{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:\u003e\n\u003e As Greg explained to you repeatedly, a softfork won't cause a\n\u003e non-upgraded full node to start accepting blocks that create more\n\u003e subsidy than is valid.\n\u003e\n\nIt was an example. Adam Back's extension blocks proposal would, in fact,\nallow for a soft forking change that creates more subsidy than is valid (or\ndoes anything else) by hiding one block inside another.\n\nAnyway, I think you got my point.\n\n\n\u003e That's very different security from an SPV node, and as Greg\n\u003e also explained, SPV nodes could be much more secure than bitcoinj\n\u003e nodes (they could, for example, validate the coinbase transaction of\n\u003e every block).\n\u003e\n\nI'm pretty sure Gregory did not use such an example because it's dead\nwrong. You cannot verify the size of a coinbase without being a fully\nverifying node because you need to know the fees in the block, and\ncalculating that requires access to the entire UTXO set.\n\nThis sort of thing is why I get annoyed when people lecture me about SPV\nwallets and the things they \"should\" do. None of you guys has built one. I\nkeep seeing wild statements about theoretical unicorn wallets that nobody\nhas even designed, and how all existing wallets are crappy and insecure\nbecause they don't meet your ever shifting goal posts.\n\nTo everyone making such statements I say: go away and build an SPV wallet\nof your own from scratch. Then you will understand the engineering\ntradeoffs involved much better, and be in a much better position to debate\nwhat they should or should not be doing.\n\nAnd bear in mind if it weren't for the work myself and a few others did on\nSPV wallets, everyone would be using web wallets instead. Then you'd all\njust complain about that instead.\n\n\n\u003e Can you give an example of an attack in which a non-upgraded full node\n\u003e wallet is defrauded with BIP65 but could not with the hardfork\n\u003e alternative (that nobody seems to be willing to implement)?\n\u003e\n\nMaking it a hard fork instead is changing one line of code (ignoring the\ncode to set up the flag day, which can be based on the code for BIP101). If\nit comes down to it, then I'll do the work to change that one line. But\nobviously I'd need to see agreement from the maintainers that such a pull\nreq would be merged first.\n\nThe example is this: find someone that accepts 1-block confirmed\ntransactions in return for something valuable. There are plenty of them out\nthere. Once the soft fork starts, send a P2SH transaction that defines a\nnew output controlled by OP_CLTV. It will be incorporated into the UTXO set\nby all miners because it's opaque (p2sh).\n\nNow send a transaction that pays the merchant, and make it spend your\nOP_CLTV output with an invalid script. New nodes will reject it as a rule\nviolator. Old nodes won't. So at some point an old miner will create a\nblock containing your invalid transaction, the merchant will think they got\npaid, they'll give you the stuff and the fraud is done.\n\n\n\u003e Please, don't assume 0 confirmation transactions or similar\n\u003e unreasonable assumptions (ie see section 11 \"Calculations\" of the\n\u003e Bitcoin whitepaper).\n\u003e\n\nThis is just embarrassing - do any of you guys at Blockstream actually use\nBitcoin in the real world? Virtually all payments that aren't moving money\ninto/out of exchange wallets are 0-confirm in reality. I described a\n1-confirm attack above, but really ... come on.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/601a316d/attachment.html\u003e"}