Quote from: DannyHamilton on March 17, 2016, 07:29:12 PM

Quote from: trashman43 on March 17, 2016, 07:07:26 PM

- 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/152

Quote from: gavinandresen

There 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).

Hmm. Not sure about that.

https://www.reddit.com/r/Bitcoin/comments/4apl97/gavins_head_first_mining_thoughts/d13nv7p

Quote

In other words, the code changes do not do what the description claims they do. It may do everything possible to limit it to 30 seconds on the node end, but as already mentioned this is ineffective with current miners which will refuse to ever switch back to an old block.

https://www.reddit.com/r/Bitcoin/comments/4apl97/gavins_head_first_mining_thoughts/d12op9j

Quote

Mining code currently sees such an attempt as if it were a malicious pool trying to fork the blockchain, and will refuse to mine on the old block. It's a safety measure against a compromised or malicious pool.

Quote

Spread out over https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c#L7528 and https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c#L6612

Now, if miners stop using that code --- and nothing in the node software can force them to do that AFAIK --- what kind of trade-off are we making? What are the risks?

Theoretically this would make attacks by a malicious pool more likely, to make attacks based on SPV-mining vulnerability less likely. That trade-off is only necessary because SPV-mining would be hard-coded into the software that all miners run, rather than a bad practice used by some miners --- and making the practice ubiquitous simply exacerbates the dangers that SPV-mining already poses. In other words, Gavin is hard-coding changes that improve orphan risk for miners at the direct cost of user security.

Is that really the best choice? And if so, let's get some more numbers and risk simulations rather than the usual on bitcointalk/reddit, which is to take Gavin's word that every change is both warranted and safe.

Why, I remember something like a year ago, Gavin made it seem like the world would end if we didn't increase the block size immediately. That simple fact should make everyone weary of his judgment and expertise, particularly when hard-coding bad miner practices into the protocol.

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?