Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2016-11-17 📝 Original message:On 11/17/2016 12:44 AM, ...
📅 Original date posted:2016-11-17
📝 Original message:On 11/17/2016 12:44 AM, Peter Todd wrote:
> On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote:
>>> This means that all future transactions will have different txids...
>> rules do guarantee it.
>>
>> No, it means that the chance is small, there is a difference.
>>
>> If there is an address collision, someone may lose some money. If there
>> is a tx hash collision, and implementations handle this differently, it
>> will produce a chain split. As such this is not something that a node
>> can just dismiss. If they do they are implementing a hard fork.
>
> If there is a tx hash collision it is almost certainly going to be because
> SHA256 has become weak..
Almost certainly is not certainly. Hash collisions happen because of chance.
BIP30 is quite explicit:
> "Fully-spent transactions are allowed to be duplicated in order not to
hinder pruning at some point in the future. Not allowing any transaction
to be duplicated would require evidence to be kept for each transaction
ever made."
BIP34 motivations:
> "2. Enforce block and transaction uniqueness, and assist unconnected
block validation."
But it only specifies making collisions harder, not impossible (i.e.
explicitly rejected by consensus).
Are you proposing that we draft a new BIP that allows us all to not have
to code for this? If we do so it will be impossible to guard against a
chain split due to pruning, but you seem to think that's unimportant.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161117/e4e97aa9/attachment.sig>;
📝 Original message:On 11/17/2016 12:44 AM, Peter Todd wrote:
> On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote:
>>> This means that all future transactions will have different txids...
>> rules do guarantee it.
>>
>> No, it means that the chance is small, there is a difference.
>>
>> If there is an address collision, someone may lose some money. If there
>> is a tx hash collision, and implementations handle this differently, it
>> will produce a chain split. As such this is not something that a node
>> can just dismiss. If they do they are implementing a hard fork.
>
> If there is a tx hash collision it is almost certainly going to be because
> SHA256 has become weak..
Almost certainly is not certainly. Hash collisions happen because of chance.
BIP30 is quite explicit:
> "Fully-spent transactions are allowed to be duplicated in order not to
hinder pruning at some point in the future. Not allowing any transaction
to be duplicated would require evidence to be kept for each transaction
ever made."
BIP34 motivations:
> "2. Enforce block and transaction uniqueness, and assist unconnected
block validation."
But it only specifies making collisions harder, not impossible (i.e.
explicitly rejected by consensus).
Are you proposing that we draft a new BIP that allows us all to not have
to code for this? If we do so it will be impossible to guard against a
chain split due to pruning, but you seem to think that's unimportant.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161117/e4e97aa9/attachment.sig>;