Transaction - Bitcoin Wiki

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]

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]

A reminder why CryptoNote protocol was created...

CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013
1 Introduction
“Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards.
Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the net- work users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project.
In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash.
2 Bitcoin drawbacks and some possible solutions
2.1 Traceability of transactions
Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta:
Untraceability: for each incoming transaction all possible senders are equiprobable.
Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person.
Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the trans- actions that take place between the network’s participants are public, any transaction can be unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient.
It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database.
Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5].
2.2 The proof-of-work function
Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “one- CPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system.
The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7].
This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs.
Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes.
One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place.
2.3 Irregular emission
Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure.
When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be)
2.4 Hardcoded constants
Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artificially introduced block size limit.
Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5 Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature.
Read the rest of the white paper here: https://cryptonote.org/whitepaper.pdf
submitted by xmrhaelan to CryptoCurrency [link] [comments]

As part of my ongoing effort to develop stupid shit for Garlicoin, I present you: W-addresses!

“Wait, what?!” I hear you asking? Well…(buckle up, this is another one of my technical posts that goes on, and on…)
For some time now, I have been using native SegWit (Pay-to-Witness-Public-Key-Hash, P2WPKH) transactions for myself. Mostly because they have a 75% fee subsidy on signature data (which comes out on ~50% fee subsidy on the entire transaction, depending on the type of transaction) and I am dutch after all ;-)
It turns out that Garlicoin Core kind of supports them and kind of does not. If you manually register the transaction redeem script to your wallet (using the addwitnessaddress command) it will start recognizing them on the blockchain but gets kind of confused on how to deal with them, so it registers them all as ‘change’ transactions. Still, this means you can receive coins using these types of transactions and pay with them in all ways you can with regular Garlicoins, except your transactions are cheaper.
However, sending coins using native SegWit is quite a hassle. You can basically only do it by creating your own raw transactions (createrawtransaction, edit it to make it native SegWit, fundrawtransaction, signrawtransaction, sendrawtransaction). On top of this, any change address the wallet creates are still legacy/normal Garlicoin addresses, so you will end up with a bunch of unspent transaction outputs (UTXOs) for which you have to pay full fee anyway. I decided we (I) could do better than this.
But first a few steps back. What is this native SegWit anyway and weren’t people already using SegWit? Wasn’t there a user that just after mainnet launched accidentally made a SegWit transaction? So what the hell am I talking about?
To understand this, you will need to know a few things about what SegWit is and how Bitcoin Garlicoin transactions work in general. Note that this bit gets really technical, so if you are not interested, you might want to skip ahead. A lot.
First thing to understand is that addresses are not really a thing if you look at the blockchain. While nodes and explorers will interpret parts of a transaction as addresses, in reality addresses are just an abstraction around Bitcoin Script and an easy way send coins instead of asking people “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?”. Let’s look at an example: say I ask you to send coins to my address GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxC. What ends up happening is that you send coins out a transaction where you say that the coin are locked in the blockchain and can only be unlocked by successfully executing the following script:
OP_DUP OP_HASH160 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050 OP_EQUALVERIFY OP_CHECKSIG
Now, without getting too technical, this means something like this:
As you can see, the address actually represents a well-known piece of script. This start making sense if you look at the decoded address:
26 4E9856671C3ABB2F03B7D80B9238E8F5ECD9F050 F8F1F945
The first byte (0x26, or 38) is the version byte. This tells the clients how the interpret the rest of the script. In our case 38 means Pay-to-Public-Key-Hash (P2PKH), or in other words the script mentioned above. The part after that is just the SHA1 hash of the public key and the final 4 bytes are a checksum to verify you did not make a typo when entering the address.
Enter SegWit. What SegWit exactly is depends on who you are talking to, however it mostly is a different transaction format/protocol. The main change of SegWit is that signature data is not longer included in the transaction (fixing transaction malleability). Instead transaction data is sent separate from the transaction itself and outside of the (main) blocks.
This is not really that much of an issue, except for the fact that people wanted to enable SegWit as a soft-fork instead of a hard-fork. This means that somehow unupgraded nodes needed a way to deal with these new transaction types without being able to verify them.
The solution turned out to be to make use of an implementation detail of Bitcoin Script: if a piece of script executes without any errors, the last bit of data determines whether the transaction is valid (non-zero) or invalid (zero). This is what they used to implement SegWit.
So what does this look like? Well, you might be surprised how simple a P2WPKH (the SegWit way of doing a P2PKH transaction) script looks:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Yes. That’s it.
The first byte is the Witness program version byte. I.e. it tells you how the other data should be interpreted (very similar to how addresses work). Then there is the hash of the public key. As you can see, SegWit does not actually use Bitcoin Script. Mostly because it needs old nodes to ‘just accept’ its transactions. However interestingly enough, while the transaction format changed, the transaction data is pretty much the same:
This means that these kind of SegWit transactions need a new way of addressing them. Now, you might think that this is where the ‘3’ addresses on Bitcoin or the ‘M’ addresses on Garlicoin come in. However, that is not the case.
These addresses are what are called Pay-to-Script-Hash (P2SH) addresses. There scrypt is like this:
OP_HASH160 35521b9e015240942ad6b0735c6e7365354b0794 OP_EQUAL
Huh? Yeah, these are a very special type of transactions, that kind of go back to the “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?” issue.
These transactions are a way to have arbitrary smart contracts (within the limits of Bitcoin Script) to determine whether a transaction output can be spend or not without the sender of the coins having to deal with your scripts. Basically they use a hash of the “real” script, which whoever owns the coins has to provide when they want to spend them, as well as the specific inputs required for a script. This functionality is for example used in multi-signature (MultiSig) wallets, without requiring someone sending money to these wallets having to deal with random bits of information like how many signatures are required, how many private keys belong to the wallet, etc.
This same method is used for so called P2SH-wrapped SegWit transactions (or P2SH-P2WPKH). Consider our earlier SegWit transaction output script:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Or 00144e9856671c3abb2f03b7d80b9238e8f5ecd9f050 in low-level hex. The P2SH script for this would be:
OP_HASH160 a059c8385124aa273dd3feaf52f4d94d42f01796 OP_EQUAL
Which would give us address MNX1uHyAQMXsGiGt5wACiyMUgjHn1qk1Kw. This is what is now widely known and used as SegWit. But this is P2SH-wrapper SegWit, not native or "real" SegWit. Native would be using the data-only SegWit script directly.
The reason for using the P2SH variant is mostly about compatibility. While SegWit nodes understand these newer transactions, they were never officially assigned a way to convert them to addresses. Hence, they will show up in blockchain explorers as Unparsed address [0] or something similar. Then there is also the whole thing about old nodes and relaying non-standard transactions, but I will skip that bit for now.
Bitcoin is using/going to use new BECH32 addresses for native SegWit transactions, which looks completely different from the old Base-58 encoded addresses. However, right now, especially on Garlicoin, you cannot really use them and have to use the P2SH variant. But why not use these new cool transaction types without having to deal with all that useless and complex P2SH wrapping, right? Right? …
Well, I went ahead and gave them their (unofficial) address space.
So last thursday I made some changes to Garlicoin Core, to make dealing with these native SegWit transaction a lot easier. In short, the changes consist of:
  • Assigning address version byte 73 to them, in other words addresses starting with a ‘W’ (for ‘witness’).
  • Allowing the use of ‘W’ addresses when sending coins.
  • Make the wallet automatically recognize the SegWit transaction type for any newly generated address.
  • Add the getwitnessaddress command, which decodes a version 38 ‘G’ address and re-encodes the same data as a version 73 ‘W’ address (unfortunately it is not as simple as just changing the first letter). Note that this can be any address, not just your own. (That said, you should not send SegWit transactions to people not expecting them, always use the address given to you.)
  • Added the usewitnesschangeaddress configuration setting, to automatically use the cheaper SegWit transaction outputs for transaction change outputs.
  • (Since using the 'W' address only changes the way coins are sent to you and the private key used for both transaction types is the same:) When receiving coins they show all up under the original ‘G’ address, whether a SegWit or legacy/normal transaction type was used. The idea behind this is that both are actually the same "physical" (?) address, just to the way to coins to it differs. Address book entries are also merged and default to the ‘G’ address type.
Anyway, I don’t expect people to actually use this or it getting merged into mainline or anything. I actually mostly made this for myself, but thought I should share anyway. I guess it was also a nice opportunity to talk a bit about transactions and SegWit. :-)
Btw, I also changed my pool to allow mining to ‘W’ addresses, to make coin consolidation cheaper (due to the SegWit fee subsidy). Right now this is only for instant payout though (as I would have to update the wallet node the pool is using for daily payout, which I haven’t done yet).
Also note that you can actually mine to a ‘W’ address (and therefore use cheaper transactions) even if you are running the official, non-patched version of Garlicoin Core, however:
  • You need to manually convert your ‘G’ address to a ‘W’ address.
  • You need to run the addwitnessaddress command (Help -> Debug Window -> Console) to make the wallet recognize SegWit transactions (you can ignore the ‘M’ address it produces).
  • The wallet might get a bit confused as it does not really understand how it got the coins. This is mostly notable in the ‘Coin Control’ window if you have it enabled. Apart from that everything should still work though.
submitted by nuc1e4r5n4k3 to garlicoin [link] [comments]

Bitcoin 2010 vulnerability

Hello I am entering in this world and always curios and curious to analize vulnerabilities. Here there is the 2010 bitcoin vulnerability which I didn't full understand, can someone help me to understand?
https://bitcointalk.org/index.php?topic=822.0
The "value out" in this block #74638 is quite strange:
{"hash" : "0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c","ver" : 1,"prev_block" : "0000000000606865e679308edf079991764d88e8122ca9250aef5386962b6e84","mrkl_root" : "618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e","time" : 1281891957,"bits" : 469794830,"nonce" : 28192719,"n_tx" : 2,"tx" : [{"hash" : "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca","ver" : 1,"vin_sz" : 1,"vout_sz" : 1,"lock_time" : 0,"in" : [{"prev_out" : {"hash" : "0000000000000000000000000000000000000000000000000000000000000000","n" : 4294967295},"coinbase" : "040e80001c028f00"}],"out" : [{"value" : 50.51000000,"scriptPubKey" : "0x4F4BA55D1580F8C3A8A2C78E8B7963837C7EA2BD8654B9D96C51994E6FCF6E65E1CF9A844B044EEA125F26C26DBB1B207E4C3F2A098989DA9BA5BA455E830F7504 OP_CHECKSIG"}]},{"hash" : "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9","ver" : 1,"vin_sz" : 1,"vout_sz" : 2,"lock_time" : 0,"in" : [{"prev_out" : {"hash" : "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39","n" : 0},"scriptSig" : "0xA87C02384E1F184B79C6ACF070BEA45D5B6A4739DBFF776A5D8CE11B23532DD05A20029387F6E4E77360692BB624EEC1664A21A42AA8FC16AEB9BD807A4698D0CA8CDB0021024530 0x965D33950A28B84C9C19AB64BAE9410875C537F0EB29D1D21A60DA7BAD2706FBADA7DF5E84F645063715B7D0472ABB9EBFDE5CE7D9A74C7F207929EDAE975D6B04"}],"out" : [{"value" : 92233720368.54277039,"scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG"},{"value" : 92233720368.54277039,"scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG"}]}],"mrkl_tree" : ["012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca","1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9","618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e"
]
}
This could be a serious problem. Bitcoin's printblock also shows it:
CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba, nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)vMerkleTree: 012cd8 1d5e51 618eba
I have a serie of questions:
  1. What is this language? which kind of language is it?
  2. the POCO i this:
''Essentially, the code for checking Bitcoin transactions did not work if outputs were so large that they overflowed when summed, and a hacker figured this out and took advantage of it. There is supposed to be a fixed maximum supply of 21 million Bitcoin, but the hacker, in a single transaction, created 8,784 times more Bitcoins than ever should exist.''

What does it mean ''did not work if outputs were so large'' ? The output of what?
so large that they overflowed when summed ...
what does this mean? can you make an example to let me understand?
The sum of what + what? And why does this sum caused a bufferoverflow? A buffer overflow isn't it when for example there is an array and then there is no definied lenght for the array and you put in more than the array may own? In this case from what is the buffer overflow caused by?
Also interstead in what does this string mean:
vMerkleTree: 012cd8 1d5e51 618eba
what does this mean?
submitted by luchins to HowToHack [link] [comments]

Seneca Smart Contract Comparison

Seneca Smart Contract Comparison
https://preview.redd.it/6duhj3r1igi11.png?width=405&format=png&auto=webp&s=453e264b8b855b4cbe6e87c7abd607c7cacaea66

Which of these three smart contracts makes the most sense to you?

We wrote Seneca to be an evolution of software development. Those who already know some programming can reuse the concepts that they know to pick up this new idea of public code. Comparatively, languages such as Solidity and Bitcoin Script require extensive knowledge of blockchain and their limitations to use effectively.
For example, this is how you invoke a method on a smart contract in Ethereum:
0xa9059cbb00000000000000000000000071511814fc09ac85b9d5d0d995e78a48049644c5000000000000000000000000000000000000000000000001f0e0a209aad60000 
This payload can be broken up as the following components:
MethodID: 0xa9059cbb [0]: 00000000000000000000000071511814fc09ac85b9d5d0d995e78a48049644c5 [1]: 000000000000000000000000000000000000000000000001f0e0a209aad60000 
For the standard developer, how do you begin to understand what this means? How do you know what the MethodIDcorrelates to? What are the arguments? What are their values? The serialization mechanisms of Ethereum are insanely obtuse.
For Bitcoin Scripts, it's even better. Here is an example of the standard transaction Bitcoin Script (yes, believe it or not, every transaction is actually a smart contract on Bitcoin!):
76a962e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac 
Which translates to the Script of:
OP_DUP OP_HASH160 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 OP_EQUALVERIFY OP_CHECKSIG 
Compare these two methods to Seneca:
import tau tau.send('stu', 100) 
Check out Seneca on Github and let us know what you think!
Telegram (ENG|CHN|NL)

submitted by lamden to lamden [link] [comments]

BIP 199 HTLC initial stack state

Hey fellow bitcoiners and redditors

I'm trying to understand how HTLCs (Hashed Time-Locked Contracts) can be implemented in Bitcoin and BIP-199 turned out to be the best resource for that purpose.

TL;DR
Question answered!
  1. Does the stack need to feature the secret/image twice in the OP_IF case? => call the script with [pubKey, signature, 1]
  2. How can the OP_ELSE flow ever be executed successfully (since this requires the stack to be empty, but [pubKey, signature] are required for OP_CHECKSIG at the very end of the script )? => call the script with [pubKey, signature, 0]

Full story
This is the example HTLC script I copied from BIP-199:
OP_IF
[HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160
OP_ELSE
[TIMEOUTOP] OP_DROP OP_DUP OP_HASH160
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

IF-Case (seller can claim the buyers deposited BTCs)
TL;DR: detailed debug log of this path. Question: Can I avoid providing the preimage twice?

Before running this script, the preimage should be known and the stack should looks:
preimage
preimage
pubKey
signature

  • So since the stack is not empty, it will jump into the OP_IF clause.
    • the OP_IF will pop the top value => stack is now: [preimage, pubKey, signature]
  • [HASHOP] will hash the preimage
    • the preimage on the stack will, be replaced by the image => stack: [image, pubKey, signature]
  • digest (a synonym for image) will be pushed
    • => stack: [image, image pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: image == image => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_DUP will duplicate the pubKey, => stack: [pubKey, pubKey, signature]
  • OP_HASH160 will double-hash the pubKey => stack: [p2pkhAddress, pubKey, signature]
  • represents the p2pkhAddress => stack: [p2pkhAddress, p2pkhAddress, pubKey, signature]
  • OP_EQUALVERIFY checks the two top items for equality: p2pkhAddress == p2pkhAddress => true
    • ...and removes them, if they are equal => stack: [pubKey, signature]
  • OP_CHECKSIG checks the signature
  • Done, all fine!
  • Question: This flow requires the secret to be on the stack twice before starting the script; Can I avoid that somehow?

ELSE-Case (buyer claims refund of his/her deposited BTCs)
Since the script runs an OP_CHECKSIG at the very end. This means the stack has to contain at least [pubKey, signature] before the execution pointer moves to OP_IF. However, OP_IF returns true "If the top stack value is not False". So how can the script possibly ever execute the OP_ELSE flow?

Disclaimer
  • My mother tongue is not English, please forgive me any mistakes. :)
  • I'm just getting started with BTC scripting, please forgive me any noob mistakes.
  • I also searched the whole stackexchange/search engine/reddit/github universum for this issue, obivously without success.
PS - buy Bitcoin :)
submitted by redditeraya to Bitcoin [link] [comments]

VGO will be launched on LOEX Global at 20:00 on July 2.

Dear LOEX users: Loex Global will soon launch VGO (VirtualGoodsToken) and open VGO/USDT trading pairs. The specific time is as follows: Loex Global will provide VGO charging service at 14:00 Singapore time on July 2.VGO/USDT trading market will be opened at 20:00 on July 2.
Token Introduction Token Name:VirtualGoodsToken Abbreviation:VGO Issue Supply:2.1 billion Website:http://vgo.life Official Website:http://vgo.life/vgo_white_paper.pdf Project Introduction:VGO (VirtualGoodsToken, Chinese for Virtual Goods Pass) addresses many of the limitations of the Bitcoin system as a transactional, everyday currency designed to provide a scalable and sustainable alternative to Bitcoin. VGO is a bitcoin spread project. The algorithm mainly includes SHA256 and RIPEMD160. Bitcoin combines the application of these two hash algorithms into two functions: hash256(d)=sha256(sha256(d)) and hash160(d)= Ripemd160(sha256(d)), where d is the byte array to be hashed, and the two generate hexadecimal values ​​of 256 bits (32 bytes) and 160 bits (20 bytes), respectively. Hash256 is mainly used to generate identifiers, such as block ID, transaction ID, etc., and hash160 is mainly used to generate VGO addresses. The above algorithm can be developed on any computer and never requires specialized mining equipment. VGO enables efficient transaction confirmation. And through the VVM (VGO Virtual Machine) smart contract virtual machine to carry out smart contract encoding operation, providing a faster, more scalable blockchain platform, more suitable for daily trading use.
Risk Reminder Investing in digital assets comes with high risks due to huge price fluctuations. Before investing, please have a full understanding of all the risks of investing in digital assets and be prudent of your own investment decisions.
Enjoy your trading on Loex Global! Follow us on: www.loex.io
Loex Global Related Community
Official reddit:https://www.reddit.com/useLOEXCHANGE
Official Twitter:https://twitter.com/LoexGlobal
Official telegraph group:http://t.me/loexmember
Official BQI community:https://t.bqi.com/exchange/loex.html
Official Weibo :https://weibo.com/6870211274/profile?rightmod=1&wvr=6&mod=personnumber
Loex Global June 28, 2019
submitted by LOEXCHANGE to u/LOEXCHANGE [link] [comments]

Trying to get a deeper understanding of atomic swaps

Hi together,
I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.
So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.
Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)
At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.
I did the same for LTC and found about 400 HTLCs.
As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.
* Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.
My questions now are the following:
I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.
Type 1: sha256 secret, length=97byte
63 if 82 size 01 data1 20 88 equalverify a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 2a: sha256 secret, length=94byte
63 if a8 sha256 20 data32  76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 68 endif 
Type 2b: sha256 secret, length=93byte
63 if a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 3: ripemd160 secret, length=81byte
63 if a6 ripemd160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 4a: hash160 secret, length=86byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify 82 size 01 data1 21 -> 33 88 equalverify a9 hash160 14 data20  87 equal 68 endif 
Type 4b: hash160 secret, length=82byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 5a: hash160 secret, length=81byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 5b: hash160 secret, length=78byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 01 data1  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 6: hash160 secret, length=79byte
63 if 54  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 7: multiple ripemd160 secrets, length=80 + n*23byte
63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 21 data33  ac checksig 68 endif 
Type 8: multiple ripemd160 secrets, length=81 + n*23byte
74 depth 60 16 87 equal 63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  67 else 03 data3  b1 checklocktimeverify 75 drop 21 data33  68 endif ac checksig 
[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480
submitted by noobWithAComputer to Bitcoin [link] [comments]

Unconfirmed Bitcoin Problem

I posted this on another forum and was referred here to try to get a hold of a Bitcoin Developer to help solve my problem. IMO, there is a bug in the blockchain. Either the blockchain is reporting transactions to me that never existed, or I have unconfirmed transactions in my ledger that need to be confirmed and are not confirming. The transactions are from 2013 and 2014 when I first started mining.
I am running the latest version of Bitcoin Core, and have fully synced through the blockchain.
Background: Years ago I mined a little bit of BTC, and forgot about it. With the prices going astronomical I wanted to open my old wallet up and sell some. I opened it in Bitcoin Core and I can see a bunch of transactions, but they're all unconfirmed and my balance is reporting zero.
Address: 1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4
One of many transaction id's:
Status: 0/unconfirmed, not in memory pool Date: 1/23/2014 22:01 Credit: 0.10630472 BTC Net amount: +0.10630472 BTC Transaction ID: c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e Transaction total size: 225 bytes Output index: 0
When I try to rebroadcast the raw transaction I get this...
Missing parents for c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e while inserting: [c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c]
If I decode it I get this...
{ "lock_time":0, "size":225, "inputs":[ { "prev_out":{ "index":0, "hash":"c677f8172824b4bb761f0ce51e23235f4a6613c62e74e847936f95440fae6b6c" }, "script":"47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60" } ], "version":1, "vin_sz":1, "hash":"c16587ae806c2392635a20843a78f8f6a1275c6990a797f8266e3b9d8a29bd1e", "vout_sz":2, "out":[ { "script_string":"OP_DUP OP_HASH160 7336d1277adaf305dddde5cedc686bb1e4988bda OP_EQUALVERIFY OP_CHECKSIG", "address":"1BWCNpA3MGYHS3sbbVpGW7jY1Ean1Y3sX4", "value":10630472, "script":"76a9147336d1277adaf305dddde5cedc686bb1e4988bda88ac" }, { "script_string":"OP_DUP OP_HASH160 95a28eec6c32896699df4ca36c880d7e42e504c5 OP_EQUALVERIFY OP_CHECKSIG", "address":"1EeCRLCksdBRJ7SUkAAFKk1TssVv62hoTQ", "value":89379528, "script":"76a91495a28eec6c32896699df4ca36c880d7e42e504c588ac" } ] }
Does this offer any more clues?
This is the raw transaction in Hex...
01000000016c6bae0f44956f9347e8742ec613664a5f23231ee50c1f76bbb4242817f877c6000000006a47304402204f1602b609027990a8e17355bdb9d967882aed3ac85e06c9311d33a3228ba9d90220097941a24457d36508f8d17e94400184c849f44c48296aab09e4deb9d23e4e2f012103db4cc04dac3ee0cb4ab0afc108eb1f398ab659be127240a672b1abe139f84b60ffffffff024835a200000000001976a9147336d1277adaf305dddde5cedc686bb1e4988bda88acc8d25305000000001976a91495a28eec6c32896699df4ca36c880d7e42e504c588ac00000000
I really need help ASAP so I can sell some coins. How do I resolve this issue, or at the bare minimum how do we correct the blockchain so this issue doesn't affect others? Any help is appreciated!
submitted by AmericasLastHope to Bitcoin [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.
submitted by achow101 to Bitcoincash [link] [comments]

Deep Analysis Of Qtum's Account Abstraction Layer (Qtum AAL)

Analysis of Qtum Account Abstraction Layer (AAL) Implementation
https://mp.weixin.qq.com/s?__biz=MzI2MzM2NDQ2NA==&mid=2247485993&idx=1&sn=57ad353fd13b10ab85b62d693f86b1f5&chksm=eabc4036ddcbc9208ea766274defc543a9238967c5d2c541e615906a25a2962d75c4c6bd2c2b&scene=21#wechat_redirect
Qtum is designed with a bitcoin UTXO-based account model and implements a smart contract that supports the EVM specification, which is done through the Account Abstract Layer (ALA). AAL adapts the UTXO account to the EVM contract account, so that the AAL can use the UTXO transaction output to create a smart contract on the chain, send the transaction to the contract account to trigger the execution of the contract, and the AAL will eventually execute after the execution. The results were processed and adapted to UTXO. Thanks to the AAL, contract developers don't need to care about the UTXO transformation details related to contract operations, they can use the features of EVM to develop and are compatible with existing Ethereum smart contracts. This paper first analyzes the working process of AAL by interpreting the implementation code from UTXO transaction to smart contract execution.
 
1. UTMO transaction added script opcode
Qtum has added three opcodes OP_CREATE, OP_CALL and OP_SPEND for UTXO trading scripts to provide operational support for conversion between UTXO and EVM account models. These opcodes are defined in the opcodetype enumeration type:
 
Enum opcodetype{
......
OP_CREATE = 0xc1,
OP_CALL = 0xc2,
OP_SPEND= 0xc3,
......
}
 
These three opcodes have the following effects:
OP_CREATE is used to create smart contracts;
OP_CALL is used for the execution of the contract;
OP_SPEND is used for the cost of the contract balance.
In order to identify and process the transactions controlled by these opcodes during the block generation process, the HasCreateOrCall() and HasOpSpend() functions are added to the class CTransaction for UTXO model transactions for use in the mempool in the new block. The transaction is processed and the corresponding processing is added to the EvalScript() function of the script opcode parsing.
 
2. Conversion of UTXO transactions to EVM model transactions
When generating new blocks, in addition to regular parameter legality, consensus rules, DDOS attack checks, etc. for UTXO transactions, it is also necessary to use the opcode check function HasCreateOrCall() to determine whether the transaction output contains OP_CREATE or OP_CALL, which respectively correspond to EVM needs to perform contract creation or contract calls. This section has the following processing:
 
2.1 Performing account parameter extraction for EVM model
The contract uses the data, gasPrice, gasLimit, and VM version parameters in the execution of the EVM. These parameters are sent by the RPC call sendtocontract. The sendtocontract generates a UTXO transaction and uses the OP_CALL opcode in the transaction output. Will be broadcast to the blockchain network. The adaptation from UTXO to EVM in AAL is implemented by the QtumTxConverter class, in which the member functions extractQtumTransactions() and parseEthTXParams() of the class complete the parameter extraction for all such UTXO transaction output. The code fragment is as follows:
 
Dev::Address receiveAddress;
Valtype vecAddr;
If (opcode == OP_CALL)
{
vecAddr = stack.back();
Stack.pop_back();
receiveAddress = dev::Address(vecAddr);
}
Valtype code(stack.back());
Stack.pop_back();
Uint64_t gasPrice = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
Uint64_t gasLimit = CScriptNum::vch_to_uint64(stack.back());
Stack.pop_back();
VersionVM version(CScriptNum::vch_to_uint64(stack.back()));
Stack.pop_back();
Return EthTransactionParams{version, dev::u256(gasLimit), dev::u256(gasPrice), code,
receiveAddress }
 
The above code first judges that if the opcode is OP_CALL, the contract with the address vecAddr has been created, so it is directly converted into the address of the EVM format receiveAddress, otherwise it is OP_CREATE, the corresponding contract is created, there is no such field, so no extraction is done. Next, the data, gasPrice, gasLimit, and VM version are extracted in turn, which are all essential parameters for the EVM to execute bytecode.
 
2.2 Transaction conversion of the EVM account model
Transaction conversion is done through the function createEthTX() of the QtumTxConverter class. The QtumTransaction type transaction is created using the parameters extracted in the previous step and the UTXO transaction output vout. Since QtumTransaction is derived from the dev::eth::Transaction class in EVM, the QtumTransaction class is supported by operations related to EVM execution.
 
QtumTransaction txEth;
If ( etp.receiveAddress == dev::Address() ) {
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
Etp.code, dev::u256(0));
}
Else{
txEth = QtumTransaction(txBit.vout[nOut].nValue, etp.gasPrice, (etp.gasLimit *
Etp.gasPrice),
etp.receiveAddress, etp.code, dev::u256(0));
}
Dev::Address sender(GetSenderAddress(txBit, view));
txEth.forceSender(sender);
txEth.setHashWith(uintToh256(txBit.GetHash()));
txEth.setNVout(nOut);
 
First, the code etp.receiveAddress == dev::Address() determines whether the contract is not in the EVM state and needs to be newly created or the contract already included in the EVM state. The only difference is the contract address. Then, the QtumTransaction() constructor completes some of the transaction parameter constructs, the next statement extracts the sender of the transaction, and then sets the transaction HASH. A UTXO transaction supports multiple inputs and outputs. Qtum's AAL design takes this into account, so AAL supports a transaction output containing UTXO accounts and contract accounts. The last set nOut indicates that the nOut output of the transaction is sent to the smart contract. , so this output will trigger contract execution. In this way, the transaction conversion is completed according to the EVM account model.
 
3. Contract execution and UTXO conversion of execution results
The execution of the contract changes state (managed by the QtumState class's instantiated object globalState). For the contract state, Qtum follows the EVM definition, so it is compatible with all EVM-compliant smart contracts. But the transfer of the account amount, Qtum made a UTXO conversion, which means that the smart contract and the ordinary UTXO model account can complete the interaction, which is an important part of AAL to achieve UTXO support smart contract. The following is a brief introduction to the conversion process of contract execution and status results.
 
3.1 Contract execution environment construction and contract execution
The execution of the contract is a critical step in the processing of the contract, directly affecting the state of the contract. The implementation of the EVM to the contract bytecode is implemented by the ByteCodeExec class. The main function is performByteCode(). The main process of this step is to use the transaction parameters extracted above to build the virtual machine execution environment, and then complete the execution of the contract, the code is as follows:
 
For(QtumTransaction& tx : txs){
Dev::eth::EnvInfo envInfo(BuildEVMEnvironment());
Std::unique_ptr
Se(dev::eth::ChainParams(dev::eth::genesisInfo(dev::eth::Network::HomesteadTest)).
createSealEngine());
If(!tx.isCreation() && !globalState->addressInUse(tx.receiveAddress())){
Dev::eth::ExecutionResult execRes;
execRes.excepted = dev::eth::TransactionException::Unknown;
Result.push_back(ResultExecute{execRes, dev::eth::TransactionReceipt(dev::h256(),
Dev::u256(), dev::eth::LogEntries()), CTransaction()});
Continue;
}
Result.push_back(globalState->execute(envInfo, *se.get(), tx, type, OnOpFunc()));
}
 
The first is to build a contract execution environment, which is done by BuildEVMEnvironment(). It can be seen that this execution environment is carried out for each independent transaction, so as to minimize the contract execution process of different transactions and avoid the cross-effects in the contract execution process. Then build a new sealEngine class, which is the EVM execution engine, which is done by the createSealEngine() function. In the middle, the possible state exceptions that occur are checked, and then globalState->execute() completes the execution of the contract. Here, the execution environment envInfo and the EVM execution engine se are used.
 
3.2 UTXO conversion of contract execution results
After the completion of the contract execution, the result is stored in vector result. The vector vector records the transfer relationship between EVM accounts generated by each contract execution. AAL completes the transfer from EVM account model to UTXO model by converting these transfers into UTXO transactions. Conversion of the transaction. This processing is implemented by the processingResults() function. The following is a code snippet.
 
ByteCodeExecResult resultBCE;
For(size_t i = 0; i < result.size(); i++){
If(result[i].execRes.excepted != dev::eth::TransactionException::None){
If(txs[i].value() > 0){
CMutableTransaction tx;
Tx.vin.push_back(CTxIn(h256Touint(txs[i].getHashWith()), txs[i].getNVout(), CScript() <<
OP_SPEND));
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
Tx.vout.push_back(CTxOut(CAmount(txs[i].value()), script));
resultBCE.valueTransfers.push_back(CTransaction(tx));
}
} else {
resultBCE.usedFee += CAmount(result[i].execRes.gasUsed);
CAmount ref((txs[i].gas() - result[i].execRes.gasUsed) * txs[i].gasPrice());
If(ref > 0){
CScript script(CScript() << OP_DUP << OP_HASH160 << txs[i].sender().asBytes() <<
OP_EQUALVERIFY << OP_CHECKSIG);
resultBCE.refundOutputs.push_back(CTxOut(ref, script));
resultBCE.refundSender += ref;
}
} if(result[i].tx != CTransaction()){
resultBCE.valueTransfers.push_back(result[i].tx);
}}
 
First, the resultBCE variable of type ByteCodeExecResult is defined to save the result of the conversion. Use the opcode OP_SPEND to implement the transaction cost, because the UTXO of Bitcoin uses the private key signature to realize the balance after the transaction input is unlocked, and the EVM implementation involves the transfer between different accounts, so these need to be implemented by OP_SPEND Transfer to UTXO model trading conversion. If execRes.excepted is not None, ie the contract execution exception, the balance is returned to the contract caller. Otherwise, if there is no abnormality, the remaining gas after deducting the consumed gas is returned to the caller of the contract. For the transfer that occurs during contract execution, its UTXO transaction is stored in result[i].tx. Therefore, transactions between different UTXO accounts generated by this process of contract execution are stored in the valueTransfers vector, and eventually these transactions are included in the new block. At this point, the AAL module completes the conversion from EVM transactions to UTXO.
 
4. Summary
AAL assists in the creation, execution, and cost of contracts through the addition of UTXO script opcodes. Before the contract is created and executed, the conversion of the UTXO transaction to the EVM model transaction is required, and then the executed EVM execution environment and engine are used to complete the execution of the contract. AAL finally processed the results of the contract and adapted it from EVM to UTXO, thus implementing a UTXO-based smart contract. AAL makes Qtum compatible with EVM-compliant smart contracts, providing Dapp with a new base platform, while UTXO's advantages allow for advantages such as parallel processing and privacy.
 
Huaming
He is currently a Qtum core developer and researcher. He graduated from Huazhong University of Science and Technology and has a graduate degree from the Chinese Academy of Sciences. Prior to joining Qtum, he has been engaged in the development of algorithms and protocol stacks for many years of wireless networks (including 4G LTE and wireless ad hoc networks); since 2015, he has been in contact with blockchain technology and has participated in the first hackathon competition organized by Wanxiang Blockchain. .
submitted by thisthingismud to Qtum [link] [comments]

Bitcoin 2010 vulnerability

Hello I am entering in this world and always curios and curious to analize vulnerabilities. Here there is the 2010 bitcoin vulnerability which I didn't full understand, can someone help me to understand?
https://bitcointalk.org/index.php?topic=822.0
The "value out" in this block #74638 is quite strange:
{ "hash" : "0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c", "ver" : 1, "prev_block" : "0000000000606865e679308edf079991764d88e8122ca9250aef5386962b6e84", "mrkl_root" : "618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e", "time" : 1281891957, "bits" : 469794830, "nonce" : 28192719, "n_tx" : 2, "tx" : [ { "hash" : "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca", "ver" : 1, "vin_sz" : 1, "vout_sz" : 1, "lock_time" : 0, "in" : [ { "prev_out" : { "hash" : "0000000000000000000000000000000000000000000000000000000000000000", "n" : 4294967295 }, "coinbase" : "040e80001c028f00" } ], "out" : [ { "value" : 50.51000000, "scriptPubKey" : "0x4F4BA55D1580F8C3A8A2C78E8B7963837C7EA2BD8654B9D96C51994E6FCF6E65E1CF9A844B044EEA125F26C26DBB1B207E4C3F2A098989DA9BA5BA455E830F7504 OP_CHECKSIG" } ] }, { "hash" : "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9", "ver" : 1, "vin_sz" : 1, "vout_sz" : 2, "lock_time" : 0, "in" : [ { "prev_out" : { "hash" : "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39", "n" : 0 }, "scriptSig" : "0xA87C02384E1F184B79C6ACF070BEA45D5B6A4739DBFF776A5D8CE11B23532DD05A20029387F6E4E77360692BB624EEC1664A21A42AA8FC16AEB9BD807A4698D0CA8CDB0021024530 0x965D33950A28B84C9C19AB64BAE9410875C537F0EB29D1D21A60DA7BAD2706FBADA7DF5E84F645063715B7D0472ABB9EBFDE5CE7D9A74C7F207929EDAE975D6B04" } ], "out" : [ { "value" : 92233720368.54277039, "scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG" }, { "value" : 92233720368.54277039, "scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG" } ] } ], "mrkl_tree" : [ "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca", "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9", "618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e" ]}

This could be a serious problem. Bitcoin's printblock also shows it:
CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba, nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2) CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0) CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00) CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7) CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0) CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC) CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7) CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512) vMerkleTree: 012cd8 1d5e51 618eba

I have a serie of questions:
  1. What is this language? which kind of language is it?
  2. the POCO i this:
''Essentially, the code for checking Bitcoin transactions did not work if outputs were so large that they overflowed when summed, and a hacker figured this out and took advantage of it. There is supposed to be a fixed maximum supply of 21 million Bitcoin, but the hacker, in a single transaction, created 8,784 times more Bitcoins than ever should exist.''

What does it mean ''did not work if outputs were so large'' ? The output of what?
so large that they overflowed when summed ...
what does this mean? can you make an example to let me understand?

The sum of what + what? And why does this sum caused a bufferoverflow? A buffer overflow isn't it when for example there is an array and then there is no definied lenght for the array and you put in more than the array may own? In this case from what is the buffer overflow caused by?

Also interstead in what does this string mean:
vMerkleTree: 012cd8 1d5e51 618eba

what does this mean?








submitted by luchins to cybersecurity [link] [comments]

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

Foreword
In this series of articles, the Qtum Quantum Chain Foundation will make public its early design documents for the first time, hoping to help the community understand the design intent of Qtum and the implementation details of key technologies. The article will be based on the original design draft in order to restore the designer's original ideas. Follow-up Qtum project team will be further collation and interpretation, to help readers understand more technical details, so stay tuned.
The topics that may be included in this series include
* Qtum account abstraction layer AAL
* Qtum distributed autonomous protocol DGP
* Qtum wallet (qt, mobile wallet, etc.) and browser
* Add RPC call
* Mutual interest consensus mechanism MPoS
* Add opcode
* Integration of EVM and Qtum blockchain
* Qtum x86 virtual machine
* Others...
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch.
Qtum original design document summary -- Qtum new OPCODE
As we all know, Qtum uses the same UTXO model as Bitcoin. The original UTXO script was not compatible with the EVM account model, so Qtum added three OP_CREATE, OP_CALL, and OP_SPEND opcodes to the UTXO transaction script for the purpose of providing operational support for conversions between UTXO and EVM account models. The original names of the three opcodes are OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) and OP_TXHASH(OP_SPEND), respectively.
The following is an excerpt of representative original documents for interested readers.
OP_CREATE (or OP_EXEC**)**
OP_CREATE (or OP_EXEC) is used to create a smart contract. The original design files (with Chinese translation) related to this opcode by the Qtum development team are as follows (ps: QTUM <#> or QTUMCORE<#> in the document numbering internal design documents. ):
QTUMCORE-3:Add EVM and OP_CREATE for contract execution Description:After this story, the EVM should be integrated and a very basic contract should be capable of being executed. There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order: 1. VM version (currently 1 is EVM) 2. Gas price (not yet used, anything is valid) 3. Gas limit (not yet used, assume very high limit) 4. bytecodeFor now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain) When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb) Note: Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed) Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though) 
The above document describes the functions required by OP_CREATE and the parameters used.

OP_CALL (or OP_EXEC_ASSIGN)

OP_CALL is used for contract execution and is one of the most commonly used opcodes. There are many descriptions in the original design document.
QTUM6: Implement calling environment info in EVM for OP_EXEC_ASSIGN 
Description: Solidity expects certain information to be pushed onto the stack as part of it's ABI. So, when data is sent into the contract using OP_EXEC_ASSIGN we need to make sure to provide this data. This data includes the Solidity "function selector" as well as ensuring the opcodes CALLER and ORIGIN function properly. This looks to be fairly easy, it should just be transferring some data from the Bitcoin stack to the EVM stack, and setting some fields for the origin info. However, this story should be split into multiple tasks and re-evaluated if it isn't easy. See also: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI For populating the CALLER and ORIGIN value, the following should be done: OP_EXEC_ASSIGN should take 2 extra arguments, SENDER and SENDER_SIGNATURE. Sender should be a public key. Sender Signature is the signature of all the vins for the current transaction, signed of course using the SENDER value.On the EVM side, CALLER's value will be a public key hash, ie, a hash of the SENDER public key. This public key hash should be compatible with Bitcoin's public key hash for it's standard version 1 addresses. IF the given SENDER_SIGNATURE does not match successfully, then the transaction should be considered invalid. If the SENDER public key is 0, then SENDER_SIGNATURE must also be 0, and the given CALLER opcode etc should just return 0.
The above document describes the OP_EXEC_ASSIGN calling environment information that needs to be implemented in the EVM.
QTUM8: Implement OP_EXEC_ASSIGN for sending money to contracts 
Description: A new opcode should be added, OP_EXEC_ASSIGN. This opcode should take these arguments in push order: # version number (VM version to use, currently just 1)

gas price (can be ignored for now)

gas refund script (can be ignored for now)

data (The data to hand to the smart contract. This will include things like the Solidity ABI Function Selector and other data that will later be available using the CALLERDATA EVM opcode) # smart contract address (txid + vout number)

It should return two values right now, 0 and 0. These are for spendable and out of gas, respectively. Making them spendable and dealing with out of gas will be in a future storyFor this story, the EVM contract does not actually need to be executed. This opcode should only be a placeholder so that the accounting system can determine how much money a contract has control of
The above document describes the OP_EXEC_ASSIGN implementation details.
QTUM15: Execute the relevant contract during OP_EXEC_ASSIGN 
Description: After this story is complete, when OP_EXEC_ASSIGN is reached, it should actually execute the contract whose address was given to it, passing the relevant data from the bitcoin script stack with it. Other data such as the caller and sender can be left for a later story. Making the CALLER, ORIGIN etc opcodes work properly will be fixed with a later story
The above document describes OP_EXEC_ASSIGN how the script runs the relevant contract code.
QTUM40: Allow contracts to send money to pubkeyhash addresses Description: We need to allow contracts to send money back to pubkeyhash addresses, so that people can withdraw their coins from contracts when allowed, etc. This should work similar to how version 0 contract sends work. Instead of using an OP_EXEC_ASSIGN vout though, we need to instead use a standard pubkeyhash script. So, upon spending to a pubkeyhash, the following transaction should be placed on the blockchain: vin: [standard contract OP_EXEC_ASSIGN inputs] ... vout: OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG change output - version 0 OP_EXEC_ASSIGN back to spending contract These outputs should be directly spendable in the wallet with no changes to the wallet code itself 
The above document describes how to allow contracts to send QTUM to pubkeyhash addresses.
QTUMCORE-10:Add ability for contracts to call other deployed contracts Description:Contracts should be capable of calling other contracts using a new opcode, OP_CALL. Arguments in push order:version (32 bit integer) gas price (64 bit integer) gas limit (64 bit integer) contract address (160 bits) data (any length) OP_CALL should ways return false for now. OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes. If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script. The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM. Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool. 
The above document describes how the contract calls other contracts via OP_CALL.

OP_SPEND (or OP_TXHASH, OP_EXEC_SPEND)

OP_SPEND is used for the cost of the contract balance. Because the contract address is a special address, in order to ensure consensus, the UTXO needs to be specially processed. Therefore, there are more descriptions of the OP_SPEND operation code in the original design document.
QTUM20: Create OP_EXEC_SPEND transaction when a contract spends money 
Description: When a CALL opcode or similar to used from an EVM contract to send another contract money, this should be shown on the blockchain as a new transaction. When a money transfer is done in the contract, the miner should add a new transaction exactly after the currently processing transaction in the block. This transaction should spend an input owned by the contract by using EXEC_SPEND in it's redeemScript. For the purposes of this story, assume change is not something to be worried about and consume as many inputs are needed. Properly picking effecient coins and sending back money to the originating contract will come in a later story. Edge cases to watch for: The transaction for sending money to the contract must come directly after the executing transaction. The outputs should use a version-0 OP_EXEC_ASSIGN vout, so that if the transaction were received out of context, it would still mean to not execute the contract.
The above document describes the timing of creating a OP_SPEND transaction.
QTUM21: Create consensus-critical change and coin-picking algorithm for OP_EXEC_SPEND transactions Description: Building on #20, now a consensus-critical algorithm must be made that picks the most optimal outputs belonging to the contract, and spends them, and also makes a change output that returns the "change" from the transaction back to the contract. All outputs in this case should be using a version-0 OP_EXEC_ASSIGN, to avoid running into the limitation that prevents more than one (version 1) OP_EXEC_ASSIGN transaction from being in a single transaction. The transaction should have as many vins as needed, and exactly 2 vouts. The first vout to go to the target contract, and the second vout to send change back to the source contract. 
QTUM22: Disallow more than one EVM execution per transaction
Description: In order to avoid significant edge cases, for now, disallow more than one EVM execution to take place in a single transaction. This includes both deployment and fund assignment vouts. Instead, such things should be split into multiple transactions If two EVM executions are encountered, the transaction should be treated as completely invalid and not suitable for broadcast nor putting into a block
QTUM23: Add "version 0" OP_EXEC_ASSIGN, which does not execute EVM Description: To counteract problems from #22, we should allow OP_EXEC_ASSIGN to be used to fund a contract without the contract actually being executed. This will be used later for "change" outputs to (multiple) contracts. If the version number passed in for OP_EXEC_ASSIGN is 0, then the contract is not executed. Also, this is only valid if the data provided to OP_EXEC_ASSIGN is just a single byte "0". Multiple version-0 OP_EXEC_ASSIGN vouts should be valid in a transaction, or 1 non-version-0 OP_EXEC_ASSIGN (or an OP_EXEC deployment) and multiple version-0 OP_EXEC_ASSIGN vouts. This will be used for all money spending that is sent from a contract to another contract
The above three documents describe that if the consensus-associated coin-picking algorithm guarantees that the OP_SPEND opcode does not cause a consensus error, the correctness of the change is ensured. At the same time, it describes the situation where the contract does not need to be run and how it is handled.
QTUM34: Disallow OP_EXEC and OP_EXEC_ASSIGN from coinbase transactions Description: Because of problems with coinbase maturity and potential side effects from ordering of gas-refund scripts, it should not be legal for coinbase outputs to be anything which results in EVM execution or directly changing EVM account balances. This includes version 0 OP_EXEC_ASSIGN outputs. 
The above document stipulates that coinbase transactions should not include contract-related scripts.

Other related documents

In addition, there are some documents describing the infrastructure needed for the new operation code.
QTUMCORE-51:Formalize the version field for OP_CREATE and OP_CALL Description:In order to sustain future extensions to the protocol, we need to set some rules for how we will later upgrade and add new VMs by changing the "version" argument to OP_CREATE and OP_CALL. We need a definitive VM version format beyond our current "just increment when doing upgrades". This would allow us to more easily plan upgrades and soft-forks. Proposed fields: 
  1. VM Format (can be increased from 0 to extend this format in the future): 2 bits2. Root VM - The actual VM to use, such as EVM, Lua, JVM, etc: 6 bits
  2. VM Version - The version of the Root VM to use (for upgrading the root VM with backwards compatibility) - 8 bits
  3. Flag options - For flags to the VM execution and AAL: 16 bits Total: 32 bits (4 bytes). Size is important since it will be in every EXEC transaction Flag option bits that control contract creation: (only apply to OP_CREATE) • 0 (reserve) Fixed gas schedule - if true, then this contract chooses to opt-out of allowing different gas schedules. Using OP_CALL with a gas schedule other than the one specified in it's creation will result in an immediate exception and result in an out of gas refund condition • 1 (reserve) Enable contract admin interface (reserve only, this will be implemented later. Will allow contracts to control for themselves what VM versions and such they allow, and allows the values to be changed over the lifecycle of the contract) • 2 (reserve) Disallow version 0 funding - If true, this contract is not capable of receiving money through version 0 OP_CALL, other than as required for the account abstraction layer. • bits 3-15 available for future extensions Flag options that control contract calls: (only apply to OP_CALL) • (none yet) Flag options that control both contract calls and creation: • (none yet) These flags will be implemented in a later story Note that the version field now MUST be a 4 byte push. A standard EVM contract would now use the version number (in hex) "01 00 00 00" Consensus behavior: VM Format must be 0 to be valid in a block Root VM can be any value. 1 is EVM, 0 is no-exec. All other values result in no-exec (allowed, but the no execution, for easier soft-forks later) VM Version can be any value (soft-fork compatibility). If a new version is used than 0 (0 is initial release version), then it will execute using version 0 and ignore the value Flag options can be any value (soft-fork compatibility). (inactive flag fields are ignored) Standard mempool behavior: VM Format must be 0Root VM must be 0 or 1VM Version must be 0Flag options - all valid fields can be set. All fields that are not assigned must be set to 0Defaults for EVM: VM Format: 0Root VM: 1VM Version: 0Flags: 0
The above documents formally identified OP_CREATE and OP_CALL needed version information, paving the way for subsequent multi-virtual machine support for Qtum.
QTUMCORE-52:Contract Admin Interface Description:(note, this isn't a goal for mainnet, though it would be a nice feature to include) It should be possible to manage the lifecycle of a contract internally within the contract itself. Such variables and configuration values that might need to be changed over the course of a contract's lifecycle: • Allowable gas schedules 
• Allowable VM versions (ie, if a future VM version breaks this contract, don't allow it to be used, as well as deprecating past VM versions from being used to interact with this contract) • Creation flags (the version flags in OP_CREATE) All of these variables must be able to be controlled within the contract itself, using decentralized code. For instance, in a DAO scenario, it might be something that participants can vote on within the contract, and then the contract triggers the code that changes these parameters. In addition, a contract should be capable of detecting it's own settings throughout it's execution as well as when it is initially created. I propose implementing this interface as a special pre-compiled contract. For a contract ot interact with it, it would call it using the Solidity ABI like any other contract. Proposed ABI for the contract: • bytes[2048] GasSchedule(int n) • int GasScheduleCount() • int AddGasSchedule(bytes[2048] • bytes[32] AllowedVMVersions() • void SetAllowedVMVersions(bytes[32]) Alternative implementations: There could be a specific Solidity function which is called in order to validate that the contract should allow itself to be called in a particular manner: pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; } } In this way a contract is responsible for managing it's own state. The basic way it would work is that when a you use OP_CALL to call a contract, it would first execute these two functions (and their execution would be included in gas costs). If either function returns false, then it immediately triggers an out of gas condition and cancels execution. It's slightly complicated to manage the "ValidateVMVersion" callback however, because we must decide which VM version to use. A bad one could cause this function itself to misbeha`ve.```````
pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; }
} 
The above document describes the management interface of the contract, and yes the contract can manage its own status.
QTUMCORE-53:Add opt-out flags to contracts for version 0 sends Description:Some contracts may wish to opt-out of certain features in Qtum that are not present in Ethereum. This way more Ethereum contracts can be ported to Qtum without worrying about new features in the Qtum blockchain Two flag options should be added to the Version field, which only have an effect in OP_CREATE for creating the contract: 2. (1st bit) Disallow "version 0" OP_CALLs to this contract outside of the AAL. (DisallowVersion0)  If this is enabled, then an OP_CALL using "root VM 0" (which causes no execution) is not allowed to be sent to this contract. If money is attempted to be sent to this contract using "version 0" OP_CALL, then it will result in an out of gas exception and the funds should be refunded. Version 0 payments made internally within the Account Abstraction Layer should not be affected by this flag. Along with these new consensus rules, there should also be some standard mempool checks: 
  1. If an OP_CALL tx uses a different gas schedule than the contract creation, and the disallow dynamic gas flag is set, then the transaction should be rejected from the mempool as a non-standard transaction (version 0 payments should not be allowed as standard transactions in the mempool anyway)
The above document describes how to get better EVM compatibility by ignoring certain Qtum specific features in order to port Ethereum contract code. This makes smart contracts in the Ethereum ecosystem more easily compatible with Qtum.

summary

The Qtum original design document presented above describes Qtu's increased opcode associated with the contract run, laying the groundwork for subsequent Qtum's EVM VMs that are compatible with the account model on top of the UTXO model, and also making the account abstraction layer AAL possible. The subsequent Qtum project team will further interpret the key documents. If you have any questions, readers can post comments in the comments area or contact the Qtum project team .
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch .
Please note that based on Patrick Dai's translation request, the content in this material is translated to English and published on Reddit.
OP's Qtum Address: QMmYAMEFgvPJGwK9nrwqYw1DHhBkiuEi78
submitted by szhman to Qtum [link] [comments]

TheOutdoorGearReview - YouTube Blockchain tutorial 3: Hash - YouTube George Levy - Blockchain in Washington D.C. and the permanent history of Bitcoin. #33 - Gleb of 2Miners talks GPU Mining, Mining Pools, Ethereum Ethash Re-Distribution, SHA3, ProgPow How To Mine BTCV (Bitcoin Vault) With Mining City

Bitcoin tools. Check Bitcoin addresses balance, sent and received bitcoins, convert hashes, generate public keys and more! Donate How do you get the OP_HASH160 value from a bitcoin address? Ask Question Asked 8 years ago. Active 6 years, 6 months ago. Viewed 7k times 7. 1. I'm trying to sign a coinbase transaction. I know I need to use 76 A9 14 (HASH160) 88 AC but I don't understand how to create the HASH160 (20 byte) from a bitcoin address. script ... tl;dr How should one perform Hash160, using most basic tools?. Hi, I'm trying to figure out, how transactions work in bitcoin. When I choose inputs for a new tx I want to make sure they belong to a specific address. The two things represent the same number, but they are both useful because on the one hand dealing with a bitcoin address gives us the security of having an embedded 4 bytes checksum (so we don't transfer money by mistake to something that isn't a valid address), and on the other hand, dealing with the Hash 160 only (20 bytes) is more efficient for the purpose of encoding a transaction. tl;dr How should one perform Hash160, using most basic python tools? ===== Hi, I'm trying to figure out, how transactions work in bitcoin. When I choose inputs for a new tx I want to make sure they belong to a specific address. However, existing txs do not specify previous outputs' addresses, but instead the contain address's hash. e.g.:

[index] [20478] [7615] [2167] [35670] [26338] [39445] [21869] [24687] [35010] [36655]

TheOutdoorGearReview - YouTube

T-shirt: RIG A: MultiCoin Owner: Kevin PARTS: Message Body: 4 sapphire rx470 mining edition 1 evga gtx1070 SC black edition 1 msi rx vega 56 8gb ballistric memory z270-a mother board 1000W EVGA ... Mine BTCV (Bitcoin Vault) With Mining City: Sign up here to mine BTCV: https://tinyurl.com/cryptokooper minimum investment is $300 To learn more follow these... We aim to understand how bitcoin nodes validate a bitcoin transaction by concatenation of output and input scripts . Therefor we analyze the format of Bitcoin transaction. This is needed to ... Gleb sets the record straight on what to expect after Ethereum's move to PoS and how the hash rate is likely to be redistributed. In this episode, we learn a lot about GPU mining for profitability ... George Levy is a certified instructor blockchain and cryptocurrency at Blockchain Institute of Technology, and the author of the best selling online course Blockchain and Bitcoin Fundamentals ...

#