- snip -
if this gets adopted, and you run a lite/SPV/api node wallet (electrum, multibit, blockchain.info etc) make sure you wait for additional confirmations (6+)! 0-2+ confirmation transactions will be much less safe for anyone that does not run a full node.
Absolutely true. Assuming that those 0-2+ confirmations all come within 30 seconds...
https://github.com/bitcoinclassic/bitcoinclassic/pull/152There is a hard-coded 30-second timeout; if the full block data takes longer than 30 seconds to get validated and propagated across the network, or is never sent, miners switch back to mining non-empty blocks on the last fully-validated block.
So, I definitely agree with trashman43. You should absolutely wait for more than your usual number of confirmations (unless 30 seconds have already passed since you received the payment, in which case it looks like it may be ok to just go with whatever your usual number of required confirmations is).
A couple thoughts on that, since it sounds like you are possibly being sarcastic.
You may be underestimating this, mining is a poisson process; most blocks are found quite soon have the prior one-- the rare long blocks are what pull the average up to ten minutes. About 10% of all block are found within 60 seconds of the prior one. You probably also missed my point that many mining devices will not move off a longer chain, as I added it a moment after the initial post.
I'm not sure of the math when we change the time period from 60 seconds to 30 seconds, but you get my point, right? This is particularly problematic for automated systems (although one would be pretty foolish to build an automated transaction system that does not fully validate).
The trouble with assuming that everything is fine because of the 30-second window.... if this vulnerability is consistent then an attacker only needs to wait, mining with low hashrate, for a block to happen. Luke describes how attacks could be mounted:
The block would contain 2+ transactions. One would be the transaction to your light wallet, and the other one an invalid transaction. The block is invalid because of the second transaction, but your light wallet will gladly accept it for proof that the first transaction is 1-block confirmed. ("Head-first miners" will happily also make additional blocks on top of that invalid block, which your light client will accept as proof of even more blocks confirmed.) However, full nodes will reject that block in its entirety since it is invalid, and instead wait for and follow another, valid block, which in this case would have a double-spend of that transaction you just accepted as confirmed.
you do realise that making "empty blocks" is not about making the average 10 minute block empty.
That's not what the issue is, although I do think that Classic users find the practice upsetting when they realize it's happening.