📅 Original date posted:2016-11-16
📝 Original message:> 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.
e
On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote:
>
>
> On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Both of these cases resulted from exact duplicate txs, which BIP34 now
> precludes. However nothing precludes different txs from having the same
> hash.
>
>
> The only way to have two transactions have the same txid is if their
> parents are identical, since the txids of the parents are included in a
> transaction.
>
> Coinbases have no parents, so it used to be possible for two of them to
> be identical.
>
> Duplicate outputs weren't possible in the database, so the later
> coinbase transaction effectively overwrote the earlier one.
>
> The happened for two coinbases. That is what the exceptions are for.
>
> Neither of the those coinbases were spent before the overwrite
> happened. I don't even think those coinbases were spent at all.
>
> This means that every activate coinbase transaction has a unique hash
> and all new coinbases will be unique.
>
> This means that all future transactions will have different txids.
>
> There might not be an explicit rule that says that txids have to be
> unique, but barring a break of the hash function, they rules do
> guarantee it.
-------------- 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/20161116/a04356d5/attachment.sig>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:54:25
in reply to nevent1q…4nru
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:54:25Event JSON
{
"id": "231bfefaaaa5baf777b686f1f0ff652d3edd2399e8e1bec4f3cf4a75431031b8",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160465,
"kind": 1,
"tags": [
[
"e",
"c6e8265a8190b09241f3ca887acc7d6077229c3ab9f15bec454c2ced306e6904",
"",
"root"
],
[
"e",
"e7ab4bc2358e980bcc4c0bf098416e2127293bfc01b58a7d54750184393849d9",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2016-11-16\n📝 Original message:\u003e This means that all future transactions will have different txids...\nrules do guarantee it.\n\nNo, it means that the chance is small, there is a difference.\n\nIf there is an address collision, someone may lose some money. If there\nis a tx hash collision, and implementations handle this differently, it\nwill produce a chain split. As such this is not something that a node\ncan just dismiss. If they do they are implementing a hard fork.\n\ne\n\nOn 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote:\n\u003e \n\u003e \n\u003e On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Both of these cases resulted from exact duplicate txs, which BIP34 now\n\u003e precludes. However nothing precludes different txs from having the same\n\u003e hash.\n\u003e \n\u003e \n\u003e The only way to have two transactions have the same txid is if their\n\u003e parents are identical, since the txids of the parents are included in a\n\u003e transaction.\n\u003e \n\u003e Coinbases have no parents, so it used to be possible for two of them to\n\u003e be identical.\n\u003e \n\u003e Duplicate outputs weren't possible in the database, so the later\n\u003e coinbase transaction effectively overwrote the earlier one.\n\u003e \n\u003e The happened for two coinbases. That is what the exceptions are for.\n\u003e \n\u003e Neither of the those coinbases were spent before the overwrite\n\u003e happened. I don't even think those coinbases were spent at all.\n\u003e \n\u003e This means that every activate coinbase transaction has a unique hash\n\u003e and all new coinbases will be unique.\n\u003e \n\u003e This means that all future transactions will have different txids.\n\u003e \n\u003e There might not be an explicit rule that says that txids have to be\n\u003e unique, but barring a break of the hash function, they rules do\n\u003e guarantee it.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/a04356d5/attachment.sig\u003e",
"sig": "b0bde2a457faf94dc872ab8e3c7be293168cea9625584b0daaea0247bb9e06ffa9343a9133d5947d744ab335c1c34ae688a19a437a7b08facb344c549f151933"
}