Eric Voskuil [ARCHIVE] on Nostr: 📅 Original date posted:2016-11-17 📝 Original message:On 11/17/2016 02:22 AM, ...
📅 Original date posted:2016-11-17
📝 Original message:On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote:
> On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric at voskuil.org
> <mailto:eric at voskuil.org>> 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.
>
> I think we are mostly in agreement then? It is just terminology.
Sure, if you accept that mostly is not fully - just as unlikely is not
impossible.
> In terms of discussing the BIP, barring a hash collision, it does make
> duplicate txids impossible.
That's like saying, as long as we exclude car accidents from
consideration, car accidents are impossible.
> Given that a hash collision is so unlikely, the qualifier should be
> added to those making claims that require hash collisions rather than
> those who assume that they aren't possible.
>
> You could have said "However nothing precludes different txs from having
> the same hash, but it requires a hash collision".
I generally try to avoid speaking in tautologies :)
> Thinking about it, a re-org to before the enforcement height could allow
> it. The checkpoints protect against that though.
>
> As such this is not something that a node
> can just dismiss.
>
> The security of many parts of the system is based on hash collisions not
> being possible.
This is not the case.
Block hash duplicates within the same chain are invalid as a matter of
consensus, which is the opposite of assuming impossibility.
Tx hash collisions are explicitly allowed in the case that preceding tx
with the same hash is unspent. This is also not a reliance on the
impossibility of hash collision. Core certainly implements this distinction:
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426
Address hashes and script hashes can collide without harming the
security of Bitcoin (although address owner(s) may experience harm).
Rare in this case is sufficient because of this distinction.
Compact blocks contemplates hash collisions:
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Random_collision_probabilty
Checkpoints aren't part of Bitcoin security, so even the remote
possibility of two different potential blocks, with the same hash, at
the same height in the same chain, does not indicate a problem.
There is no case where the security of Bitcoin assumes that hashes never
collide. Consensus rules have specific handling for both block hash
collisions and tx hash collisions.
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/a1837c8b/attachment.sig>;
📝 Original message:On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote:
> On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil <eric at voskuil.org
> <mailto:eric at voskuil.org>> 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.
>
> I think we are mostly in agreement then? It is just terminology.
Sure, if you accept that mostly is not fully - just as unlikely is not
impossible.
> In terms of discussing the BIP, barring a hash collision, it does make
> duplicate txids impossible.
That's like saying, as long as we exclude car accidents from
consideration, car accidents are impossible.
> Given that a hash collision is so unlikely, the qualifier should be
> added to those making claims that require hash collisions rather than
> those who assume that they aren't possible.
>
> You could have said "However nothing precludes different txs from having
> the same hash, but it requires a hash collision".
I generally try to avoid speaking in tautologies :)
> Thinking about it, a re-org to before the enforcement height could allow
> it. The checkpoints protect against that though.
>
> As such this is not something that a node
> can just dismiss.
>
> The security of many parts of the system is based on hash collisions not
> being possible.
This is not the case.
Block hash duplicates within the same chain are invalid as a matter of
consensus, which is the opposite of assuming impossibility.
Tx hash collisions are explicitly allowed in the case that preceding tx
with the same hash is unspent. This is also not a reliance on the
impossibility of hash collision. Core certainly implements this distinction:
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2419-L2426
Address hashes and script hashes can collide without harming the
security of Bitcoin (although address owner(s) may experience harm).
Rare in this case is sufficient because of this distinction.
Compact blocks contemplates hash collisions:
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Random_collision_probabilty
Checkpoints aren't part of Bitcoin security, so even the remote
possibility of two different potential blocks, with the same hash, at
the same height in the same chain, does not indicate a problem.
There is no case where the security of Bitcoin assumes that hashes never
collide. Consensus rules have specific handling for both block hash
collisions and tx hash collisions.
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/a1837c8b/attachment.sig>;