Actually both possibilities were specifically covered in my description. Sorry if it wasn't clear.
If you create a new valid block out of an old one it's has potential to cause a reorg. The blocks that previously built on the original are still able to do so but presumably cannot build forever on the *new* block as it has a different tx. But other new blocks can. There is no chain split due to a different interpretation of valid, there are simply two valid competing chains. Note that this scenario requires not only block and tx validity with a tx hash collision, but also that the tx be valid within the block. Pretty far to reach to not even get a chain split, but it could produce a deep reorg with a very low chance of success. As I keep telling people, deep reorgs can happen, they are just unlikely, as is this scenario. If you create a new invalid block it is discarded by everyone. That does not invalidate the hash of that block. Permanent blocking as you describe it would be a p2p protocol design choice, having nothing to do with consensus. Libbitcoin for example does not ban invalidated hashes at all. It just discards the block and drops the peer. e > On Nov 17, 2016, at 9:22 AM, Johnson Lau <[email protected]> wrote: > > I’m not sure if you really understand what you and I am talking. It has > nothing to do with BIP30, 34, nor any other BIPs. > > Say tx1 is confirmed 3 years ago in block X. An attacker finds a valid tx2 > which (tx1 != tx2) and (SHA256(tx1) == SHA256(tx2)). Now he could replace tx1 > with tx2 in block X and the block is still perfectly valid. Anyone trying to > download the blockchain from the beginning may end up with a different > ledger. The consensus is irrevocably broken as soon as tx1 or tx2 is spent. > > Or, alternatively, an attacker finds an invalid tx3 which (tx1 != tx3) and > (SHA256(tx1) == SHA256(tx3)). Now he could replace tx1 with tx3 in block X. > Anyone trying to download the blockchain from the beginning will permanently > reject the hash of block X. They will instead accept a fork built on top of > block X-1. The chain will be permanently forked. > > jl2012 > > >> On 18 Nov 2016, at 01:01, Eric Voskuil <[email protected]> wrote: >> >> On 11/17/2016 07:40 AM, Johnson Lau wrote: >>> >>>> On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev >> <[email protected]> wrote: >>>> >>>> Given that hash collisions are unquestionably possible, >>> >>> Everything you said after this point is irrelevant. >> >> So... you think hash collisions are not possible, or that it's moot >> because Core has broken its ability to handle them. >> >> >>> Having hash collision is **by definition** a consensus failure, >> >> I suppose if you take fairly recent un-BIPped consensus changes in Core >> to be the definition of consensus, you would be right about that. >> >> >>> or a hardfork. >> >> And those changes could definitely result in a chain split. So right >> about that too. >> >> >>> You could replace the already-on-chain tx with the collision and >> create 2 different versions of UTXOs (if the colliding tx is valid), or >> make some nodes to accept a fork with less PoW (if the colliding tx is >> invalid, or making the block invalid, such as being to big). >> >> >> Not in accordance with BIP30 and not according to the implementation of >> it that existed in Core until Nov 2015. A tx was only valid as a >> "replacement" if it did not collide with the hash of an existing tx with >> unspent outputs. The collision would have been rejected. And an invalid >> colliding tx would not be accepted in any case (since nodes presumably >> validate blocks and don't rely on checkpoints as a security measure). >> >> A transaction duplicating the hash of another and taking its place in a >> block would not only have to collide the hash, but it would have to be >> fully valid in the context of the block you are suggesting it is >> substituted into. In that case it's simply a fully valid block. This is >> not just the case of a hash collision, this is the case of a hash >> collision where both transactions are fully valid in the context of the >> same block parent. Even if that unlikely event did occur, it's not a >> hard fork, it's a reorg. The chain that builds on this block will be >> valid to all nodes but necessarily deviates from the other block's valid >> chain. This is true whether the magical block is assembled via compact >> blocks or otherwise. >> >> Transaction "replacement" is an implementation detail of Core. Once Core >> accepted a replacement of a previously spent transaction it would be >> unable to provide the previous block/spent-tx, but that would be a >> wallet failure and an inability to provide valid historical blocks, not >> a consensus/validation failure. The previously spent outputs no longer >> contribute to validation, unless there is a reorg back to before the >> original tx's block, and at that point it would be moot, since neither >> transaction is on the chain. >> >> You are referring to the *current* behavior ("replacement" without >> concern for collision). That was an unpublished hard fork, and is the >> very source of the problems you are describing. >> >>> To put it simply, the Bitcoin protocol is broken. So with no doubt, >> Bitcoin Core and any implementation of the Bitcoin protocol should >> assume SHA256 collision is unquestionably **impossible**. >> >> I'm not disagreeing with you that it is broken. I'm pointing out that it >> was broken by code that was merged recently - an undocumented hard fork >> that reverted the documented BIP30 behavior that was previously >> implemented correctly, based on the assumption that hash collisions >> cannot occur, for the modest performance boost of not having to check >> for unspent duplicates (sounds sort of familiar). >> >>> If some refuse to make such assumption, they should have introduced an >> alternative hash algorithm and somehow run it in parallel with SHA256 to >> prevent the consensus failure. >> >> No hash algorithm can prevent hash collisions, including one that is >> just two running in parallel. A better resolution would be to fix the >> problem. >> >> There is no need to replace the BIP30 rule. That resolves the TX hash >> collision problem from a consensus standpoint. In order to serve up >> whole blocks in the circumstance requires a more robust store than I >> believe is exists in Core, but that has nothing to do with validity. >> >> The block hash check and signature validation caching splits caused by >> collision can easily be avoided, and doing so doesn't break with >> consensus. I'm not aware of any other aspects of consensus that are >> effected by an implementation assumption of non-colliding hashes. But in >> any case I'm pretty sure there aren't any that are necessary to consensus. >> >> e > > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
