What Is A Txid For Bitcoin? CryptoCoins Info Club

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.

Highlights

Protocol

Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.

GUI

Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.

Blockchain

The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog

Accrual

Changed

Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.
ColdCard also has a utility called ckcc that will do the sign operation instead of HWI, but in many ways they are interchangeable. KeepKey and Ledger both have libraries for scripted signing but no one-shot, one-line console apps that I know of. But HWI and Electrum of course work on all four.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to Bitcoin [link] [comments]

The power of "import electrum" as a python bitcoin scripting engine

I've been a big fan of Electrum as a wallet for a while now. Traditionally, when I wanted to do bitcoin scripting I would use either trezorlib, pycoin, or bitcoinlib. But recently I was digging a bit deeper into the Electrum source and found it to be one of the simpler python libraries to use to craft bitcoin transactions.
One of the nicer things about Electrum as a scripting engine is that you can drop the standalone app or AppImage on a system and run your scripts directly through the console. This makes doing things on Tails or other locked down systems much easier. To run one one of your scripts (without the event loop) simply type (assuming you correct the file path):
with open(r"myscript.py", 'r') as s: exec(s.read())
Obviously only do this with scripts you've personally authored. Never run random code on your machine especially when wallet private keys are in play.
There are already some great scripting examples in the electrum\scripts folder, but most of these use the event loop which brings in a lot of overhead. I found simple TXN processing can easily be done without spawning an full electrum thread. I'd be happy to PR the samples if there is any interest in this style from the maintainers.
Here's two examples I put together that craft a BIP65 spending transaction. It turned out to be much simpler than I imagined. I did it both in bitcoinlib and electrum. The structure is very similar and should hopefully be easier to follow. Feel free to start a PythonRoastMe on it.
Two things of note. I had to disable R-value grinding (nuked while loop) so that I had parity with bitcoinlib, which hasn't rolled it out yet. This is why the TXIDs differ. I also had to override the the PartialTransaction.get_preimage_script method since it makes certain multisig assumptions that don't apply to generic scripting.
Reference: * Electrum script to spend an OP_HODL P2WSH address (txid 3a461e6...78de2b6) * Electrum script to spend an OP_HODL P2SH address (txid a8110bb...3dadc93) * BitcoinLib script to spend an OP_HODL P2WSH address (txid 3a461e6...78de2b6) * BitcoinLib script to spend an OP_HODL P2SH address (txid a8110bb...3dadc93) * TXID 3a461e6...78de2b6 (P2WSH) on the blockchain * TXID a8110bb...3dadc93 (P2SH) on the blockchain * BIP-0065: OP_CHECKLOCKTIMEVERIFY (aka OP_HODL) * BIP-0141: P2WSH symantics * BIP-0016: P2SH symantics
submitted by brianddk to Electrum [link] [comments]

Weird behavior when scripting electrum's ECPrivkey(...).sign_transaction(...)

Update

Nevermind... Electrum is performing low-value R-grinding and bitcoinlib and CoinBin are not. For anyone interested, the grinding code his here. Nuking the while look makes the sigs the same.
A few days ago I used bitcoinlib to create a OP_CLTV transaction. Tonight I did the same with Electrum 4.0.4 via python and my sigs don't match.
The TXN I'm trying to match is:
The TXN has the following characteristics:
When I try signing the sighash (pre-image hash) using both bitcoinlib and Electrum 4.0.4, I get different results. I coded the TXN through another wallet as well (CoinBin), and bitcoinlib seems to be producing the proper signature, but Electrum's seems off.
I'm sure there is something simple I'm missing, but I can't figure it out.
Here's a test script to illustrate the differences:
``` from bitcoin.core.key import use_libsecp256k1_for_signing from bitcoin.core import x, b2x from bitcoin.wallet import CBitcoinSecret from electrum.ecc import ECPrivkey from electrum.bitcoin import EncodeBase58Check
use_libsecp256k1_for_signing(True) sechex = '535b755a4c265772c4f6c7e0316bfd21e24c9e47441989e14e8133c7cb2f41a3' hashhex = '9039c54c1c34aa12b69b4dda962f501bb6c9cdb6745014ef326f5d4d0472aa99' seckey = CBitcoinSecret.from_secret_bytes(x(sechex)) sig = seckey.sign(x(hashhex)) b_wif = str(seckey) b_pub = b2x(seckey.pub) b_sig = b2x(sig) seckey = ECPrivkey(x(sechex)) sig = seckey.sign_transaction(x(hashhex)) e_wif = EncodeBase58Check(b'\x80' + seckey.get_secret_bytes() + b'\x01') e_pub = seckey.get_public_key_hex(compressed=True) e_sig = b2x(sig) assert b_wif == e_wif assert b_pub == e_pub print("wif:", b_wif) print("pub:", b_pub) print("sighash:", hashhex) print("bitcoinlib sig:", b_sig) print("electrum sig: ", e_sig) 
```
The resultant sigs are:
Thoughts?
submitted by brianddk to Electrum [link] [comments]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to TREZOR [link] [comments]

Electrum unable to sign transaction properly

I'm new to using bitcoin and I'm trying to figure out a problem I've been having trying to broadcast a transaction with Electrum. Initially I was trying to send bitcoin using Electrum's built in "send" function, but kept receiving the error "scriptpubkey." After browsing other forums and seeing issues similar to what I was having, it seemed like people were saying that it was an issue with the server I was connected to. In some cases, people had to try 15-20 different servers before finally being able to send the transaction through.
I thought this was the probable cause of my situation as well so tried about 20 different servers but to no avail. Then I read about "pushing the raw hex transaction" (not sure if I am using the right lingo here) and decided to try that. I was able to make an offline transaction with Electrum and signed it, then obtained the hex code from the .txn file that was created.
I then tried to broadcast the hex code on blockchain.com/btc/pushtx, but I am still receiving the error " Code: -26, Error: scriptpubkey."
So after doing some more research it seems that my problem now is not that there was an issue with servers in Eluctrum, but rather my transactions are not being properly signed. So now I have a signed offline transaction that seems to be improperly signed by Electrum, and I am clueless as to how to correct this.
Is there a way to "unsign" the transaction and sign it again properly? How would I even go about doing that? I fear that I now have money locked up in this faulty transaction that I may not be able to recover. I have all my passwords and everything so I am confused why Electrum would not have signed it properly. I am very new to all this so I'm sure I could be missing something essential. Any advice on how to broadcast and complete my transaction would be much appreciated.
I am running the latest version of Electrum on a Windows 10 computer.

Thanks!
Edit: Latest version of Electrum being 4.0.2
Also, I suppose it is probably helpful to see the decoded transaction here:
{ "version": 2, "locktime": 644562, "ins": [ { "n": 50, "script": { "asm": "", "hex": "" }, "sequence": 4294967293, "txid": "9bc2e9464a58f7d8017fc332f064eb4faf2773daa3251d5194bb851f07afe8c5", "witness": [ "3044022066e5aa2f97647eb34377a1937dc6b7dcad81c652a23c2a5be20e07e2b1af39cf02207bc07ac253b4480c07c4b2d8494d6b18d98a4b17c4bf057468b81d95655f4aa101", "0319a1a5408ccbf7cba4d569bd14b779ded4bbedec040ab84fd9c88d79ab7410fe" ] }, { "n": 8, "script": { "asm": "", "hex": "" }, "sequence": 4294967293, "txid": "dc4e13e07f74b51e623669e2b6f05f7e6e7fa173c07ffcea73b9e84462e6e3c6", "witness": [ "3044022027822d6a6531fa3a4c2b3edfc189afdfad985ade643ebb208eb15174779400b102201db77e06d6158639ae320be5123a3effc00dff48eddf17c03c699334ea58d25a01", "031399274350b7f4888cc34ca1fa1fd915d8e90222026fc89c2d5d42574e0cf7eb" ] } ], "outs": [ { "script": { "addresses": [], "asm": "039135a7d4a9df8a21977f0765ea5667e931be9d1e1f7666d1e264ef539c2c2157", "hex": "21039135a7d4a9df8a21977f0765ea5667e931be9d1e1f7666d1e264ef539c2c2157" }, "value": 1208329 } ], "hash": "b2b8209b1c0e46cddb6ded0758fc8287a97e6b2bd1f88290c1d374b0bab4a6c8", "txid": "b2b8209b1c0e46cddb6ded0758fc8287a97e6b2bd1f88290c1d374b0bab4a6c8" } 

submitted by Arug_1 to Electrum [link] [comments]

Help with raw BCH transaction - Coinbase Multisig

Been trying to recover an old Coinbase BCH multisig wallet from back in the day and am running into errors after signing the transaction.

I followed this process to get the keys and auth script. http://blog.nerdbank.net/2017/08/how-to-sell-your-coinbase-multi-sig.html?m=1

Now that blockdozer.com is no longer up and running, these kinds of tools don't work like the original Coinb.in method - https://www.reddit.com/btc/comments/6bsc5m/used_the_coinbase_multisig_vault_recovery_tool/
https://bitcoin.stackexchange.com/questions/64493/restore-block-io-multisig-wallet-in-electrum

My last attempt was to use cryptoapis.io on postman to publish the transaction.

When I decode my transaction I get this:
{
"payload": {
"txid": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"hash": "c210d81d7421df8c29fef9d51ed4762c7c435e37e4e1f0d03da98d7a0ff53707",
"size": 404,
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "3f9c05b991e2da6a45447ad794d4a3ce83ecea4616d6865de51d823e44f6640f",
"sequence": 4294967293,
"vout": 0,
"scriptSig": {
"asm": "0 304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d09[ALL] 304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681[ALL] 5221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae",
"hex": "0047304402202c751ad9af37e4ac396e4c0517db3155996f4444912f9029c0aca48d7ebcbab102201a0b5abc1dd11377481c04f94bb61607bec3238e8efb85968fbafedf55160d090148304502210084c5bab07dd33be1f080ff39994e42139902871d7cedbbd8aa9d1cf4b02d301f02204b275afd22b4ce3b4b60de4204aad2082ecd0bd37e1ac3c2d97dc23fc0d8d681014ca95221038e0a77486457bb154806aa9696f9c09e6160961cf45978e24b3077a457c89b0a410456d2147c0ac68657840bedbc80de83ae2f3f29efb6bec8123ac5c54428e0c88f8c8c2a27fb2c32c9788e70595fc742fba6adc4dab15e8ab4a1a5d89e16025f5b4104c8b2bbb7147082f993f19a8d9641968903c9ad0be35c7e535dc307840a6af470d40eeada1ab8cffc661816423423e1cd1c867704fd436b3ebf25a330ca7eb10d53ae"
}
}
],
"vout": [
{
"value": "0.21192121",
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 e6a79df19f5b69c87231e65005b3b39396368fa0 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914e6a79df19f5b69c87231e65005b3b39396368fa088ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"bitcoincash:qrn20803nadknjrjx8n9qpdnkwfevd505qpqsq8r8w"
]
}
}
]
}
}

But when I try to send the transaction I get this error:

{
"meta": {
"error": {
"code": 4003,
"message": "Cannot send transaction: mandatory-script-verify-flag-failed (Signature must use SIGHASH_FORKID) (code 16)"
}
}
}

I wasn't able to find much info on this error message. Any help getting this sorted out would be appreciated
submitted by Majestic-Pear-1100 to btc [link] [comments]

There is new a HODLING world champ

Yesterday there was a transaction that received a lot of attention, as it spent the coinbase reward from a very early block. Here is the txID for it: f38d6f043c070ce9805ee81f46db4d32d0c9f148d62bbfbc0378bc5847c7dc70
Something interesting about this transaction that I haven't seen mentioned much online, is that whoever spent those coins is now officially the HODL world champion! What is meant by this, is that of all now-spent UTXOs, the coinbase reward they spent in that block now holds the record for being the longest-held.
This is a pretty cool title to hold, the individual who owned that UTXO had been sitting on it since the absolute earliest days of the Bitcoin network. When that block was mined, BTC had no value, beyond fascinating a handful of crypto and computer nerds around the world. When spent, the output was worth almost $500,000 USD. Thats quite the HODL!
In total, this UTXO was held for 627,404 blocks, which is about 11 years, 3 months, and 11 days.
For more info, and a list of all the runner ups, see this post on stack exchange: https://bitcoin.stackexchange.com/questions/88517/what-was-the-longest-held-utxo-ever-spent/96055#96055
submitted by Chytrik to Bitcoin [link] [comments]

Technical: A Brief History of Payment Channels: from Satoshi to Lightning Network

Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value?
So let's have a short history of various payment channel techs!

Generation 0: Satoshi's Broken nSequence Channels

Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product.
Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger.
Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore.
In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction.
So what you'd do would be something like this:
  1. You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
  2. For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
  3. For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
  4. Eventually you have to stop drinking. It comes down to one of two possibilities:
    • You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
    • You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time.
Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
  1. Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
  2. Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
  3. When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
  4. Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
  5. The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
  6. Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
  7. The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
  8. Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
  9. I think I got sidetracked here.
Lessons learned?

Spilman Channels

Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is).
Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender.
Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender.
First, you and the bartender perform this ritual:
  1. You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
  2. You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
  3. The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
  4. Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds.
So now you start ordering in this way:
  1. For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
  2. You sign the transaction and pass it to the bartender, who serves your first drink.
  3. For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
  4. At the end:
    • If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
    • If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
    • If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen.
So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx...
Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly.
"I'm refusing service to you," the bartender says.
"Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!"
"Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed."
"What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer.
What you see shocks you.
"What the --- the txid is different! You--- you changed my signature?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!"
"Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by separating the signatures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW."
Lesson learned?

CLTV-protected Spilman Channels

Using CLTV for the backoff branch.
This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015.
Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed.
This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction.
With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to.
Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time".
With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.

Todd Micropayment Networks

The old hub-spoke model (that isn't how LN today actually works).
One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel.
Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable.
So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user).
In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today.
Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy.
Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.

Poon-Dryja Lightning Network

Bidirectional two-participant channels.
The Poon-Dryja channel mechanism has two important properties:
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel.
The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online.
Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want.
Both properties, together, form a very powerful scaling property that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening.
With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow.
I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere.
There is a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit):
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network.
Lessons learned?

Future

After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time.
The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory).
Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough.
Lessons learned?
submitted by almkglor to Bitcoin [link] [comments]

Contrats d'exécution consensuels de VDS et processus du téléchargement à la chaîne

Résumé des contrats d’exécution consensuels
Le concept de base du contrat d’exécution consensuels
Contrats d’exécution consensuels, connu sous le nom de contrat intelligent dans l'industrie de la blockchain, mais l'équipe de VDS estime que ce terme est trop marketing, car nous n'avons pas trouvé à quel point la technologie de programmation contractuelle est intelligente jusqu'à présent, il s'agit simplement d'un système décentralisé dans le réseau distribué, la procédure prédéfinie de comportement consensuel formée par l'édition de code. Dans l'esprit de rechercher la vérité à partir des faits, nous pensons qu'il est plus approprié de renommer le contrat intelligent en tant que contrat d'exécution de consensus. Lorsque les humains combineront la technologie blockchain avec la technologie d'intelligence artificielle de AI à l'avenir, les obstacles à la compréhension des noms sont éliminés.
Le contrat d'exécution consensuel peut être appliqué à de nombreuses industries, telles que la finance, l'éducation, les systèmes administratifs, l'Internet des objets, le divertissement en ligne, etc. Grâce à la technologie de la blockchain, dans un réseau distribué spécifique, un script d'exécution qui est formé par l'édition de pré-code sans aucune intervention de tiers et le comportement de consensus des deux parties ou de plusieurs parties impliquées dans le protocole. Il garantit l’exécution sûre, stable et équitable des droits et intérêts de tous les participants au contrat.
Le contrat d'exécution consensuel a joué un rôle dans l'accélération de l'atterrissage de diverses applications pour le développement de l'industrie de la blockchain et a incité davantage de développeurs à y participer activement, révolutionnant l'expérience réelle des produits de la technologie de la blockchain. Tout découle des contributions exceptionnelles de l'équipe Ethereum, ouvrant une nouvelle porte à l'ensemble de l'industrie.
Structure de base et jonction
L’intégration de EVM
La machine virtuelle Ethereum (EVM) utilise un code machine 256 bits et est une machine virtuelle basée sur la pile utilisée pour exécuter les contrats d'exécution consensuels d'Ethereum. Étant donné que l'EVM est conçu pour le système Ethereum, le modèle de compte Ethereum (Account Model) est utilisé pour la transmission de valeurs. La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La raison de cette conception est, d'une part, c'est en raison de la nécessité de réaliser la fonction d'échange de résonance de VDS et la fonction d'échange inter-chaîne unidirectionnelle de bitcoin à chaîne VDS, qui peuvent réaliser la génération de deux adresses différentes de bitcoin et VDS avec une clé privée. D'autre part, l'équipe VDS estime que la structure sous-jacente des transactions Bitcoin est plus stable et fiable grâce à 10 ans de pratique sociale. Par conséquent, VDS utilise une couche d'abstraction de compte (Account Abstraction Layer) pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par EVM. De plus, VDS a ajouté une interface basée sur le modèle de compte, afin qu'EVM puisse lire directement les informations sur la chaîne VDS. Il convient de noter que la couche d'abstraction de compte peut masquer les détails de déploiement de certaines fonctions spécifiques et établir une division des préoccupations pour améliorer l'interopérabilité et l'indépendance de la plate-forme.
Dans le système Bitcoin, ce n'est qu'après la vérification du script de déverrouillage (Script Sig) et du script de verrouillage (Script Pub Key) que la sortie de transaction correspondante peut être dépensée.
Par exemple, le script de verrouillage verrouille généralement une sortie de transaction sur une adresse bitcoin (la valeur de hachage de la clé publique). Ce n'est que lorsque les conditions de configuration du script de déverrouillage et du script de verrouillage correspondent, que l'exécution du script combiné affiche le résultat sous la forme True (la valeur de retour de système est 1), de sorte que la sortie de transaction correspondante sera dépensée.
Dans le système distribué de VDS, nous soulignons l'opportunité de l'exécution du contrat d'exécution consensuel. Par conséquent, nous avons ajouté les opérateurs OP_CREATE et OP_CALL au script de verrouillage. Lorsque le système de VDS détecte cet opérateur, les nœuds de l'ensemble du réseau exécuteront la transaction. De cette façon, le rôle joué par le script Bitcoin est plus de transférer les données pertinentes vers EVM, pas seulement en tant que langage de codage. Tout comme Ethereum exécute un contrat d'exécution de consensus, le contrat déclenché par les opérateurs OP_CREATE et OP_CALL, EVM changera son état dans sa propre base de données d'état.
Compte tenu de la facilité d'utilisation du contrat d'exécution du consensus de la chaîne VDS, il est nécessaire de vérifier les données qui déclenchent le contrat et la valeur de hachage de la clé publique de la source de données.
Afin d'éviter que la proportion d'UTXO sur la chaîne de VDS ne soit trop importante, la sortie de transaction de OP_CREATE et OP_CALL est t conçue pour être dépensée. La sortie de OP_CALL peut envoyer des fonds pour d'autres contrats ou adresses de hachage de clé publique.
Tout d’abord, pour le contrat d'exécution consensuel créé sur la chaîne VDS, le système généreraune valeur de hachage de transaction pour l'appel de contrat.Le contrat nouvellement libéré a un solde initial de 0 (les contrats avec un solde initial ne sont pas 0 ne sont pas pris en charge). Afin de répondre aux besoins du contrat d'envoi de fonds, VDS utilise l'opérateur OP_CALL pour créer une sortie de transaction. Le script de sortie du contrat d'envoi de fonds est similaire à :
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
Ce script n'est pas compliqué et OP_CALL effectue la plupart du travail requis. VDS définit le coût spécifique de la transaction (sans tenir compte de la situation de out-of-gas) comme Output Value, qui est Gas Limit. Le mécanisme spécifique du Gas sera discuté dans les chapitres suivants. Lorsque le script de sortie ci-dessus est ajouté à la blockchain, la sortie établit une relation correspondante avec le compte du contrat et se reflète dans le solde du contrat. Le solde peut être compris comme la somme des coûts contractuels disponibles.
La sortie d'adresse de hachage de clé publique standard est utilisée pour le processus de base des transactions de contrat, et le processus de transaction entre les contrats est également généralement cohérent. En outre, vous pouvez effectuer des transactions par P2SH et des transactions non standard (non-standard transactions). Lorsque le contrat actuel doit être échangé avec un autre contrat ou une adresse de hachage de clé publique, la sortie disponible dans le compte du contrat sera consommée. Cette partie de la sortie consommée doit être présente pour la vérification des transactions dans le réseau de VDS, que nous appelons la transaction attendue du contrat (Expected Contract Transactions). Étant donné que la transaction attendue du contrat est générée lorsque le mineur vérifie et exécute la transaction, plutôt que d'être générée par l'utilisateur de la transaction, elle ne sera pas diffusée sur l'ensemble du réseau.
Le principe de fonctionnement principal de la transaction attendue du contrat est réalisé par le code OP_SPEND. OP_CREATE et OP_CALL ont deux modes de fonctionnement. Lorsque l'opérateur est utilisé comme script de sortie, EVM l'exécute, lorsque l'opérateur est utilisé comme script d'entrée, EVM ne sera pas exécuté (sinon il provoquera une exécution répétée). Dans ce cas, OP_CREATE et OP_CALL peuvent être utilisés comme Opération sans commandement. OP_CREATE et OP_CALL reçoivent la valeur de hachage de transaction transmise par OP_SPEND et renvoient 1 ou 0 (c'est-à-dire il peut être dépensé ou pas). Il montre l'importance de OP_SPEND dans la transaction attendue de l'intégralité du contrat. Plus précisément, lorsque OP_SPEND transmet la valeur de hachage de transaction à OP_CREATE et OP_CALL, OP_CREATE et OP_CALL comparent si la valeur de hachage existe dans la liste des transactions attendues du contrat. S'il existe, renvoyez 1 pour dépenser, sinon retournez 0, ce n'est pas pour dépenser. Cette logique fournit indirectement un moyen complet et sûr de garantir que les fonds du contrat ne peuvent être utilisés que par le contrat, ce qui est cohérent avec le résultat des transactions UTXO ordinaires.
Lorsque le contrat EVM envoie des fonds à l'adresse de hachage de clé publique ou à un autre contrat, une nouvelle transaction sera établie. À l'aide de l'algorithme de Consensus-critical coin picking, la sortie de transaction la plus appropriée peut être sélectionnée dans le pool de sortie disponible du contrat. La sortie de transaction sélectionnée sera utilisée comme script d'entrée pour exécuter un seul OP_SPEND, et la sortie est l'adresse cible des fonds, et les fonds restants seront renvoyés au contrat, tout en modifiant la sortie disponible pour la consommation. Ensuite, la valeur de hachage de cette transaction sera ajoutée à la liste des transactions attendues du contrat. Lorsque la transaction est exécutée, la transaction sera immédiatement ajoutée au bloc. Une fois que les mineurs de la chaîne ont vérifié et exécuté la transaction, la liste des transactions attendues du contrat est à nouveau parcourue. Une fois la vérification correcte, la valeur de hachage est supprimée de la table. De cette façon, l'utilisation de OP_SPEND peut effectivement empêcher l'utilisation de valeurs de hachage codées en dur pour modifier le coût de la sortie.
La couche d'abstraction des comptes VDS élimine la nécessité pour l'EVM d'accorder trop d'attention à coin-picking. Il lui suffit de connaître le solde du contrat et peut échanger des fonds avec d'autres contrats ou même des adresses de hachage de clé publique. De cette façon, seule une légère modification du contrat d'exécution du consensus Ethereum peut répondre aux exigences de fonctionnement du contrat VDS.
En d'autres termes, tant que le contrat d'exécution consensuel peut être exécuté sur la chaîne Ethereum, il peut s'exécuter sur la chaîne VDS.
Achèvement de AAL
La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La plate-forme générale de contrat d'exécution de consensus utilise le modèle de compte. Étant donné que le contrat en tant qu'entité nécessite un logo de réseau, ce logoest l'adresse du contrat, de sorte que le fonctionnement et la gestion du contrat d'exécution consensuel peuvent être effectués par cette adresse. La couche d'abstraction de compte est ajoutée à la conception du modèle (Account Abstraction Layer, AAL) de chaîne de VDS, qui est utilisée pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par le contrat.
Pour les développeurs qui exécutent des contrats par consensus, le modèle de compte de la machine virtuelle est relativement simple. Il prend en charge l'interrogation des soldes des contrats et peut également envoyer des fonds pour d'autres contrats. Bien que ces opérations semblent très simples et basiques, toutes les transactions de la chaîne VDS utilisent le langage de script Bitcoin, et il est plus compliqué que prévu d'être implémenté dans la couche d'abstraction de compte de la chaîne VDS basée sur le modèle Bitcoin UTXO. AAL a donc élargi sa base en ajoutant trois nouveaux opérateurs :
OP_CREATE est utilisé pour effectuer la création de contrats intelligents, transmettre le code d'octet transmis via la transaction à la base de données de stockage de contrats de la machine virtuelle et générer un compte de contrat.
OP_CALL est utilisé pour transférer les données pertinentes et les informations d'adresse nécessaires pour appeler le contrat et exécuter le contenu du code dans le contrat. (Cet opérateur peut également envoyer des fonds pour des contrats d'exécution consensuels).
OP_SPEND utilise la valeur de hachage de ID de contrat actuel comme transaction d'entrée HASH ou transaction HASH envoyée à l'UTXO du contrat, puis utilise OP_SPEND comme instruction de dépense pour créer un script de transaction.
Utilisation des Contrats et processus du téléchargement à la chaîne
Rédiger les contrats
Il est actuellement possible d'utiliser le langage Solidity pour rédiger des contrats d'exécution de consensus.
Utilisez Solidity Remix ou un autre Solidity IDE pour l'écriture et la compilation de code.
solidity remix(https://remix.ethereum.org/
Il est recommandé d'utiliser le mode homestead pour compiler.
Il est recommandé d'utiliser la version solidité 0.4.24 (si d'autres versions sont utilisées, cela peut provoquer des erreurs ou des échecs).
La syntaxe Solidity peut être référencée(https://solidity.readthedocs.io/en)
Compiler et déployer les contrats
Fonctionnement du contrat intelligent de vdsd
Examiner les variables de fonctionnement de l'environnement
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
> Les tests sous contrat sont effectués dans l'environnement de test. Il est recommandé de tester après avoir atteint une hauteur de 440 blocs.
440 blocs hautement achevés l'opération de retour de fonds après les événements anormaux du contrat (refund) et (revert).
La commande de contrat de déploiement est :
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
Cette fonction est utilisée pour l'exécution du constructeur du contrat avec les paramètres entrants pour obtenir le ByteCode qui est finalement utilisé pour le déploiement.
(Cette méthode consiste à associer le bytecode à ABI et à le stocker localement pour l'enregistrement. Il peut appeler des méthodes internes localement et renvoyer le bytecode approprié)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
La valeur de retour est : txid, éxpéditeur, hachage de l'expéditeur160, adresse du contrat
Consulter si la commande a été exécutée avec succès :
```vds-cli gettransactionreceipt txid```
La valeur de retour de txid pour les transactions non contractuelles est vide
La valeur de retour est : Les informations pertinentes de txid sur la BlockHash Hachage du bloc
- blockNumber Hauteur de bloc
- transactionHash Hachage de transaction
- transactionIndex La position de l'échange dans le bloc
- from Hachage de l’adresse de l’expéditeur 160
- to Le destinataire est l'adresse du contrat, le lieu de création de la transaction contractuelle est 00000000000000000000000000000
- cumulativeGasUsed Gas accumulé
- gasUsed Gaz réellement utilisé
- contractAddress Adresse du contrat
- excepted Y a-t-il des erreurs
- exceptedMessage Message d'erreur
-
Il convient de noter que le champ excepted n'est pas None, ce qui indique que l'exécution du contrat a échoué. Bien que la transaction puisse être vérifiée sur la chaîne, cela ne signifie pas que le contrat a été exécuté avec succès, c'est-à-dire que les frais de traitement pour l'exécution de ce contrat ne sont pas remboursables. Les frais de traitement ne seront remboursés que si la méthode revert est entrée dans le contrat, et les frais de méthode ne seront pas remboursés pour la méthode assert.
Appel des contrats
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
Cette fonction est utilisée pour ajouter le contrat ABI à la base de données locale.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
Cette fonction est utilisée pour obtenir les informations du contrat ajouté.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
Cette fonction renverra le résultat de l'exécution lors de l'appel de la méthode constante ordinaire, comme l'appel de la méthode d'opération de données de contrat retournera la chaîne de format hexadécimal du script d'opération.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Cette fonction est utilisée pour envoyer le script d'opération de contrat au contrat spécifié et le faire enregistrer sur la blockchain.
Consultation des résultats d’exécution des contrats
```vds-cli gettransaction txid```
Cette commande est utilisée pour afficher les heures de confirmation de la transaction de portefeuille actuelle.
```vds-cli gettransactionreceipt txid```
Cette commande est utilisée pour vérifier les résultats d'exécution de la création de contrat et des transactions d'appel, s'il y a des exceptions levées et des consommations réelles de GAS.
`${datadir}/vmExecLogs.json` enregistrera les appels de contrat sur la blockchain. Ce fichier servira d'interface externe pour les événements de contrat.
Interface d'appel des contrats
l Interface de création de contrat createcontract
l Interface de déploiement de contrat deploycontract
l Interface d'ajout ABI addcontract
l Interface d’appel des contrats avec l’opération des fons sendtocontract
l Interface de lecture des informations sur les contrats callcontractfunc
l Interface d'acquisition d'informations sur l'exécution des transactions contractuelles gettransactionreceipt
L’expliquation des coûts d’expoitation des contrats
Les coûts de fonctionnement de la création d'un contrat sont toutes des méthodes estimées, et un succès d'exécution à 100% ne peut pas être garanti, car gas limit a une limite supérieure de 50000000, et les contrats dépassant cette limite entraîneront un échec. La chaîne de VDS utilise une méthode de rendre la monnaie, ce qui signifie que même si beaucoup de gaz est envoyé, le mineur n'utilisera pas tout le gas et restituera le gas restant. Alors ne vous inquiétez pas de dépenser trop de gas.
Le coût de création d'un contrat est approximativement de la taille du Byte Code * 300 comme gas limit, le gas price minimum est de 0.0000004, gas price * gas limit est le coût de création d'un contrat.
En ce qui concerne l'exécution de la méthode dans un contrat, le gas requis est estimé. En raison de la congestion du réseau, l'estimation ne garantit pas que 100% peuvent être téléchargés avec succès dans la chaîne. Par conséquent, je crains de tromper et de demander au développeur de vérifier les résultats.
submitted by YvanMay to u/YvanMay [link] [comments]

How can I get this script to work for Litecoin 0.8.7.5?

What would I need to do to get this script to work for Litecoin 0.8.7.5? https://github.com/litecoin-project/litecoin/releases/tag/v0.8.7.5
 class Bitcoin { // Configuration options private $username; private $password; private $proto; private $host; private $port; private $url; private $CACertificate; // Information and debugging public $status; public $error; public $raw_response; public $response; private $id = 0; /** * @param string $username * @param string $password * @param string $host * @param int $port * @param string $proto * @param string $url */ function __construct($username, $password, $host = 'localhost', $port = 8332, $url = null) { $this->username = $username; $this->password = $password; $this->host = $host; $this->port = $port; $this->url = $url; // Set some defaults $this->proto = $host == 'localhost' ? 'http':'https'; $this->CACertificate = null; } /** * @param string|null $certificate */ function setSSL($certificate = null) { $this->proto = 'https'; // force HTTPS $this->CACertificate = $certificate; } function __call($method, $params) { $this->status = null; $this->error = null; $this->raw_response = null; $this->response = null; // If no parameters are passed, this will be an empty array $params = array_values($params); // The ID should be unique for each call $this->id++; // Build the request, it's ok that params might have any empty array $request = json_encode(array( 'method' => $method, 'params' => $params, 'id' => $this->id )); // Build the cURL session $curl = curl_init("{$this->proto}://{$this->username}:{$this->password}@{$this->host}:{$this->port}/{$this->url}"); $options = array( CURLOPT_RETURNTRANSFER => TRUE, CURLOPT_FOLLOWLOCATION => TRUE, CURLOPT_MAXREDIRS => 10, CURLOPT_HTTPHEADER => array('Content-type: application/json'), CURLOPT_POST => TRUE, CURLOPT_POSTFIELDS => $request ); if ($this->proto == 'https') { // If the CA Certificate was specified we change CURL to look for it if ($this->CACertificate != null) { $options[CURLOPT_CAINFO] = $this->CACertificate; $options[CURLOPT_CAPATH] = DIRNAME($this->CACertificate); } else { // If not we need to assume the SSL cannot be verified so we set this flag to FALSE to allow the connection $options[CURLOPT_SSL_VERIFYPEER] = FALSE; } } curl_setopt_array($curl, $options); // Execute the request and decode to an array $this->raw_response = curl_exec($curl); $this->response = json_decode($this->raw_response, TRUE); //error_log('this->response: '. print_r($this->response,true)); // If the status is not 200, something is wrong $this->status = curl_getinfo($curl, CURLINFO_HTTP_CODE); // If there was no error, this will be an empty string $curl_error = curl_error($curl); curl_close($curl); if (!empty($curl_error)) { $this->error = $curl_error; } if ($this->response['error']) { // If bitcoind returned an error, put that in $this->error $this->error = $this->response['error']['message']; } elseif ($this->status != 200) { // If bitcoind didn't return a nice error message, we need to make our own switch ($this->status) { case 400: $this->error = 'HTTP_BAD_REQUEST'; break; case 401: $this->error = 'HTTP_UNAUTHORIZED'; break; case 403: $this->error = 'HTTP_FORBIDDEN'; break; case 404: $this->error = 'HTTP_NOT_FOUND'; break; } } if ($this->error) { return FALSE; } return $this->response['result']; } } /* Address History Interface Class */ class AddressHistory { public $address = null; public $n_tx = 0; public $total_sent = 0; public $total_received = 0; public $balance = 0; public $final_balance = 0; public $txns = array(); public function __construct($txn=null) { if(! is_array($txn)) return null; if(array_key_exists('address', $txn)) $this->address = $txn['address']; if(array_key_exists('n_tx', $txn)) $this->n_tx = $txn['n_tx']; if(array_key_exists('total_sent', $txn)) $this->total_sent = $txn['total_sent']; if(array_key_exists('total_received', $txn))$this->total_received = $txn['total_received']; if(array_key_exists('balance', $txn)) $this->balance = $txn['balance']; if(array_key_exists('final_balance', $txn)) $this->final_balance = $txn['final_balance']; if(is_array($txn['txns'])) { foreach($txn['txns'] as $key => $this_txn) { $new_txn = array( 'hash' => $this_txn['hash'], 'block_height' => $this_txn['block_height'], 'value' => $this_txn['value'], 'spent' => $this_txn['spent'], 'spent_by' => $this_txn['spent_by'], 'confirmations'=> $this_txn['confirmations'] ); $this->txns[$key] = new TransRef($new_txn); } } else { $this->txns = null; } return $this; } } /* Transaction Reference Interface Class */ class TransRef { public $hash; public $block_height; public $value; public $spent; public $spent_by; public $confirmations; public function __construct($txnref=null) { if(! is_array($txnref)) return null; if(array_key_exists('hash', $txnref)) $this->hash = $txnref['hash']; if(array_key_exists('block_height', $txnref)) $this->block_height = $txnref['block_height']; if(array_key_exists('value', $txnref)) $this->value = $txnref['value']; if(array_key_exists('spent', $txnref)) $this->spent = $txnref['spent']; if(array_key_exists('spent_by', $txnref)) $this->spent_by = $txnref['spent_by']; if(array_key_exists('confirmations', $txnref)) $this->confirmations = $txnref['confirmations']; return $this; } } /* CoindRPC - JsonRPC Class to talk to bitcoind */ class CoindRPC extends Bitcoin { public function __construct() { return parent::__construct(WN_RPC_USER, WN_RPC_PASS, WN_RPC_HOST, WN_RPC_PORT); } public function __call($method, $params) { return parent::__call($method, $params); } public function get_address_balance($address, $confirmations=0) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { $balance = $this->getreceivedbyaddress($address, $confirmations); } if($balance != '') { return floatval($balance); } else { return 0; } } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_address_history($address) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { //- if only listening to one BTC account //$history = $this->listtransactions(WN_RPC_ACCT); $history = $this->listtransactions(); $txns = array(); $final_balance = $balance = 0; foreach($history as $txn) { if($txn['address'] != $address) continue; $n_tx = $total_received = $total_sent = 0; $n_tx = intval($addr_hist['n_tx']) + 1; switch($txn['category']) { case('receive'): $total_received = $addr_hist['total_received'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; case('send'): $total_sent = $addr_hist['total_sent'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; } $txns[] = array( 'hash' => $txn['txid'], 'value' => $txn['amount'], 'spent' => $txn['spent'], 'spent_by' => $txn['spent_by'], 'confirmations' => $txn['confirmations'], ); } $addr_hist = array( 'address' => $address, 'n_tx' => $n_tx, 'total_sent' => $total_sent, 'total_received' => $total_received, 'balance' => $balance, 'final_balance' => $final_balance, 'txns' => $txns ); $addr_hist = new AddressHistory($addr_hist); } else { $addr_hist = false; error_log('Address invalid: '.$address); error_log('['.__LINE__.'] : '.__FILE__); } return $addr_hist; } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_transaction($hash) { try { return $this->gettransaction($hash); } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } } /* Helper class */ class Helper { public static $api = null; public static $db = null; public function __construct($db, $api) { Helper::$api = $api; Helper::$db = $db; } public static function walletnotify_email($txnhead) { //- bitcoind calls walletnotify on 0 confirmations and 1. //- We only want email to go out on the first call. Otherwise //- if we want only one 1 confrime, change this to //- confirmations == 0) return; if($txnhead['confirmations'] > 0) return; $tmpl = file_get_contents('email.notify.tmpl.html'); foreach($txnhead as $key => $val) { $map['{'.$key.'}'] = $val; } $map['{timestamp}'] = date('Y-m-d H:i:s', WN_GLOBAL_TIMESTAMP); $map['{hostname}'] = php_uname('n'); $html = str_replace(array_keys($map), array_values($map), $tmpl); $txid_short = substr($txnhead['txid'], 0, 4).' .. '.substr($txnhead['txid'], -4); $msg = "=WNotify=". "\ntxid: ".$txid_short. "\nAmt : ".$txnhead['amount']. "\nCmnt: ".$txnhead['comment']. "\nAcct: ".$txnhead['account']. "\nConf: ".$txnhead['confirmations']. "\nCat : ".$txnhead['category']. "\nAddr: ".$txnhead['address']. ""; //- send to carrier's email to SMS gateway if configured if(defined('WN_SMS_ADMIN') && filter_var(WN_SMS_ADMIN, FILTER_VALIDATE_EMAIL)) { Helper::send_email_sms($msg, WN_SMS_ADMIN); } return Helper::send_email($html, 'WN:WalletNotify', WN_EMAIL_ADMIN);; } public static function send_email($msg, $subj, $to) { $headers = 'From: '.WN_EMAIL_FROM."\r\n"; $headers .= "MIME-Version: 1.0\r\n"; $headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n"; if(trim($msg) == '') return false; return mail($to, $subj, $msg, $headers); } public static function send_email_sms($msg, $to) { if(trim($msg) == '') return false; if($to == '') return false; $headers = 'From: '.WN_EMAIL_FROM."\r\n"; return mail($to, null, $msg."\n.", $headers); } } 
submitted by Mjjjokes to cryptodevs [link] [comments]

Strange behavior of small OP_RETURN outputs

I'm hoping someone familiar with the structure of an OP_RETURN output can help point me to a technical resource or help explain some strange behavior I've noticed in OP_RETURN outputs that are 4 bytes or smaller. It seems that data 4 bytes or less doesn't get pushed onto the stack in the same manner as outputs with 5-80 bytes.
For example, bitcoin txid 71a5e4e683b06b1b2accdab265abfad8335d75f3d5436e7435d0e48a33f283bb has an OP_RETURN output that looks like this:
 [vout] => Array ( [0] => Array ( [value] => 0 [n] => 0 [scriptPubKey] => Array ( [asm] => OP_RETURN 24897 [hex] => 6a024161 [type] => nulldata ) ) 
The OP_RETURN hex value of 6a024161 should have scripted with the OP_RETURN (6a) pushing 2 bytes of data (02) to the stack, with the data being 4161. Yet the data that was actually pushed is 24897. This doesn't appear consistent with the script specification (https://en.bitcoin.it/wiki/Script). I've been able to consistently reproduce these results by building transactions with bitcoin core, and once the data is 5 bytes or larger it behaves consistent with the specification. Does anyone know what's going on here or have any information they can share on this?
Thanks!
submitted by sepharose to Bitcoin [link] [comments]

Craig Steven Wright is Satoshi Nakamoto

A couple of years ago in the early months of the 2017, I published a piece called Abundance Via Cryptocurrencies (https://www.reddit.com/C\_S\_T/comments/69d12a/abundance\_via\_cryptocurrencies/) in which I kind of foresaw the crypto boom that had bitcoin go from $1k to $21k and the alt-coin economy swell up to have more than 60% of the bitcoin market capitalisation. At the time, I spoke of coming out from “the Pit” of conspiracy research and that I was a bit suss on bitcoin’s inception story. At the time I really didn’t see the scaling solution being put forward as being satisfactory and the progress on bitcoin seemed stifled by the politics of the social consensus on an open source protocol so I was looking into alt coins that I thought could perhaps improve upon the shortcomings of bitcoin. In the thread I made someone recommended to have a look at 4chan’s business and finance board. I did end up taking a look at it just as the bull market started to really surge. I found myself in a sea of anonymous posters who threw out all kinds of info and memes about the hundreds, thousands, tens of thousands of different shitcoins and why they’re all going to have lambos on the moon. I got right in to it, I loved the idea of filtering through all the shitposts and finding the nuggest of truth amongst it all and was deeply immersed in it all as the price of bitcoin surged 20x and alt coins surged 5-10 times against bitcoin themselves. This meant there were many people who chucked in a few grand and bought a stash of alt coins that they thought were gonna be the next big thing and some people ended up with “portfolios” 100-1000x times their initial investment.
To explain what it’s like to be on an anonymous business and finance board populated with incel neets, nazis, capitalist shit posters, autistic geniuses and whoever the hell else was using the board for shilling their coins during a 100x run up is impossible. It’s hilarious, dark, absurd, exciting and ultimately addictive as fuck. You have this app called blockfolio that you check every couple of minutes to see the little green percentages and the neat graphs of your value in dollars or bitcoin over day, week, month or year. Despite my years in the pit researching conspiracy, and my being suss on bitcoin in general I wasn’t anywhere near as distrustful as I should have been of an anonymous business and finance board and although I do genuinely think there are good people out there who are sharing information with one another in good faith and feel very grateful to the anons that have taken their time to write up quality content to educate people they don’t know, I wasn’t really prepared for the level of organisation and sophistication of the efforts groups would go to to deceive in this space.
Over the course of my time in there I watched my portfolio grow to ridiculous numbers relative to what I put in but I could never really bring myself to sell at the top of a pump as I always felt I had done my research on a coin and wanted to hold it for a long time so why would I sell? After some time though I would read about something new or I would find out of dodgy relationships of a coin I had and would want to exit my position and then I would rebalance my portfolio in to a coin I thought was either technologically superior or didn’t have the nefarious connections to people I had come across doing conspiracy research. Because I had been right in to the conspiracy and the decentralisation tropes I guess I always carried a bit of an antiauthoritarian/anarchist bias and despite participating in a ridiculously capitalistic market, was kind of against capitalism and looking to a blockchain protocol to support something along the lines of an open source anarchosyndicalist cryptocommune. I told myself I was investing in the tech and believed in the collective endeavour of the open source project and ultimately had faith some mysterious “they” would develop a protocol that would emancipate us from this debt slavery complex.
As I became more and more aware of how to spot artificial discussion on the chans, I began to seek out further some of the radical projects like vtorrent and skycoin and I guess became a bit carried away from being amidst such ridiculous overt shilling as on the boards so that if you look in my post history you can even see me promoting some of these coins to communities I thought might be sympathetic to their use case. I didn’t see it at the time because I always thought I was holding the coins with the best tech and wanted to ride them up as an investor who believed in them, but this kind of promotion is ultimately just part of a mentality that’s pervasive to the cryptocurrency “community” that insists because it is a decentralised project you have to in a way volunteer to inform people about the coin since the more decentralised ones without premines or DAO structures don’t have marketing budgets, or don’t have marketing teams. In the guise of cultivating a community, groups form together on social media platforms like slack, discord, telegram, twitter and ‘vote’ for different proposals, donate funds to various boards/foundations that are set up to give a “roadmap” for the coins path to greatness and organise marketing efforts on places like reddit, the chans, twitter. That’s for the more grass roots ones at least, there are many that were started as a fork of another coin, or a ICO, airdrop or all these different ways of disseminating a new cryptocurrency or raising funding for promising to develop one. Imagine the operations that can be run by a team that raised millions, hundreds of millions or even billions of dollars on their ICOs, especially if they are working in conjunction with a new niche of cryptocurrency media that’s all nepotistic and incestuous.
About a year and a half ago I published another piece called “Bitcoin is about to be dethroned” (https://www.reddit.com/C\_S\_T/comments/7ewmuu/bitcoin\_is\_about\_to\_be\_dethroned/) where I felt I had come to realise the scaling debate had been corrupted by a company called Blockstream and they had been paying for social media operations in a fashion not to dissimilar to correct the record or such to control the narrative around the scaling debate and then through deceit and manipulation curated an apparent consensus around their narrative and hijacked the bitcoin name and ticker (BTC). I read the post again just before posting this and decided to refer to it to to add some kind of continuity to my story and hopefully save me writing so much out. Looking back on something you wrote is always a bit cringey especially because I can see that although I had made it a premise post, I was acting pretty confident that I was right and my tongue was acidic because of so much combating of shills on /biz/ but despite the fact I was wrong about the timing I stand by much of what I wrote then and want to expand upon it a bit more now.
The fork of the bitcoin protocol in to bitcoin core (BTC) and bitcoin cash (BCH) is the biggest value fork of the many that have occurred. There were a few others that forked off from the core chain that haven’t had any kind of attention put on them, positive or negative and I guess just keep chugging away as their own implementation. The bitcoin cash chain was supposed to be the camp that backed on chain scaling in the debate, but it turned out not everyone was entirely on board with that and some players/hashpower felt it was better to do a layer two type solution themselves although with bigger blocks servicing the second layer. Throughout what was now emerging as a debate within the BCH camp, Craig Wright and Calvin Ayre of Coin Geek said they were going to support massive on chain scaling, do a node implementation that would aim to restore bitcoin back to the 0.1.0 release which had all kinds of functionality included in it that had later been stripped by Core developers over the years and plan to bankrupt the people from Core who changed their mind on agreeing with on-chain scaling. This lead to a fork off the BCH chain in to bitcoin satoshis vision (BSV) and bitcoin cash ABC.

https://bitstagram.bitdb.network/m/raw/cbb50c322a2a89f3c627e1680a3f40d4ad3cee5a3fb153e5d6d001bdf85de404

The premise for this post is that Craig S Wright was Satoshi Nakamoto. It’s an interesting premise because depending upon your frame of reference the premise may either be a fact or to some too outrageous to even believe as a premise. Yesterday it was announced via CoinGeek that Craig Steven Wright has been granted the copyright claim for both the bitcoin white-paper under the pen name Satoshi Nakamoto and the original 0.1.0 bitcoin software (both of which were marked (c) copyright of satoshi nakamoto. The reactions to the news can kind of be classified in to four different reactions. Those who heard it and rejected it, those who heard it but remained undecided, those who heard it and accepted it, and those who already believed he was. Apparently to many the price was unexpected and such a revelation wasn’t exactly priced in to the market with the price immediately pumping nearly 100% upon the news breaking. However, to some others it was a vindication of something they already believed. This is an interesting phenomena to observe. For many years now I have always occupied a somewhat positively contrarian position to the default narrative put forward to things so it’s not entirely surprising that I find myself in a camp that holds the minority opinion. As you can see in the bitcoin dethroned piece I called Craig fake satoshi, but over the last year and bit I investigated the story around Craig and came to my conclusion that I believed him to be at least a major part of a team of people who worked on the protocol I have to admit that through reading his articles, I have kind of been brought full circle to where my contrarian opinion has me becoming somewhat of an advocate for “the system’.
https://coingeek.com/bitcoin-creator-craig-s-wright-satoshi-nakamoto-granted-us-copyright-registrations-for-bitcoin-white-paper-and-code/

When the news dropped, many took to social media to see what everyone was saying about it. On /biz/ a barrage of threads popped up discussing it with many celebrating and many rejecting the significance of such a copyright claim being granted. Immediately in nearly every thread there was a posting of an image of a person from twitter claiming that registering for copyright is an easy process that’s granted automatically unless challenged and so it doesn’t mean anything. This was enough for many to convince them of the insignificance of the revelation because of the comment from a person who claimed to have authority on twitter. Others chimed in to add that in fact there was a review of the copyright registration especially in high profile instances and these reviewers were satisfied with the evidence provided by Craig for the claim. At the moment Craig is being sued by Ira Kleiman for an amount of bitcoin that he believes he is entitled to because of Craig and Ira’s brother Dave working together on bitcoin. He is also engaged in suing a number of people from the cryptocurrency community for libel and defamation after they continued to use their social media/influencer positions to call him a fraud and a liar. He also has a number of patents lodged through his company nChain that are related to blockchain technologies. This has many people up in arms because in their mind Satoshi was part of a cypherpunk movement, wanted anonymity, endorsed what they believed to be an anti state and open source technologies and would use cryptography rather than court to prove his identity and would have no interest in patents.
https://bitstagram.bitdb.network/m/raw/1fce34a7004759f8db16b2ae9678e9c6db434ff2e399f59b5a537f72eff2c1a1
https://imgur.com/a/aANAsL3)

If you listen to Craig with an open mind, what cannot be denied is the man is bloody smart. Whether he is honest or not is up to you to decide, but personally I try to give everyone the benefit of the doubt and then cut them off if i find them to be dishonest. What I haven’t really been able to do with my investigation of craig is cut him off. There have been many moments where I disagree with what he has had to say but I don’t think people having an opinion about something that I believe to be incorrect is the same as being a dishonest person. It’s very important to distinguish the two and if you are unable to do so there is a very real risk of you projecting expectations or ideals upon someone based off your ideas of who they are. Many times if someone is telling the truth but you don’t understand it, instead of acknowledging you don’t understand it, you label them as being stupid or dishonest. I think that has happened to an extreme extent with Craig. Let’s take for example the moment when someone in the slack channel asked Craig if he had had his IQ tested and what it was. Craig replied with 179. The vast majority of people on the internet have heard someone quote their IQ before in an argument or the IQ of others and to hear someone say such a score that is actually 6 standard deviations away from the mean score (so probably something like 1/100 000) immediately makes them reject it on the grounds of probability. Craig admits that he’s not the best with people and having worked with/taught many high functioning people (sometimes on the spectrum perhaps) on complex anatomical and physiological systems I have seen some that also share the same difficulties in relating to people and reconciling their genius and understandings with more average intelligences. Before rejecting his claim outright because we don’t understand much of what he says, it would be prudent to first check is there any evidence that may lend support to his claim of a one in a million intelligence quotient.

Craig has mentioned on a number of occasions that he holds a number of different degrees and certifications in relation to law, cryptography, statistics, mathematics, economics, theology, computer science, information technology/security. I guess that does sound like something someone with an extremely high intelligence could achieve. Now I haven’t validated all of them but from a simple check on Charles Sturt’s alumni portal using his birthday of 23rd of October 1970 we can see that he does in fact have 3 Masters and a PhD from Charles Sturt. Other pictures I have seen from his office at nChain have degrees in frames on the wall and a developer published a video titled Craig Wright is a Genius with 17 degrees where he went and validated at least 8 of them I believe. He is recently publishing his Doctorate of Theology through an on-chain social media page that you have to pay a little bit for access to sections of his thesis. It’s titled the gnarled roots of creation. He has also mentioned on a number of occasions his vast industry experience as both a security contractor and business owner. An archive from his LinkedIn can be seen below as well.

LinkedIn - https://archive.is/Q66Gl
https://youtu.be/nXdkczX5mR0 - Craig Wright is a Genius with 17 Degrees
https://www.yours.org/content/gnarled-roots-of-a-creation-mythos-45e69558fae0 - Gnarled Roots of Creation.
In fact here is an on chain collection of articles and videos relating to Craig called the library of craig - https://www.bitpaste.app/tx/94b361b205196560d1bd09e4e3b3ec7ad6bea478af204cabfe243efd8fc944dd


So there is a guy with 17 degrees, a self professed one in a hundred thousand IQ, who’s worked for Australian Federal Police, ASIO, NSA, NASA, ASX. He’s been in Royal Australian Air Force, operated a number of businesses in Australia, published half a dozen academic papers on networks, cryptography, security, taught machine learning and digital forensics at a number of universities and then another few hundred short articles on medium about his work in these various domains, has filed allegedly 700 patents on blockchain related technology that he is going to release on bitcoin sv, copyrighted the name so that he may prevent other competing protocols from using the brand name, that is telling you he is the guy that invented the technology that he has a whole host of other circumstantial evidence to support that, but people won’t believe that because they saw something that a talking head on twitter posted or that a Core Developer said, or a random document that appears online with a C S Wright signature on it that lists access to an address that is actually related to Roger Ver, that’s enough to write him off as a scam. Even then when he publishes a photo of the paper copy which appears to supersede the scanned one, people still don’t readjust their positions on the matter and resort back to “all he has to do is move the coins or sign a tx”.

https://imgur.com/urJbe10

Yes Craig was on the Cypherpunk mailing list back in the day, but that doesn’t mean that he was or is an anarchist. Or that he shares the same ideas that Code Is Law that many from the crypto community like to espouse. I myself have definitely been someone to parrot the phrase myself before reading lots of Craig’s articles and trying to understand where he is coming from. What I have come to learn from listening and reading the man, is that although I might be fed up with the systems we have in place, they still exist to perform important functions within society and because of that the tools we develop to serve us have to exist within that preexisting legal and social framework in order for them to have any chance at achieving global success in replacing fiat money with the first mathematically provably scarce commodity. He says he designed bitcoin to be an immutable data ledger where everyone is forced to be honest, and economically disincentivised to perform attacks within the network because of the logs kept in a Write Once Read Many (WORM) ledger with hierarchical cryptographic keys. In doing so you eliminate 99% of cyber crime, create transparent DAO type organisations that can be audited and fully compliant with legislature that’s developed by policy that comes from direct democratic voting software. Everyone who wants anonymous coins wants to have them so they can do dishonest things, illegal things, buy drugs, launder money, avoid taxes.

Now this triggers me a fair bit as someone who has bought drugs online, who probably hasn’t paid enough tax, who has done illegal things contemplating what it means to have that kind of an evidence ledger, and contemplate a reality where there are anonymous cryptocurrencies, where massive corporations continue to be able to avoid taxes, or where methamphetamine can be sold by the tonne, or where people can be bought and sold. This is the reality of creating technologies that can enable and empower criminals. I know some criminals and regard them as very good friends, but I know there are some criminals that I do not wish to know at all. I know there are people that do horrific things in the world and I know that something that makes it easier for them is having access to funds or the ability to move money around without being detected. I know arms, drugs and people are some of the biggest markets in the world, I know there is more than $50 trillion dollars siphoned in to off shore tax havens from the value generated as the product of human creativity in the economy and how much human charity is squandered through the NGO apparatus. I could go on and on about the crappy things happening in the world but I can also imagine them getting a lot worse with an anonymous cryptocurrency. Not to say that I don’t think there shouldn’t be an anonymous cryptocurrency. If someone makes one that works, they make one that works. Maybe they get to exist for a little while as a honeypot or if they can operate outside the law successfully longer, but bitcoin itself shouldn’t be one. There should be something a level playing field for honest people to interact with sound money. And if they operate within the law, then they will have more than adequate privacy, just they will leave immutable evidence for every transaction that can be used as evidence to build a case against you committing a crime.

His claim is that all the people that are protesting the loudest about him being Satoshi are all the people that are engaged in dishonest business or that have a vested interest in there not being one singular global ledger but rather a whole myriad of alternative currencies that can be pumped and dumped against one another, have all kinds of financial instruments applied to them like futures and then have these exchanges and custodial services not doing any Know Your Customer (KYC) or Anti Money Laundering (AML) processes. Bitcoin SV was delisted by a number of exchanges recently after Craig launched legal action at some twitter crypto influencetalking heads who had continued to call him a fraud and then didn’t back down when the CEO of one of the biggest crypto exchanges told him to drop the case or he would delist his coin. The trolls of twitter all chimed in in support of those who have now been served with papers for defamation and libel and Craig even put out a bitcoin reward for a DOX on one of the people who had been particularly abusive to him on twitter. A big european exchange then conducted a twitter poll to determine whether or not BSV should be delisted as either (yes, it’s toxic or no) and when a few hundred votes were in favour of delisting it (which can be bought for a couple of bucks/100 votes). Shortly after Craig was delisted, news began to break of a US dollar stable coin called USDT potentially not being fully solvent for it’s apparent 1:1 backing of the token to dollars in the bank. Binance suffered an alleged exchange hack with 7000 BTC “stolen” and the site suspending withdrawals and deposits for a week. Binance holds 800m USDT for their US dollar markets and immediately once the deposits and withdrawals were suspended there was a massive pump for BTC in the USDT markets as people sought to exit their potentially not 1:1 backed token for bitcoin. The CEO of this exchange has the business registered out of Malta, no physical premises, the CEO stays hotel room to hotel room around the world, has all kind of trading competitions and the binance launchpad, uses an unregistered security to collect fees ($450m during the bear market) from the trading of the hundreds of coins that it lists on its exchange and has no regard for AML and KYC laws. Craig said he himself was able to create 100 gmail accounts in a day and create binance accounts with each of those gmail accounts and from the same wallet, deposit and withdraw 1 bitcoin into each of those in one day ($8000 x 100) without facing any restrictions or triggering any alerts or such.
This post could ramble on for ever and ever exposing the complexities of the rabbit hole but I wanted to offer some perspective on what’s been happening in the space. What is being built on the bitcoin SV blockchain is something that I can only partially comprehend but even from my limited understanding of what it is to become, I can see that the entirety of the crypto community is extremely threatened as it renders all the various alt coins and alt coin exchanges obsolete. It makes criminals play by the rules, it removes any power from the developer groups and turns the blockchain and the miners in to economies of scale where the blockchain acts as a serverless database, the miners provide computational resources/storage/RAM and you interact with a virtual machine through a monitor and keyboard plugged in to an ethernet port. It will be like something that takes us from a type 0 to a type 1 civilisation. There are many that like to keep us in the quagmire of corruption and criminality as it lines their pockets. Much much more can be read about the Cartel in crypto in the archive below. Is it possible this cartel has the resources to mount such a successful psychological operation on the cryptocurrency community that they manage to convince everyone that Craig is the bad guy, when he’s the only one calling for regulation, the application of the law, the storage of immutable records onchain to comply with banking secrecy laws, for Global Sound Money?

https://archive.fo/lk1lH#selection-3671.46-3671.55

Please note, where possible, images were uploaded onto the bitcoin sv blockchain through bitstagram paying about 10c a pop. If I wished I could then use an application etch and archive this post to the chain to be immutably stored. If this publishing forum was on chain too it would mean that when I do the archive the images that are in the bitstragram links (but stored in the bitcoin blockchain/database already) could be referenced in the archive by their txid so that they don’t have to be stored again and thus bringing the cost of the archive down to only the html and css.
submitted by whipnil to C_S_T [link] [comments]

Those large Bitcoin Cash transactions are not what you think they are

I've decided to take a look at these large transactions that occurred on Bitcoin Cash yesterday. I have analyzed them to see what they are doing, and it is actually kind of funny. Contrary to popular belief, those transactions are not preparation transactions for the attack presented by _chjj yesterday, and I will explain why below.
For starters, lets look at the large transactions. There are 7 of them: https://bch-bitcore2.trezor.io/tx/ac4849b3b03e44d5fcba8becfc642a8670049b59436d6c7ab89a4d3873d9a3ef, https://bch-bitcore2.trezor.io/tx/1bd4f08ffbeefbb67d82a340dd35259a97c5626368f8a6efa056571b293fae52, https://bch-bitcore2.trezor.io/tx/c0472d267c8d178804eefdddb348f2f7a8a95bf6a4152b952a5fb6bfa09cab2e, https://bch-bitcore2.trezor.io/tx/27cb862d9c4c7eaace8d901e89365f2e843572788b774b14e5675fd9107d6637, https://bch-bitcore2.trezor.io/tx/b87d1dc8c0f3b450f1c1a845a5561ad87d850173b852c6839de6eb04441dfc7f, https://bch-bitcore2.trezor.io/tx/fc3e3bbd49ad6a6e87e7220f380b24ae86e566b1d26d0e40fb5250e54a25dc2a, https://bch-bitcore2.trezor.io/tx/dbd3f7518111d679c1b229af71181c9395e3bf8c1370b6856376f391d25c883e. Each of these transactions has 31243 identical P2SH outputs of 1 satoshi each, and one change output. So at first glance, these look a lot like attack transactions for _chjj's attack. But looking closer, it looks like the first output of each transaction has been spent in https://bch-bitcore2.trezor.io/tx/36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d. Lets take a closer look at that transaction
36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d is strangely large for a transaction spending P2SH outputs, it is nearly 70 kB but only spends 7 inputs. This means that those inputs must be massive, almost 10 kB each, which, incidentally, is the size limit for a scriptSig. Unfortunately block explorers based on insight aren't showing us the scriptSig, so this will need to be decoded with a node.
Here is the decoded output (I have cut out a few things because it is too large):
{ "hex": , "txid": "36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d", "hash": "36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d", "size": 69651, "version": 2, "locktime": 0, "vin": [ { "txid": "ac4849b3b03e44d5fcba8becfc642a8670049b59436d6c7ab89a4d3873d9a3ef", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884cab492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e87", "hex":  }, "sequence": 4294967295 }, { "txid": "1bd4f08ffbeefbb67d82a340dd35259a97c5626368f8a6efa056571b293fae52", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e  492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e 788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c89492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e87", "hex":  }, "sequence": 4294967295 }, { "txid": "c0472d267c8d178804eefdddb348f2f7a8a95bf6a4152b952a5fb6bfa09cab2e", "vout": 0, "scriptSig": { "asm": "57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274  57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274 7888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8f57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d61727487", "hex":  }, "sequence": 4294967295 }, { "txid": "27cb862d9c4c7eaace8d901e89365f2e843572788b774b14e5675fd9107d6637", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869  492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8b492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f73686987", "hex":  }, "sequence": 4294967295 }, { "txid": "b87d1dc8c0f3b450f1c1a845a5561ad87d850173b852c6839de6eb04441dfc7f", "vout": 0, "scriptSig": { "asm": "4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b  788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c904920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b87", "hex":  }, "sequence": 4294967295 }, { "txid": "fc3e3bbd49ad6a6e87e7220f380b24ae86e566b1d26d0e40fb5250e54a25dc2a", "vout": 0, "scriptSig": { "asm": "48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978  48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8b48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d697887", "hex":  }, "sequence": 4294967295 }, { "txid": "dbd3f7518111d679c1b229af71181c9395e3bf8c1370b6856376f391d25c883e", "vout": 0, "scriptSig": { "asm": "5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65  5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65 7888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c935468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d6587", "hex":  }, "sequence": 4294967295 } ], "vout": [ { "value": 0.00000000, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 f6c403dd1f02211d21db137cd219e156ce7e5ca7 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a914f6c403dd1f02211d21db137cd219e156ce7e5ca788ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "1PVn3ZM5mUW9n9eVXRAedUbpJdAMCG7KXS" ] } } ], "blockhash": "000000000000000005a42e167af40866487ceda82863614c409d67d1239aff19", "confirmations": 174, "time": 1505044920, "blocktime": 1505044920 } 
Well that's interesting. Lets find the redeemScript of the first transaction and decode it:
bitcoin-cli decodescript 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884cab492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e87 { "asm": "OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e OP_EQUAL", "type": "nonstandard", "p2sh": "39BLXfKysaXNuGuBrgT7b9WfaiBMw2VMZf" } 
Well that is a very interesting script. So lets explore what this script is doing. OP_OVER means that the top stack item is copied, e.g. x1 x2 -> x1 x2 x1. OP_EQUALVERIFY means that the top two stack items must be equal to each other and they are consumed. There are 55 OP_OVER OP_EQUALVERIFY pairs here, which means that something will need to be repeated 55 times. At the end of the script, we see this byte string and then OP_EQUAL. That means that whatever is being repeated much match this byte string in order for this script to validate. The scriptSig that this redeemScript comes from does exactly that, the byte string at the bottom of the script are repeated a bunch of times. And it looks like all of the 7 scripts do basically the same thing, but with different length byte strings. Now lets see what our byte strings are.
492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e 57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274 492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869 4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b 48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978 5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65 
Looking more closely at these scripts, we see that there are repeating sequences, and they are different lengths. This means that it isn't just random garbage. Well the first thing to try is to see if this hex results in any ascii, and what do you know, this is what we get for the first string:
I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain 
Huh. That's interesting. I think someone is being mocked. Lets see what the rest are:
I will not use assert(0) for input validation I will not use assert(0) for input validation I will not use assert(0) for input validation Writing gibberish equations on a blackboard does not make me look smart Writing gibberish equations on a blackboard does not make me look smart I will not worship a false satoshi I will not worship a false satoshi I will not worship a false satoshi I will not worship a false satoshi I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank High explosives and mail don't mix High explosives and mail don't mix High explosives and mail don't mix High explosives and mail don't mix They are laughing at me, not with me They are laughing at me, not with me They are laughing at me, not with me They are laughing at me, not with me 
So it seems that someone is just mocking you all. They have put these mocking strings in a redeemScript and require you to repeat them in order to spend them. This kind of reminds me of Bart Simpson performing his punishment of writing sentences over and over on a chalkboard. The other thing that this does is that in order to clean up the thousands of outputs, you will need to spend 10 kB per output, which will severely bloat your blockchain. Or you can just leave them in the UTXO set which will bloat the UTXO set with dust. But what to do with these is something you all will need to deal with, I'm just here to see what was up with these transactions.
As for why these transactions don't work for _chjj's attack, they require that the spending transactions be very large. But that is not ideal because for that attack to work, the spends need to be very small so that more spends can fit in one block which will increase memory usage. These transactions are not good for that since you can only fit a much smaller number of transactions in a block so the memory blow up is way less.
Edit: I don't support Bitcoin Cash, which is why I say that this is "your problem". I just thought this was interesting as it looked like it could impact Bitcoin as well, which is why I investigated this.
submitted by achow101 to btc [link] [comments]

HACK BITCOIN Bitcoin Generator 2020 Bitcoin Wallet Hack FREE CryptoCurrency Without Invest How to Use #Cryptotab Script 14 BTC #Bitcoin Hack 2020 FREE BITCOIN CRYPTOTAB SCRIPT 2020 , 14 BTC WORKING AND LEG FREE BITCOIN CRYPTOTAB SCRIPT 2021 14 BTC WORKING 100% ... How to Hack Free 1 Bitcoin with Proof Working Review - YouTube

Bitcoin Block Explorer - Blockchain. Like paper money and gold before it, bitcoin and ether allow parties to exchange value. Unlike their predecessors, they are digital and decentralized. For the first time in history, people can exchange value without intermediaries which translates to greater control of funds and lower fees. Search You may ... About open source bitcoin wallet. txid.io is a fork of Coinb.in Wallet. Compatible with bitcoin core. Wallet code itself cutted out, improved manual transaction processing, Double-spending tool added. Legacy, Segwit and Bech32 addresses are supported. txid.io has been updated at 2019-03-17, BCC and BTG removed and no longer supported. “txid” = transaction ID ... The amount of bitcoin: bitcoin value in satoshis (satoshi = the smallest denomination of bitcoins — equivalent to 100 millionth of a bitcoin) 2. The locking ... However, the TXID corresponding to the output must be placed at some point before the TXID corresponding to the input. This ensures that any program parsing block chain transactions linearly will encounter each output before it is used as an input. If a block only has a coinbase transaction, the coinbase TXID is used as the merkle root hash. If a block only has a coinbase transaction and one ... A Transaction ID or TXID is the double SHA256 hash or SHA256d of a serialized Bitcoin transaction.TXIDs are not part of the the transaction, as the hash cannot be generated until the transaction is complete. A TXID and VOUT (or prevout_n) index are used to reference UTXOs when they are added to a transaction as an input.. Data

[index] [2780] [50157] [38464] [11803] [7138] [34004] [1114] [845] [9069] [19653]

HACK BITCOIN Bitcoin Generator 2020 Bitcoin Wallet Hack FREE CryptoCurrency Without Invest

TXID: https://bit.ly/3aCcc2l Free bitcoins giveaway of 0.60 BTC for 1 winner this week i will choose if qualified. how to join? 1. Watch this video all the way through. 2. Like and share this ... #CRYPTOTAB#HACK #SCRIPT 2020 14 BTC #WORKING #REVIEW #FREE #BITCOIN Today i will review the script that proclaimed to be generating bitcoins quickly. Is it L... This is my final result txid from the script. ... As for an example,i was able to find one blockchain block what was decryped in 2 minutes and the value was about 0.3 bitcoins. 🙂 Why should I ... Hello in this review i will shown how the hack works and earns you 1 Bitcoin in less than an hour, watch till end to learn how. Proof TXID: https://www.block... Here is the tutorial how to use the bitcoin hack cryptotab script in few simple steps. watch the full video to learn how to generate 14 btc with the script. This is my final result txid from the ...

#