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; 
MIME-Version: 1.0
In-Reply-To: <CAC0TF=nNJ9qN+VCf8opwL822HA3L7sHpjV0v3=mCG51=y7V56w@mail.gmail.com>
References: <CA+8=xu+Bo5W+i__c-QMo+9sTTWzs4mi-wF9FFR1axPPRf5MO1A@mail.gmail.com>
	<CAC0TF=nNJ9qN+VCf8opwL822HA3L7sHpjV0v3=mCG51=y7V56w@mail.gmail.com>
Date: Tue, 10 Jun 2014 13:25:05 +0200
Message-ID: <CA+8=xuJ_jvX8ZtjTkgW37u1kjBUfYK9gxw22-y1CD5HqB6konA@mail.gmail.com>
From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es>
To: "Chris D'Costa" <chrisjdcosta@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c341985bf6d704fb7994f5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Possible attack: Keeping unconfirmed
	transactions
Precedence: list

--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" <chrisjdcosta@gmail.com> 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 <chris_dcosta@me.com> (Personal)
> 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
>> 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

<p dir=3D"ltr">I believe that the Payment Protocol works that way, the merc=
hant broadcast the Tx.</p>
<div class=3D"gmail_quote">El 10/06/2014 13:23, &quot;Chris D&#39;Costa&quo=
t; &lt;<a href=3D"mailto:chrisjdcosta@gmail.com">chrisjdcosta@gmail.com</a>=
&gt; escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">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 &quot;attack&quot; is incorrect. =C2=A0<div class=3D"gmai=
l_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><b><font style=3D"background-color:=
rgb(255,255,255)" color=3D"#0b5394" size=3D"4">Chris D&#39;Costa</font></b>=
<div><br></div><div><font><br></font></div><div><font>Follow on Twitter: <b=
>@cjdcosta</b></font></div>

<div><b><font color=3D"#9fc5e8" size=3D"1">--------------------------------=
-------------------------------------------------------</font></b></div><di=
v><font><a href=3D"mailto:chris.dcosta@meek.io" target=3D"_blank">chris.dco=
sta@meek.io</a> (Meek)</font></div>

<div><font><a href=3D"mailto:chris.dcosta@sossee.com" target=3D"_blank">chr=
is.dcosta@sossee.com</a> (Blog)</font></div><div><font><a href=3D"mailto:ch=
ris_dcosta@me.com" target=3D"_blank">chrisjdcosta@gmail.com</a> (Personal)<=
/font></div>

<div><font><a href=3D"mailto:chris.dcosta@bitcoinassociation.be" target=3D"=
_blank">chris.dcosta@bitcoinassociation.be</a> (Belgian Bitcoin Association=
)</font></div><div><font color=3D"#9fc5e8" size=3D"1">---------------------=
------------------------------------------------------------------</font><b=
r>

</div></div></div>
<br><br><div class=3D"gmail_quote">On 7 June 2014 00:02, Ra=C3=BAl Mart=C3=
=ADnez <span dir=3D"ltr">&lt;<a href=3D"mailto:rme@i-rme.es" target=3D"_bla=
nk">rme@i-rme.es</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">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.<div><br></div><div>=
Some transacions keep unconfirmed forever and finally they are purged by Bi=
tcoin nodes, mostly due to the lack of fees.</div>



<div><br></div><div><br></div><div>Example:</div><div>---------</div><div><=
br></div><div>Alice is selling a pizza to Bob, Bob is now making the paymen=
t with Bitcoin.</div><div>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.</div>



<div><br></div><div>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).</div><div>



Bob does not know what is happening, he believed that that transaction was =
&quot;canceled forever&quot;, he even does not remember the failed pizza de=
al.</div><div><br></div><div>Alice has now the bitcoins and Bob does not kn=
ow what happened with his money.</div>



<div><br></div><div>---------</div><div><br></div><div>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).</div>



<div><br></div><div>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).</div><div><br></div><div>Alice now has two payments, Bob does not know =
what happened.</div>



<div><br></div><div><br></div><div>-----------</div><div><br></div><div>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.</div>



<div><br></div><div>Thanks for your time.</div><div><br></div><div><br></di=
v><div><br></div><div><br></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/NeoTech" target=3D"_blank">http://p.sf.net/s=
fu/NeoTech</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div>

--001a11c341985bf6d704fb7994f5--