Brautigam Róbert [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-22 to 2012-02-28
💬 Posted a total of 4 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub17vt9s8f4fwjvrzscfqmdgdaq0zn2ephnqs53jynr8x6hu6vsd7wqm4nw5q

Profile Code

nprofile1qqs0x9jcr565hfxp3gvysdk5x7s83f4vsmesg2gezf3nndt7dxgxl8qs222w3

Author Public Key

npub17vt9s8f4fwjvrzscfqmdgdaq0zn2ephnqs53jynr8x6hu6vsd7wqm4nw5q

Show more details

Last Notes

2023-06-07 03:09:29

- reply

📅 Original date posted:2012-02-28
📝 Original message:On 02/28/2012 05:48 PM, Pieter Wuille wrote:
> Hello all,
Hi,
> as some of you may know, a vulnerability has been found in how the
> Bitcoin reference client deals with duplicate transactions. Exploiting
> it is rather complex, requires some hash power, and has no financial
> benefit for the attacker. Still, it's a security hole, and we'd like
> to fix this as soon as possible.
>
> A simple way to fix this, is adding an extra protocol rule[1]:
>
> Do not allow blocks to contain a transaction whose hash is equal to
> that of a former transaction which has not yet been completely spent.
I don't know whether I understand this correctly, but there should be no
duplicate transaction hashes at all. So the rule should be: Do not allow
blocks to contain transaction hashes which are already present in that
branch.
If by a freak accident a transaction has the same hash as another
transaction in the chain, shouldn't the transaction be "tweaked" in some
way to avoid collision (generate a new target address for it or
something)? In any case this seams very-very unlikely to happen, or am I
missing something?
Robert.