📅 Original date posted:2012-02-29
📝 Original message:> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?
Looks good to me. I also second the notion that we should deploy this
quickly, given that it's a bug fix.
On 2/28/2012 5:48 PM, Pieter Wuille wrote:
> Hello all,
>
> 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've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible. The change is backward compatible in the same way BIP16
> is: if a supermajority of mining power implements it, old clients can
> continue to function without risk.
>
> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?
>
> [1] https://en.bitcoin.it/wiki/Protocol_rules
> [2] https://en.bitcoin.it/wiki/BIP_0030
>
Stefan Thomas [ARCHIVE] /
npub1f8…ap20e
2023-06-07 03:09:58
in reply to nevent1q…2esw
Author Public Key
npub1f8c8h5evqyy29yp6p7jelyzw6vfwp6jz05exn66l4ygwkj57ytzqmap20eSeen on
wss://relay.nostr.bandPublished at
2023-06-07 03:09:58Event JSON
{
"id": "05f4e4aaa8d2fa18faa2a01dad23c78f25d87495279e640e119d0d3d44444722",
"pubkey": "49f07bd32c0108a2903a0fa59f904ed312e0ea427d3269eb5fa910eb4a9e22c4",
"created_at": 1686107398,
"kind": 1,
"tags": [
[
"e",
"431de1b2053f2297a5c4d8abb946e01d3f305001a64415bafb02369c2320d799",
"",
"root"
],
[
"e",
"d56dbe4eefa29492121fdd6c69f777ff20940c284522f6958267b551210fef4c",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2012-02-29\n📝 Original message:\u003e The purpose of this mail is asking for support for adding this rule to\n\u003e the protocol rules. If there is consensus this rule is the solution, I\n\u003e hope pools and miners can agree to update their nodes without lengthy\n\u003e coinbase-flagging procedure that would only delay a solution. So, who\n\u003e is in favor?\n\nLooks good to me. I also second the notion that we should deploy this \nquickly, given that it's a bug fix.\n\n\nOn 2/28/2012 5:48 PM, Pieter Wuille wrote:\n\u003e Hello all,\n\u003e\n\u003e as some of you may know, a vulnerability has been found in how the\n\u003e Bitcoin reference client deals with duplicate transactions. Exploiting\n\u003e it is rather complex, requires some hash power, and has no financial\n\u003e benefit for the attacker. Still, it's a security hole, and we'd like\n\u003e to fix this as soon as possible.\n\u003e\n\u003e A simple way to fix this, is adding an extra protocol rule[1]:\n\u003e\n\u003e Do not allow blocks to contain a transaction whose hash is equal to\n\u003e that of a former transaction which has not yet been completely spent.\n\u003e\n\u003e I've written about it in BIP30[2]. There is a patch for the reference\n\u003e client, which has been tested and verified to make the attack\n\u003e impossible. The change is backward compatible in the same way BIP16\n\u003e is: if a supermajority of mining power implements it, old clients can\n\u003e continue to function without risk.\n\u003e\n\u003e The purpose of this mail is asking for support for adding this rule to\n\u003e the protocol rules. If there is consensus this rule is the solution, I\n\u003e hope pools and miners can agree to update their nodes without lengthy\n\u003e coinbase-flagging procedure that would only delay a solution. So, who\n\u003e is in favor?\n\u003e\n\u003e [1] https://en.bitcoin.it/wiki/Protocol_rules\n\u003e [2] https://en.bitcoin.it/wiki/BIP_0030\n\u003e",
"sig": "cab214067c27f3ad1ab4caba9834ff8241a2cd6584ba2ba87e205644927b78e9b953d396d8e8a97a6630d5d4ac0bec9248c06e35420fd8228be6b77c3ac43106"
}