📅 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>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:54:26
in reply to nevent1q…uzsp
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:54:26Event JSON
{
"id": "95c29175bb584e0b3fab419a10df8f4bded85f4067d80af9bef692e9fbf7cc31",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160466,
"kind": 1,
"tags": [
[
"e",
"c6e8265a8190b09241f3ca887acc7d6077229c3ab9f15bec454c2ced306e6904",
"",
"root"
],
[
"e",
"7c4f3557266742a061e6ae045c6beb72dae45e8b0d5e97cb204e956c67608f46",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-11-17\n📝 Original message:On 11/17/2016 12:44 AM, Peter Todd wrote:\n\u003e On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote:\n\u003e\u003e\u003e This means that all future transactions will have different txids...\n\u003e\u003e rules do guarantee it.\n\u003e\u003e\n\u003e\u003e No, it means that the chance is small, there is a difference.\n\u003e\u003e\n\u003e\u003e If there is an address collision, someone may lose some money. If there\n\u003e\u003e is a tx hash collision, and implementations handle this differently, it\n\u003e\u003e will produce a chain split. As such this is not something that a node\n\u003e\u003e can just dismiss. If they do they are implementing a hard fork.\n\u003e \n\u003e If there is a tx hash collision it is almost certainly going to be because\n\u003e SHA256 has become weak..\n\nAlmost certainly is not certainly. Hash collisions happen because of chance.\n\nBIP30 is quite explicit:\n\n\u003e \"Fully-spent transactions are allowed to be duplicated in order not to\nhinder pruning at some point in the future. Not allowing any transaction\nto be duplicated would require evidence to be kept for each transaction\never made.\"\n\nBIP34 motivations:\n\n\u003e \"2. Enforce block and transaction uniqueness, and assist unconnected\nblock validation.\"\n\nBut it only specifies making collisions harder, not impossible (i.e.\nexplicitly rejected by consensus).\n\nAre you proposing that we draft a new BIP that allows us all to not have\nto code for this? If we do so it will be impossible to guard against a\nchain split due to pruning, but you seem to think that's unimportant.\n\ne\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/20161117/e4e97aa9/attachment.sig\u003e",
"sig": "e937e681bb2a7c61138699a96437bb6fcc479ab4ffccb50266b4a4220dbd5118a6ddd1812711ab2bc9290455ee15396f4e1960623fce51335590c94f04697faf"
}