* [Bitcoin-development] Duplicate transactions vulnerability
@ 2012-02-28 16:48 Pieter Wuille
2012-02-28 17:12 ` Brautigam Róbert
` (7 more replies)
0 siblings, 8 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-02-28 16:48 UTC (permalink / raw)
To: Bitcoin Dev
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-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
[not found] ` <20120229232029.GA6073@vps7135.xlshosting.net>
@ 2012-02-29 23:45 ` Pieter Wuille
2012-03-01 10:15 ` Ben Reeves
0 siblings, 1 reply; 23+ messages in thread
From: Pieter Wuille @ 2012-02-29 23:45 UTC (permalink / raw)
To: Ben Reeves; +Cc: Bitcoin Dev
On Wed, Feb 29, 2012 at 11:00:42PM +0000, Ben Reeves wrote:
> I'm not sure. What if they use a coinbase of a block that has already matured?
Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase.
The 100-blocks maturity will not help against is.
I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward-
compatible way, though.
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-02-29 23:45 ` Pieter Wuille
@ 2012-03-01 10:15 ` Ben Reeves
2012-03-01 13:09 ` Ben Reeves
0 siblings, 1 reply; 23+ messages in thread
From: Ben Reeves @ 2012-03-01 10:15 UTC (permalink / raw)
To: Bitcoin Dev
Yes you are right. Any fix in DisconnectBlock() has the same potential issues.
I think the exchanges and major merchants need to be made aware that
they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and
issue an advisory stating that this is a mandatory upgrade for
everyone.
It also might be prudent to have a blockchain repair script ready,
which checks the db for missing coinbase transactions and downloads
them from another peer or block explorer if necessary.
Thank You,
Ben Reeves
www.blockchain.info
On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> On Wed, Feb 29, 2012 at 11:00:42PM +0000, Ben Reeves wrote:
>> I'm not sure. What if they use a coinbase of a block that has already matured?
>
> Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase.
> The 100-blocks maturity will not help against is.
>
> I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward-
> compatible way, though.
>
> --
> Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-03-01 10:15 ` Ben Reeves
@ 2012-03-01 13:09 ` Ben Reeves
2012-03-01 14:27 ` Gregory Maxwell
2012-03-01 14:30 ` Pieter Wuille
0 siblings, 2 replies; 23+ messages in thread
From: Ben Reeves @ 2012-03-01 13:09 UTC (permalink / raw)
To: Bitcoin Dev
One more thing to add. The implementation in the reference patch fixes
the blockchain forking issue however by still allowing spent coinbases
to be disconnected patched clients are still vulnerable to blockchain
corruption. While not an immediate issue it would mean
LoadBlockIndex() would error on restart and could cause problems for
new clients during the initial blockchain download.
Is there a reason not to disallow duplicate coinbases entirely?
On Thu, Mar 1, 2012 at 10:15 AM, Ben Reeves <support@pi•uk.com> wrote:
> Yes you are right. Any fix in DisconnectBlock() has the same potential issues.
>
> I think the exchanges and major merchants need to be made aware that
> they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and
> issue an advisory stating that this is a mandatory upgrade for
> everyone.
>
> It also might be prudent to have a blockchain repair script ready,
> which checks the db for missing coinbase transactions and downloads
> them from another peer or block explorer if necessary.
>
> Thank You,
> Ben Reeves
> www.blockchain.info
>
> On Wed, Feb 29, 2012 at 11:45 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
>> On Wed, Feb 29, 2012 at 11:00:42PM +0000, Ben Reeves wrote:
>>> I'm not sure. What if they use a coinbase of a block that has already matured?
>>
>> Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old coinbase.
>> The 100-blocks maturity will not help against is.
>>
>> I'm not sure how you intend to fix DisconnectBlock() to prevent this in a backward-
>> compatible way, though.
>>
>> --
>> Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-03-01 13:09 ` Ben Reeves
@ 2012-03-01 14:27 ` Gregory Maxwell
2012-03-01 17:20 ` Ben Reeves
2012-03-01 14:30 ` Pieter Wuille
1 sibling, 1 reply; 23+ messages in thread
From: Gregory Maxwell @ 2012-03-01 14:27 UTC (permalink / raw)
To: Ben Reeves; +Cc: Bitcoin Dev
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves <support@pi•uk.com> wrote:
> One more thing to add. The implementation in the reference patch fixes
> the blockchain forking issue however by still allowing spent coinbases
> to be disconnected patched clients are still vulnerable to blockchain
> corruption. While not an immediate issue it would mean
> LoadBlockIndex() would error on restart and could cause problems for
> new clients during the initial blockchain download.
I am not following you here, can you explain what you're thinking?
> Is there a reason not to disallow duplicate coinbases entirely?
Because this would make it impossible for nodes to prune the vaules.
They'd all forever have to keep a set of all the coinbase hashes in
order to perform the test. The height-in-coinbase BIP will make
duplicates effectively impossible to create, which is a much more
clean behavior.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-03-01 13:09 ` Ben Reeves
2012-03-01 14:27 ` Gregory Maxwell
@ 2012-03-01 14:30 ` Pieter Wuille
1 sibling, 0 replies; 23+ messages in thread
From: Pieter Wuille @ 2012-03-01 14:30 UTC (permalink / raw)
To: Ben Reeves; +Cc: Bitcoin Dev
On Thu, Mar 01, 2012 at 01:09:02PM +0000, Ben Reeves wrote:
> One more thing to add. The implementation in the reference patch fixes
> the blockchain forking issue however by still allowing spent coinbases
> to be disconnected patched clients are still vulnerable to blockchain
> corruption. While not an immediate issue it would mean
> LoadBlockIndex() would error on restart and could cause problems for
> new clients during the initial blockchain download.
I don't understand this.
> Is there a reason not to disallow duplicate coinbases entirely?
Just disallowing duplicate coinbases is possible, but it requires keeping a
set of all coinbases transaction around until infinity. That's not really a problem,
but it can be avoided. One very reasonable proposed solution is adding the block
height to the coinbase. However, as coinbases are used for all kinds of things
already, this is harder to roll out network-wide. Hence, first this "emergency"
solution that already prevents (afaik) all practical attacks, and in a later step
forcing unique coinbases, so that transactions can be assumed to be unique
identifiable by their hash again.
--
Pieter
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Bitcoin-development] Duplicate transactions vulnerability
2012-03-01 14:27 ` Gregory Maxwell
@ 2012-03-01 17:20 ` Ben Reeves
0 siblings, 0 replies; 23+ messages in thread
From: Ben Reeves @ 2012-03-01 17:20 UTC (permalink / raw)
To: Bitcoin Dev
>I am not following you here, can you explain what you're thinking?
If I mine a duplicate coinbase of an old block (whether spent or not)
if that block is then invalidated DisconnectBlock() will erase both
the coinbase of the new block and of the old block. This leaves the
blockchain is in an inconsistent state because with the coinbase
missing the old block will no longer pass CheckBlock().
When affected clients are restarted LoadBlockIndex() will try and
verify all blocks in the main chain, failing at the block with the
missing coinbase.
1) If an attacker was to do this with an early block it would force
all affected clients to redownload the majority of the blockchain.
2) If the attacker was able to do this on a block after the March 1st
deadline (future block A). If they mined a fake copy of block A (block
B) with the same coinbase but a different hash clients who received
block B before block A will refuse to accept block A because of the
unspent duplicate coinbase in block B. The attacker can then fork the
chain at this point despite the real chain being longer.
I am just think out load here so I could be wrong, but maybe it would
be better to go for the full block height fix now?
On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves <support@pi•uk.com> wrote:
>> One more thing to add. The implementation in the reference patch fixes
>> the blockchain forking issue however by still allowing spent coinbases
>> to be disconnected patched clients are still vulnerable to blockchain
>> corruption. While not an immediate issue it would mean
>> LoadBlockIndex() would error on restart and could cause problems for
>> new clients during the initial blockchain download.
>
> I am not following you here, can you explain what you're thinking?
>
>> Is there a reason not to disallow duplicate coinbases entirely?
>
> Because this would make it impossible for nodes to prune the vaules.
> They'd all forever have to keep a set of all the coinbase hashes in
> order to perform the test. The height-in-coinbase BIP will make
> duplicates effectively impossible to create, which is a much more
> clean behavior.
^ 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
end of thread, other threads:[~2012-03-03 16:41 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
2012-02-29 16:47 ` Pieter Wuille
2012-02-29 17:02 ` Amir Taaki
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-02-29 23:00 ` Ben Reeves
[not found] ` <20120229232029.GA6073@vps7135.xlshosting.net>
2012-02-29 23:45 ` Pieter Wuille
2012-03-01 10:15 ` Ben Reeves
2012-03-01 13:09 ` Ben Reeves
2012-03-01 14:27 ` Gregory Maxwell
2012-03-01 17:20 ` Ben Reeves
2012-03-01 14:30 ` Pieter Wuille
2012-03-02 1:56 ` Pieter Wuille
2012-03-03 16:41 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox