Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ucb1E-0002AC-0Q for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 12:41:20 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f52.google.com; Received: from mail-la0-f52.google.com ([209.85.215.52]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ucb1A-0002bl-FY for bitcoin-development@lists.sourceforge.net; Wed, 15 May 2013 12:41:19 +0000 Received: by mail-la0-f52.google.com with SMTP id fo13so1690634lab.39 for ; Wed, 15 May 2013 05:41:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.144.165 with SMTP id sn5mr17480972lbb.48.1368621669691; Wed, 15 May 2013 05:41:09 -0700 (PDT) Received: by 10.112.143.38 with HTTP; Wed, 15 May 2013 05:41:09 -0700 (PDT) In-Reply-To: <20130515113827.GB26020@savin> References: <20130515113827.GB26020@savin> Date: Wed, 15 May 2013 14:41:09 +0200 Message-ID: From: Melvin Carvalho To: Peter Todd Content-Type: multipart/alternative; boundary=047d7b3a84367436bd04dcc110aa X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Ucb1A-0002bl-FY Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 12:41:20 -0000 --047d7b3a84367436bd04dcc110aa Content-Type: text/plain; charset=ISO-8859-1 On 15 May 2013 13:38, Peter Todd wrote: > Now that I have the replace-by-fee reward, I might as well spread the > wealth a bit. > > > So for all this discussion about replace-by-fee and the supposed > security of zero-conf transactions, no-one seems to think much about how > in practice very few vendors have a setup to detect if conflicting > transactions were broadcast on the network simultaneously - after all if > that is the case which transaction gets mined is up to chance, so much > of the time you'll get away with a double spend. We don't yet have a > mechanism to propagate double-spend warnings, and funny enough, in the > case of a single txin transaction the double-spend warning is also > enough information to allow miners to implement replace-by-fee. > > > So I'm offering 2BTC for anyone who comes up with a nice and easy to use > command line tool that lets you automagically create one version of the > transaction sending the coins to the desired recipient, and another > version sending all the coins back to you, both with the same > transaction inputs. In addition to creating the two versions, you need > to find a way to broadcast them both simultaneously to different nodes > on the network. One clever approach might be to use blockchain.info's > raw transaction POST API, and your local Bitcoin node. > > If you happen to be at the conference, a cool demo would be to > demonstrate the attack against my Android wallet. I'll buy Bitcoins off > of you at Mt. Gox rates + %10, and you can see if you can rip me off. > Yes, you can keep the loot. :) This should be videotaped so we can put > an educational video on youtube after. > Isnt it potentially inviting trouble by encouraging people to insert double spends into the block chain? Sure, zero conf isnt 100% safe, we all know that. But neither is the postal service. Doesnt mean we should be going around promoting the creation of tools to go into people's maiilboxes and open their letters! > > -- > 'peter'[:-1]@petertodd.org > 00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5 > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --047d7b3a84367436bd04dcc110aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 15 May 2013 13:38, Peter Todd <pete@petertodd.org> wrote:
Now that I have the replace-by-fee reward, I= might as well spread the
wealth a bit.


So for all this discussion about replace-by-fee and the supposed
security of zero-conf transactions, no-one seems to think much about how in practice very few vendors have a setup to detect if conflicting
transactions were broadcast on the network simultaneously - after all if that is the case which transaction gets mined is up to chance, so much
of the time you'll get away with a double spend. We don't yet have = a
mechanism to propagate double-spend warnings, and funny enough, in the
case of a single txin transaction the double-spend warning is also
enough information to allow miners to implement replace-by-fee.


So I'm offering 2BTC for anyone who comes up with a nice and easy to us= e
command line tool that lets you automagically create one version of the
transaction sending the coins to the desired recipient, and another
version sending all the coins back to you, both with the same
transaction inputs. In addition to creating the two versions, you need
to find a way to broadcast them both simultaneously to different nodes
on the network. One clever approach might be to use blockchain.info's
raw transaction POST API, and your local Bitcoin node.

If you happen to be at the conference, a cool demo would be to
demonstrate the attack against my Android wallet. I'll buy Bitcoins off=
of you at Mt. Gox rates + %10, and you can see if you can rip me off.
Yes, you can keep the loot. :) This should be videotaped so we can put
an educational video on youtube after.

= Isnt it potentially inviting trouble by encouraging people to insert double= spends into the block chain?

Sure, zero conf isnt 100% s= afe, we all know that.

But neither is the postal service.=A0 Doesnt mean we should be going ar= ound promoting the creation of tools to go into people's maiilboxes and= open their letters!
=A0

--
'peter'[:-1]@pet= ertodd.org
00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5

---------------------------------------------------------= ---------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial.
http://p.s= f.net/sfu/alienvault_d2d
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7b3a84367436bd04dcc110aa--