On 11/16/2016 05:24 PM, Alex Morcos wrote: > huh? > can you give an example of how a duplicate transaction hash (in the same > chain) can happen given BIP34?
"The pigeonhole principle arises in computer science. For example, collisions are inevitable in a hash table because the number of possible keys exceeds the number of indices in the array. A hashing algorithm, no matter how clever, cannot avoid these collisions." https://en.wikipedia.org/wiki/Pigeonhole_principle e > On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev wrote: > > On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote: > > On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > >> BIP30 actually was given similar treatment after a reasonable amount > of time > >> had passed. > >> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392 > <https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392> > > > > This is not really the same. BIP30 is not validated after BIP34 is > > active because blocks complying with BIP34 will always necessarily > > comply with BIP30 (ie coinbases cannot be duplicated after they > > include the block height). > > This is a misinterpretation of BIP30. Duplicate transaction hashes can > and will happen and are perfectly valid in Bitcoin. BIP34 does not > prevent this. > > e
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
