diff options
author | Pieter Wuille <pieter.wuille@gmail.com> | 2012-02-28 21:24:15 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2012-02-28 20:42:16 +0000 |
commit | f81478ee0b01056c2025eafece3d392ec372a169 (patch) | |
tree | c62dfc99e28ac2f47e215637be8a6d093245fbdc | |
parent | 434335bbdca654feb16cb32d217b726117be692d (diff) | |
download | pi-bitcoindev-f81478ee0b01056c2025eafece3d392ec372a169.tar.gz pi-bitcoindev-f81478ee0b01056c2025eafece3d392ec372a169.zip |
Re: [Bitcoin-development] Duplicate transactions vulnerability
-rw-r--r-- | 8c/2e5f436929629c08bcb94be7438a21fa67fd96 | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/8c/2e5f436929629c08bcb94be7438a21fa67fd96 b/8c/2e5f436929629c08bcb94be7438a21fa67fd96 new file mode 100644 index 000000000..b848e6c3a --- /dev/null +++ b/8c/2e5f436929629c08bcb94be7438a21fa67fd96 @@ -0,0 +1,77 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pw@vps7135.xlshosting.net>) id 1S2TsG-0004pa-Sn + for bitcoin-development@lists.sourceforge.net; + Tue, 28 Feb 2012 20:42:16 +0000 +X-ACL-Warn: +Received: from vps7135.xlshosting.net ([178.18.90.41]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1S2TsF-0006lD-Og for bitcoin-development@lists.sourceforge.net; + Tue, 28 Feb 2012 20:42:16 +0000 +Received: by vps7135.xlshosting.net (Postfix, from userid 1000) + id 7ABEF60DA2; Tue, 28 Feb 2012 21:24:15 +0100 (CET) +Date: Tue, 28 Feb 2012 21:24:15 +0100 +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Luke-Jr <luke@dashjr.org> +Message-ID: <20120228202414.GA16255@vps7135.xlshosting.net> +References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com> + <201202281323.02976.luke@dashjr.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <201202281323.02976.luke@dashjr.org> +X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc +User-Agent: Mutt/1.5.20 (2009-06-14) +X-Spam-Score: 1.2 (+) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is + CUSTOM_MED + -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, + and not from a mailing list +X-Headers-End: 1S2TsF-0006lD-Og +Cc: bitcoin-development@lists.sourceforge.net +Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 28 Feb 2012 20:42:17 -0000 + +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 + + + |