rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:> > As Greg explained to you repeatedly, a softfork won't cause a > non-upgraded full node to start accepting blocks that create more > subsidy than is valid. > It was an example. Adam Back's extension blocks proposal would, in fact, allow for a soft forking change that creates more subsidy than is valid (or does anything else) by hiding one block inside another. Anyway, I think you got my point. > That's very different security from an SPV node, and as Greg > also explained, SPV nodes could be much more secure than bitcoinj > nodes (they could, for example, validate the coinbase transaction of > every block). > I'm pretty sure Gregory did not use such an example because it's dead wrong. You cannot verify the size of a coinbase without being a fully verifying node because you need to know the fees in the block, and calculating that requires access to the entire UTXO set. This sort of thing is why I get annoyed when people lecture me about SPV wallets and the things they "should" do. None of you guys has built one. I keep seeing wild statements about theoretical unicorn wallets that nobody has even designed, and how all existing wallets are crappy and insecure because they don't meet your ever shifting goal posts. To everyone making such statements I say: go away and build an SPV wallet of your own from scratch. Then you will understand the engineering tradeoffs involved much better, and be in a much better position to debate what they should or should not be doing. And bear in mind if it weren't for the work myself and a few others did on SPV wallets, everyone would be using web wallets instead. Then you'd all just complain about that instead. > Can you give an example of an attack in which a non-upgraded full node > wallet is defrauded with BIP65 but could not with the hardfork > alternative (that nobody seems to be willing to implement)? > Making it a hard fork instead is changing one line of code (ignoring the code to set up the flag day, which can be based on the code for BIP101). If it comes down to it, then I'll do the work to change that one line. But obviously I'd need to see agreement from the maintainers that such a pull req would be merged first. The example is this: find someone that accepts 1-block confirmed transactions in return for something valuable. There are plenty of them out there. Once the soft fork starts, send a P2SH transaction that defines a new output controlled by OP_CLTV. It will be incorporated into the UTXO set by all miners because it's opaque (p2sh). Now send a transaction that pays the merchant, and make it spend your OP_CLTV output with an invalid script. New nodes will reject it as a rule violator. Old nodes won't. So at some point an old miner will create a block containing your invalid transaction, the merchant will think they got paid, they'll give you the stuff and the fraud is done. > Please, don't assume 0 confirmation transactions or similar > unreasonable assumptions (ie see section 11 "Calculations" of the > Bitcoin whitepaper). > This is just embarrassing - do any of you guys at Blockstream actually use Bitcoin in the real world? Virtually all payments that aren't moving money into/out of exchange wallets are 0-confirm in reality. I described a 1-confirm attack above, but really ... come on. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/601a316d/attachment.html>