From: Ben Reeves <support@pi•uk.com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
Date: Tue, 28 Feb 2012 20:35:05 +0000 [thread overview]
Message-ID: <736F8531-28F8-4219-9DE9-3F201FC7DCF4@pi.uk.com> (raw)
In-Reply-To: <201202281323.02976.luke@dashjr.org>
[-- 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 --]
next prev parent reply other threads:[~2012-02-28 21:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 16:48 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=736F8531-28F8-4219-9DE9-3F201FC7DCF4@pi.uk.com \
--to=support@pi$(echo .)uk.com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox