📅 Original date posted:2016-11-16
📝 Original message:Also, it's important to take note of the motivation behind not banning
duplicate tx hashes outright. Doing so would require that spent tx
hashes are retained forever. A pruning node will have no way of knowing
whether a new tx duplicates the hash of a preceding tx. Any
implementation that does retain such hashes and dismisses new txs on
that basis would fork against pruning nodes.
e
On 11/16/2016 04:43 PM, Eric Voskuil 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.
>
> 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/d25e8219/attachment.sig>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:54:26
in reply to nevent1q…l7s6
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:54:26Event JSON
{
"id": "4a781678f699d649146163ca2490061dd0630a3d6cfd09f57078b8c4deca427d",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160466,
"kind": 1,
"tags": [
[
"e",
"c6e8265a8190b09241f3ca887acc7d6077229c3ab9f15bec454c2ced306e6904",
"",
"root"
],
[
"e",
"231bfefaaaa5baf777b686f1f0ff652d3edd2399e8e1bec4f3cf4a75431031b8",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2016-11-16\n📝 Original message:Also, it's important to take note of the motivation behind not banning\nduplicate tx hashes outright. Doing so would require that spent tx\nhashes are retained forever. A pruning node will have no way of knowing\nwhether a new tx duplicates the hash of a preceding tx. Any\nimplementation that does retain such hashes and dismisses new txs on\nthat basis would fork against pruning nodes.\n\ne\n\nOn 11/16/2016 04:43 PM, Eric Voskuil wrote:\n\u003e\u003e This means that all future transactions will have different txids...\n\u003e rules do guarantee it.\n\u003e \n\u003e No, it means that the chance is small, there is a difference.\n\u003e \n\u003e If there is an address collision, someone may lose some money. If there\n\u003e is a tx hash collision, and implementations handle this differently, it\n\u003e will produce a chain split. As such this is not something that a node\n\u003e can just dismiss. If they do they are implementing a hard fork.\n\u003e \n\u003e e\n\u003e \n\u003e On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e Both of these cases resulted from exact duplicate txs, which BIP34 now\n\u003e\u003e precludes. However nothing precludes different txs from having the same\n\u003e\u003e hash.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e The only way to have two transactions have the same txid is if their\n\u003e\u003e parents are identical, since the txids of the parents are included in a\n\u003e\u003e transaction.\n\u003e\u003e\n\u003e\u003e Coinbases have no parents, so it used to be possible for two of them to\n\u003e\u003e be identical.\n\u003e\u003e\n\u003e\u003e Duplicate outputs weren't possible in the database, so the later\n\u003e\u003e coinbase transaction effectively overwrote the earlier one.\n\u003e\u003e\n\u003e\u003e The happened for two coinbases. That is what the exceptions are for.\n\u003e\u003e\n\u003e\u003e Neither of the those coinbases were spent before the overwrite\n\u003e\u003e happened. I don't even think those coinbases were spent at all.\n\u003e\u003e\n\u003e\u003e This means that every activate coinbase transaction has a unique hash\n\u003e\u003e and all new coinbases will be unique.\n\u003e\u003e\n\u003e\u003e This means that all future transactions will have different txids.\n\u003e\u003e\n\u003e\u003e There might not be an explicit rule that says that txids have to be\n\u003e\u003e unique, but barring a break of the hash function, they rules do\n\u003e\u003e guarantee it.\n\u003e \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/d25e8219/attachment.sig\u003e",
"sig": "135e597e4bf516d56359cd455f959fcf33fca1d0ae8d372054ae04baedc528852cdc3fd117fb3cf101ac536dc5391100ede1f36dfc43af112d72a38ba49f6be8"
}