From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WuKB0-0003PJ-6r for bitcoin-development@lists.sourceforge.net; Tue, 10 Jun 2014 11:25:14 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of i-rme.es designates 209.85.215.49 as permitted sender) client-ip=209.85.215.49; envelope-from=rme@i-rme.es; helo=mail-la0-f49.google.com; Received: from mail-la0-f49.google.com ([209.85.215.49]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WuKAy-0000bd-Dk for bitcoin-development@lists.sourceforge.net; Tue, 10 Jun 2014 11:25:14 +0000 Received: by mail-la0-f49.google.com with SMTP id pv20so3777966lab.22 for ; Tue, 10 Jun 2014 04:25:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kaEaUbmXjK17SnGpQ55p8Jt+3qloJ5QSLj5mHUx2Wks=; b=OyAk33AcPvvCaIkrM5fRhUNNmQ/8WcaYxUzQ/ErI3FRvKAmTOkjFUCGZoQkoy+UDqB FAYILABYnrp5qsU35/h+eidaELhALK0YBMhjKbIGKds6bpewUdy12aYbGcE2WoljqATE dlx4mYcpezoKSiLqmRV8TWCKei7fC32h5u+VYf4aShSiAyMNWKcw5u9BUy+Dj3KlSHnS u3PJ/vT0Ufbg6VKIsfpAdvOuZYtXm/rhZCCo98b2Lcf6Nu/Ns5AYKCrgejCNI0iHMgMC HqDYMk/CZVOenEQfiIziweCV9oUsPHhjTxqhmJsIhRl6u4jf0zcHQr5tgebI4thvmwh5 p7+Q== X-Gm-Message-State: ALoCoQnC0514TthPt7mHbsNPM9P06H4XIzr/3FRu3Y27qEHv8zagMaBfv5VmH1bCgIvrPNDHniWh MIME-Version: 1.0 X-Received: by 10.112.72.41 with SMTP id a9mr1027061lbv.71.1402399505507; Tue, 10 Jun 2014 04:25:05 -0700 (PDT) Received: by 10.152.199.8 with HTTP; Tue, 10 Jun 2014 04:25:05 -0700 (PDT) X-Originating-IP: [85.251.84.81] Received: by 10.152.199.8 with HTTP; Tue, 10 Jun 2014 04:25:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Jun 2014 13:25:05 +0200 Message-ID: From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= To: "Chris D'Costa" Content-Type: multipart/alternative; boundary=001a11c341985bf6d704fb7994f5 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 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: 1WuKAy-0000bd-Dk Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions 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: Tue, 10 Jun 2014 11:25:14 -0000 --001a11c341985bf6d704fb7994f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe that the Payment Protocol works that way, the merchant broadcast the Tx. El 10/06/2014 13:23, "Chris D'Costa" escribi=C3=B3= : > I wonder if Raul is mistakenly under the impression that the transaction > only reaches the Bitcoin network via Alice? In which case the premise of > this "attack" is incorrect. > > *Chris D'Costa* > > > Follow on Twitter: *@cjdcosta* > > *------------------------------------------------------------------------= ---------------* > chris.dcosta@meek.io (Meek) > chris.dcosta@sossee.com (Blog) > chrisjdcosta@gmail.com (Personal) > chris.dcosta@bitcoinassociation.be (Belgian Bitcoin Association) > > -------------------------------------------------------------------------= -------------- > > > On 7 June 2014 00:02, Ra=C3=BAl Mart=C3=ADnez wrote: > >> I dont know if this attack is even possible, it came to my mind and I >> will try to explain it as good as possible. >> >> Some transacions keep unconfirmed forever and finally they are purged by >> Bitcoin nodes, mostly due to the lack of fees. >> >> >> Example: >> --------- >> >> Alice is selling a pizza to Bob, Bob is now making the payment with >> Bitcoin. >> The main goal of this attack is to store a unconfirmed transaction send >> by Bob for a few days (it will not be included in the blockchain because= it >> has no fee or due to other reason), Bob might resend the payment or migh= t >> just cancel the deal with Alice. >> >> Bob forgets about that failed trade but a couple of days later, Alice, >> who has stored the signed transacion, relays the transaction to the netw= ork >> (or mines it directly with his own hashpower). >> Bob does not know what is happening, he believed that that transaction >> was "canceled forever", he even does not remember the failed pizza deal. >> >> Alice has now the bitcoins and Bob does not know what happened with his >> money. >> >> --------- >> >> This might also work with the Payment Protocol because when using it Bob >> does not relay the transaction to the network, its Alices job to do it, >> Alice stores it and tells Bob to resend the payment, Bob creates another >> transaction (If has the same inputs as the first TX this does not work) >> (this one is relayed by Alice to the network). >> >> Alice comes back a couple of days later and mines with his hashrate the >> first transaction (the one she didnt relayed to the network). >> >> Alice now has two payments, Bob does not know what happened. >> >> >> ----------- >> >> I hope that I explained well this possible attack, I dont know if there >> is already a fix for this problem or if it is simply impossible to execu= te >> this kind of attack. >> >> Thanks for your time. >> >> >> >> >> >> >> ------------------------------------------------------------------------= ------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and the= ir >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --001a11c341985bf6d704fb7994f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I believe that the Payment Protocol works that way, the merc= hant broadcast the Tx.

El 10/06/2014 13:23, "Chris D'Costa&quo= t; <chrisjdcosta@gmail.com= > escribi=C3=B3:
I wonder if Raul is mistakenly under the impression that t= he transaction only reaches the Bitcoin network via Alice? In which case th= e premise of this "attack" is incorrect. =C2=A0

Chris D'Costa=


Follow on Twitter: @cjdcosta
--------------------------------= -------------------------------------------------------
chris.dco= sta@meek.io (Meek)
chrisjdcosta@gmail.com (Personal)<= /font>
chris.dcosta@bitcoinassociation.be (Belgian Bitcoin Association= )
---------------------= ------------------------------------------------------------------


On 7 June 2014 00:02, Ra=C3=BAl Mart=C3= =ADnez <rme@i-rme.es> wrote:
I dont know if this attack is even possible, it came to my= mind and I will try to explain it as good as possible.

= Some transacions keep unconfirmed forever and finally they are purged by Bi= tcoin nodes, mostly due to the lack of fees.


Example:
---------
<= br>
Alice is selling a pizza to Bob, Bob is now making the paymen= t with Bitcoin.
The main goal of this attack is to store a unconf= irmed transaction send by Bob for a few days (it will not be included in th= e blockchain because it has no fee or due to other reason), Bob might resen= d the payment or might just cancel the deal with Alice.

Bob forgets about that failed trade but a couple of day= s later, Alice, who has stored the signed transacion, relays the transactio= n to the network (or mines it directly with his own hashpower).
Bob does not know what is happening, he believed that that transaction was = "canceled forever", he even does not remember the failed pizza de= al.

Alice has now the bitcoins and Bob does not kn= ow what happened with his money.

---------

This might also work= with the Payment Protocol because when using it Bob does not relay the tra= nsaction to the network, its Alices job to do it, Alice stores it and tells= Bob to resend the payment, Bob creates another transaction (If has the sam= e inputs as the first TX this does not work) (this one is relayed by Alice = to the network).

Alice comes back a couple of days later and mines with = his hashrate the first transaction (the one she didnt relayed to the networ= k).

Alice now has two payments, Bob does not know = what happened.


-----------

I h= ope that I explained well this possible attack, I dont know if there is alr= eady a fix for this problem or if it is simply impossible to execute this k= ind of attack.

Thanks for your time.





-----------------------------------------------------------------------= -------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases = and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/s= fu/NeoTech
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c341985bf6d704fb7994f5--