* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
@ 2012-02-28 17:12 ` Brautigam Róbert
2012-02-28 17:18 ` Pieter Wuille
2012-02-28 18:10 ` Gavin Andresen
` (6 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Brautigam Róbert @ 2012-02-28 17:12 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 17:12 ` Brautigam Róbert
@ 2012-02-28 17:18 ` Pieter Wuille
0 siblings, 0 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-02-28 17:18 UTC (permalink / raw)
To: Brautigam Róbert; +Cc: bitcoin-development
On Tue, Feb 28, 2012 at 18:12, Brautigam Róbert
<robert.brautigam@netmind•hu> wrote:
>> 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.
As explained in the BIP, that would prevent pruning, as it would
require each full node to keep a database with all transaction hashes
ever.
> 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?
It won't happen by accident. Duplicate coinbase transactions are
possible however (by badly written software, or malicious intent).
Transactions that spend duplcate coinbases can be made to have the
same hash as well.
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
2012-02-28 17:12 ` Brautigam Róbert
@ 2012-02-28 18:10 ` Gavin Andresen
2012-02-28 18:23 ` Luke-Jr
` (5 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Gavin Andresen @ 2012-02-28 18:10 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
>
> 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?
Pieter
>
Most of you might already know this, but I'm strongly in favor of doing
this as soon as possible.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 824 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
2012-02-28 17:12 ` Brautigam Róbert
2012-02-28 18:10 ` Gavin Andresen
@ 2012-02-28 18:23 ` Luke-Jr
2012-02-28 20:24 ` Pieter Wuille
2012-02-28 20:35 ` Ben Reeves
2012-02-29 1:41 ` Zooko Wilcox-O'Hearn
` (4 subsequent siblings)
7 siblings, 2 replies; 23+ messages in thread
From: Luke-Jr @ 2012-02-28 18:23 UTC (permalink / raw)
To: bitcoin-development
On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
> 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.
Has it been verified to make even rocconor's complicated transaction-based
version impossible?
> 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?
Can we do this in two steps? First, prefer blocks which don't break the rule;
once 55%+ are confirmed to have upgraded, then it is safe to treat it as a
hard rule.
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 18:23 ` Luke-Jr
@ 2012-02-28 20:24 ` Pieter Wuille
2012-02-28 20:35 ` Ben Reeves
1 sibling, 0 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-02-28 20:24 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Tue, Feb 28, 2012 at 01:23:01PM -0500, Luke-Jr wrote:
> Has it been verified to make even rocconor's complicated transaction-based
> version impossible?
Yes, he tried it on testnet against a patched node.
> > 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?
>
> Can we do this in two steps? First, prefer blocks which don't break the rule;
> once 55%+ are confirmed to have upgraded, then it is safe to treat it as a
> hard rule.
I prefer to avoid this if possible, as it increases the size of the patch
significantly. In particular, it would require the discouragement-system to
be backported to whatever versions pools are running. The current proposal
only requires adding 6 lines of code.
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 18:23 ` Luke-Jr
2012-02-28 20:24 ` Pieter Wuille
@ 2012-02-28 20:35 ` Ben Reeves
1 sibling, 0 replies; 23+ messages in thread
From: Ben Reeves @ 2012-02-28 20:35 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]
I might be wrong but I think perhaps it would help to get this fix out before the p2sh protocol change. Otherwise a miner could combine a duplicate coinbase and an invalid P2SH transaction to create a block which can have excellent network propagation and still be guaranteed to be orphaned. This makes the attack significantly easier to perform.
If someone were to do this on the day of the P2SH switchover they could corrupt the database of all clients < 0.6 with only a single block. If it was done on an early block and was widespread enough it would make it difficult for new clients to find a genuine non-corrupted copy of the blockchain to download.
Thank You,
Ben Reeves
www.blockchain.info
On 28 Feb 2012, at 18:23, Luke-Jr wrote:
> On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
>> 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.
>
> Has it been verified to make even rocconor's complicated transaction-based
> version impossible?
>
>> 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?
>
> Can we do this in two steps? First, prefer blocks which don't break the rule;
> once 55%+ are confirmed to have upgraded, then it is safe to treat it as a
> hard rule.
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3263 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
` (2 preceding siblings ...)
2012-02-28 18:23 ` Luke-Jr
@ 2012-02-29 1:41 ` Zooko Wilcox-O'Hearn
2012-02-29 16:47 ` Pieter Wuille
2012-02-29 21:00 ` Stefan Thomas
` (3 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Zooko Wilcox-O'Hearn @ 2012-02-29 1:41 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
Could you spell out the attack explicitly? Presumably there aren't a
lot of people with the "malice energy" to perform the attack but not
to figure it out for themselves. I, however, have the "niceness
energy" to think about it for a few minutes but not to figure it out
for myself. If in your opinion it is realistically dangerous to post
it publicly, would you be so kind as to include me in the private
sharing of the explanation?
By the way, I found a couple of cases of slightly bad handling of
merkle trees when I inspected the code (v0.4) that was, I'm 99% sure,
not exploitable. I never got around to reporting it yet. I'm sorry
about that. My discoveries might interact with the one you're talking
about here. I should definitely explain mine to y'all soon. (Possibly
in private for the first pass, in case it is more exploitable than I
thought, or has become exploitable since v0.4.)
I showed it to a couple of other people at the time who helped me make
sure that it wasn't exploitable.
I'll make time to explain what I found within a week.
Regards,
Zooko
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 1:41 ` Zooko Wilcox-O'Hearn
@ 2012-02-29 16:47 ` Pieter Wuille
2012-02-29 17:02 ` Amir Taaki
0 siblings, 1 reply; 23+ messages in thread
From: Pieter Wuille @ 2012-02-29 16:47 UTC (permalink / raw)
To: Zooko Wilcox-O'Hearn; +Cc: Bitcoin Dev
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
> to figure it out for themselves. I, however, have the "niceness
> energy" to think about it for a few minutes but not to figure it out
> for myself. If in your opinion it is realistically dangerous to post
> it publicly, would you be so kind as to include me in the private
> sharing of the explanation?
It's not exactly a secret anymore, as the patch also references it.
Russell O'Connor described the attack on his blog:
http://r6.ca/blog/20120206T005236Z.html
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 16:47 ` Pieter Wuille
@ 2012-02-29 17:02 ` Amir Taaki
0 siblings, 0 replies; 23+ messages in thread
From: Amir Taaki @ 2012-02-29 17:02 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
I support BIP 30.
I gave it a thought. The other ways of resolving this issue, all have various niggles. This is the best way.
________________________________
From: Pieter Wuille <pieter.wuille@gmail•com>
To: Zooko Wilcox-O'Hearn <zooko@zooko•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Sent: Wednesday, February 29, 2012 4:47 PM
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
> to figure it out for themselves. I, however, have the "niceness
> energy" to think about it for a few minutes but not to figure it out
> for myself. If in your opinion it is realistically dangerous to post
> it publicly, would you be so kind as to include me in the private
> sharing of the explanation?
It's not exactly a secret anymore, as the patch also references it.
Russell O'Connor described the attack on his blog:
http://r6.ca/blog/20120206T005236Z.html
--
Pieter
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2702 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
` (3 preceding siblings ...)
2012-02-29 1:41 ` Zooko Wilcox-O'Hearn
@ 2012-02-29 21:00 ` Stefan Thomas
2012-02-29 22:05 ` Ben Reeves
` (2 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Stefan Thomas @ 2012-02-29 21:00 UTC (permalink / raw)
To: bitcoin-development
> 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
>
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
` (4 preceding siblings ...)
2012-02-29 21:00 ` Stefan Thomas
@ 2012-02-29 22:05 ` Ben Reeves
2012-02-29 22:38 ` Matt Corallo
2012-02-29 22:46 ` Gavin Andresen
2012-03-02 1:56 ` Pieter Wuille
2012-03-03 16:41 ` Pieter Wuille
7 siblings, 2 replies; 23+ messages in thread
From: Ben Reeves @ 2012-02-29 22:05 UTC (permalink / raw)
To: Bitcoin Dev
Assuming 50% of hashing power adopts BIP30 but the actual client
install base is relatively low the patch will likely result in a
"hard" blockchain split if someone takes advantage.
A malicious miner can produce a duplicate coinbase which the majority
of clients will accept but the majority of hashing power won't.
Spending the coinbase output after disconnection will cause the
blockchain to fork. All none BIP30 clients on the short blockchain
will be vulnerable to transaction reversal of 6 confirmations or more.
It is a relatively inexpensive attack to perform (costing the attacker
only one valid block ~$240) and could be quite disruptive. I think
this should be patched in DisconnectBlock() (if it hasn't already?)
before any protocol change - maybe a new mapByCoinbase multimap is
needed.
Thank You,
Ben Reeves
www.blockchain.info
On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille <pieter.wuille@gmail•com> 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
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 22:05 ` Ben Reeves
@ 2012-02-29 22:38 ` Matt Corallo
2012-02-29 22:46 ` Gavin Andresen
1 sibling, 0 replies; 23+ messages in thread
From: Matt Corallo @ 2012-02-29 22:38 UTC (permalink / raw)
To: bitcoin-development
In other words when we roll out the update, we have to make sure we have
>>50% not just 50%. Something like 60%-75% should do fine (IMHO). In
other words we just have to be very, very vocal about the change when it
happens and make sure miners are all on board.
Matt
On Wed, 2012-02-29 at 22:05 +0000, Ben Reeves wrote:
> Assuming 50% of hashing power adopts BIP30 but the actual client
> install base is relatively low the patch will likely result in a
> "hard" blockchain split if someone takes advantage.
>
> A malicious miner can produce a duplicate coinbase which the majority
> of clients will accept but the majority of hashing power won't.
> Spending the coinbase output after disconnection will cause the
> blockchain to fork. All none BIP30 clients on the short blockchain
> will be vulnerable to transaction reversal of 6 confirmations or more.
>
> It is a relatively inexpensive attack to perform (costing the attacker
> only one valid block ~$240) and could be quite disruptive. I think
> this should be patched in DisconnectBlock() (if it hasn't already?)
> before any protocol change - maybe a new mapByCoinbase multimap is
> needed.
>
> Thank You,
> Ben Reeves
> www.blockchain.info
>
> On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille <pieter.wuille@gmail•com> 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
> >
> > --
> > Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 22:05 ` Ben Reeves
2012-02-29 22:38 ` Matt Corallo
@ 2012-02-29 22:46 ` Gavin Andresen
2012-02-29 23:00 ` Ben Reeves
1 sibling, 1 reply; 23+ messages in thread
From: Gavin Andresen @ 2012-02-29 22:46 UTC (permalink / raw)
To: Ben Reeves; +Cc: Bitcoin Dev
On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves <support@pi•uk.com> wrote:
> A malicious miner can produce a duplicate coinbase which the majority
> of clients will accept but the majority of hashing power won't.
> Spending the coinbase output after....
That can't happen until the coinbase matures, which takes 100 blocks.
And it won't mature because a majority of hashing power is rejecting
it, right?
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 22:46 ` Gavin Andresen
@ 2012-02-29 23:00 ` Ben Reeves
[not found] ` <20120229232029.GA6073@vps7135.xlshosting.net>
0 siblings, 1 reply; 23+ messages in thread
From: Ben Reeves @ 2012-02-29 23:00 UTC (permalink / raw)
To: Bitcoin Dev
I'm not sure. What if they use a coinbase of a block that has already matured?
On Wed, Feb 29, 2012 at 10:46 PM, Gavin Andresen
<gavinandresen@gmail•com> wrote:
> On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves <support@pi•uk.com> wrote:
>> A malicious miner can produce a duplicate coinbase which the majority
>> of clients will accept but the majority of hashing power won't.
>> Spending the coinbase output after....
>
> That can't happen until the coinbase matures, which takes 100 blocks.
> And it won't mature because a majority of hashing power is rejecting
> it, right?
>
> --
> --
> Gavin Andresen
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
` (5 preceding siblings ...)
2012-02-29 22:05 ` Ben Reeves
@ 2012-03-02 1:56 ` Pieter Wuille
2012-03-03 16:41 ` Pieter Wuille
7 siblings, 0 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-03-02 1:56 UTC (permalink / raw)
To: Bitcoin Dev
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> 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.
After some private discussion, Ben Reeves pointed out two potential
small weaknesses in the proposed patch, which seem viable to me.
First: disconnecting the same coinbase transaction twice would fail,
as EraseTxIndex will not find anything the second time. This is
extremely hard to pull off, as it requires reverting a chain of at
least 120 blocks long. Still, the fix is very easy imho: allow
EraseTxIndex to fail.
Second: assume the following order of events: block with coinbase A is
created, 120 blocks later, A:0 is spent in transaction B. Then, a dupe
of A is created, and another 120 blocks are waited. At this point, A:0
and B:0 are still spendable. Now a block is created with two
transactions: first C which spends B:0, followed by a dupe of B. This
dupe is accepted, as its former instance is completely spent now.
However, if this last block is disconnected again, B:0 is not
spendable anymore, causing a risk for chain split. Ben suggested
moving the check for dupes up, turning the new network rule into:
Blocks are not allowed to contain transactions whose hash matches
that of an earlier transaction in the same chain, unless that
transaction was already completely spent before said block.
I've updated the patch, and will update the BIP soon.
What do you all think? Can we still move forward with deploying this?
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-28 16:48 [Bitcoin-development] Duplicate transactions vulnerability Pieter Wuille
` (6 preceding siblings ...)
2012-03-02 1:56 ` Pieter Wuille
@ 2012-03-03 16:41 ` Pieter Wuille
7 siblings, 0 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-03-03 16:41 UTC (permalink / raw)
To: Bitcoin Dev
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> Hello all,
>
> 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.
After getting responses from Deepbit, bitcoin.cz (slush), MtRed, Bitlc
and BTCmine, it looks like march 15 is a reasonable deployment date
for the security update described in BIP 30.
I have created patches for:
* git master: https://github.com/sipa/bitcoin/tree/nooverwritetx
* v0.4.0: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.4.0
* v0.3.24: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.24
* v0.3.24+vinced:
https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.24+vinced
* v0.3.19: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.19
I've asked pool operators to upgrade, and confirm when they have done
so. If you are a miner or pool operator, and have the ability to
upgrade, please do so as well.
Thanks,
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread