From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wt2Wp-0003xL-KK for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 22:22:27 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of i-rme.es designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; envelope-from=rme@i-rme.es; helo=mail-la0-f44.google.com; Received: from mail-la0-f44.google.com ([209.85.215.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wt2Wn-0006zh-Ji for bitcoin-development@lists.sourceforge.net; Fri, 06 Jun 2014 22:22:27 +0000 Received: by mail-la0-f44.google.com with SMTP id hr17so1919921lab.17 for ; Fri, 06 Jun 2014 15:22:18 -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:from:date :message-id:subject:to:cc:content-type; bh=J2b11q/8Ra2irYNueb0tLHj1qpAckTZO/ENNehYHmNQ=; b=iLzz5Vwr1trohp9y0SJ5Z01vPTshmebGbl55B25SG7lzr/Aesm5gaABGkjNorLpqhZ 0bpNpX67qmdf/aACHWR2OcpiNeb+7gSyrAZdlhkS6ocMIoTw7jFN2Y/SqyEyz/UAr3So 1u10yp+KyU9k45RNwQxgG+ZqsLXxwcRAD0yavhk7N88dNwIXL8SxjY5d5UIztQ6NT3lP XPZ/6p3z8XgM7L50uSs34MLJvpY7tWQIYNqUGynfofGsAf+cki9BbeJl12Ft6ZZ+WKH3 M248R3JSGwraKotsYBtsUmtyqNRPnt4fWA6Gw6Mkxa1JbPeoIKp2FO3NmL+qLYwJz94m 7XNg== X-Gm-Message-State: ALoCoQntL2MijAIQ07aymHEtJPgDDI7GJN5Xz0PEMbRHLRi7npKcEJKaW+xFT7ssEzD09MQ8UPqk X-Received: by 10.152.29.200 with SMTP id m8mr4552474lah.49.1402093338616; Fri, 06 Jun 2014 15:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.199.8 with HTTP; Fri, 6 Jun 2014 15:21:48 -0700 (PDT) X-Originating-IP: [85.251.84.81] In-Reply-To: References: From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= Date: Sat, 7 Jun 2014 00:21:48 +0200 Message-ID: To: Toshi Morita Content-Type: multipart/alternative; boundary=089e0158c29c63fcc404fb324b74 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: 1Wt2Wn-0006zh-Ji 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: Fri, 06 Jun 2014 22:22:27 -0000 --089e0158c29c63fcc404fb324b74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alice does not intercept the transaction, she only saves it and expect that it will not be confirmed (because has 0 fee for example). Also using the Payment Protocol I believe that Alice is the only person that can relay Bob's transaction. Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki *When the merchant's server receives the Payment message, it must determine > whether or not the transactions satisfy conditions of payment. If and onl= y > if they do, if should broadcast the transaction(s) on the Bitcoin p2p > network.* > 2014-06-07 0:11 GMT+02:00 Toshi Morita : > From what I know, Alice does not know to which node Bob will broadcast th= e > transaction. Therefore, Alice cannot intercept the transaction and preven= t > the rest of the network from seeing it. > > Toshi > > > > On Fri, Jun 6, 2014 at 3:02 PM, Ra=C3=BAl Mart=C3=ADnez wr= ote: > >> 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 >> >> > --089e0158c29c63fcc404fb324b74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alice does not intercept the transaction, she only saves i= t and expect that it will not be confirmed (because has 0 fee for example).=

Also using the Payment Protocol I believe that Alice is= the only person that can relay Bob's transaction.


When the merchant's= server receives the Payment message, it must determine whether or not the = transactions satisfy conditions of payment. If and only if they do, if shou= ld broadcast the transaction(s) on the Bitcoin p2p network.


2014-06-07 0:11 GMT+02:00 Toshi Morita <toshi@peernova.com>= :
From what I know, Alice doe= s not know to which node Bob will broadcast the transaction. Therefore, Ali= ce cannot intercept the transaction and prevent the rest of the network fro= m seeing it.

Toshi



On Fri, Jun 6, 2014 at 3:02 PM, R= a=C3=BAl Mart=C3=ADnez <rme@i-rme.es> wrote:
I dont know if this attack is even possible, it came to my mind an= d I will try to explain it as good as possible.

Some transacions keep unconfirmed forever and finally they a= re purged by Bitcoin 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



--089e0158c29c63fcc404fb324b74--