summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRaúl Martínez <rme@i-rme.es>2014-06-07 00:02:36 +0200
committerbitcoindev <bitcoindev@gnusha.org>2014-06-06 22:03:16 +0000
commit3225283409968bdedb375c39f7374c7244860209 (patch)
treeb507fad64c7899ff9af43b6d7faa00c29d922304
parent55f5c370a82c1523f5511dd6fe339cdd4c60f061 (diff)
downloadpi-bitcoindev-3225283409968bdedb375c39f7374c7244860209.tar.gz
pi-bitcoindev-3225283409968bdedb375c39f7374c7244860209.zip
[Bitcoin-development] Possible attack: Keeping unconfirmed transactions
-rw-r--r--cf/5cf708b763031b69db6f6e7aca20fd23a97204166
1 files changed, 166 insertions, 0 deletions
diff --git a/cf/5cf708b763031b69db6f6e7aca20fd23a97204 b/cf/5cf708b763031b69db6f6e7aca20fd23a97204
new file mode 100644
index 000000000..efe2a93c8
--- /dev/null
+++ b/cf/5cf708b763031b69db6f6e7aca20fd23a97204
@@ -0,0 +1,166 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <rme@i-rme.es>) id 1Wt2EG-0002ty-Ew
+ for bitcoin-development@lists.sourceforge.net;
+ Fri, 06 Jun 2014 22:03:16 +0000
+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of i-rme.es
+ designates 209.85.215.52 as permitted sender)
+ client-ip=209.85.215.52; envelope-from=rme@i-rme.es;
+ helo=mail-la0-f52.google.com;
+Received: from mail-la0-f52.google.com ([209.85.215.52])
+ by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
+ (Exim 4.76) id 1Wt2ED-0005fe-RP
+ for bitcoin-development@lists.sourceforge.net;
+ Fri, 06 Jun 2014 22:03:14 +0000
+Received: by mail-la0-f52.google.com with SMTP id s18so1913251lam.11
+ for <bitcoin-development@lists.sourceforge.net>;
+ Fri, 06 Jun 2014 15:03:06 -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:from:date:message-id:subject:to
+ :content-type;
+ bh=N1v67UnoqlIwJlvmaRkqh5oAhI5y4vIW/5PScAT8P20=;
+ b=RYQGmVqtGTp8BHuIMBxfoG6jbx4SzS9Ib0/etffQJ6lPMBPsEjFsl9q7T+Q3rE4lw7
+ As4ka2sTAyE176CisM94IemFL4UR582mZRiBSWDVW2htDU7Gi+jaeVOid/2iE3UpXwHO
+ nufwkRIy25qKGCdBfUjA69mm2Ie5mO+r8TAb+Wun0UKnv9lxqU5KM02b+wUE0g8kabAo
+ QLGC92gMLJioNxSTSQ5PbjcmwaZIrQHhaUaJE3THuLsYfrUv0RrsQ/lP+xOfAN9ItqVI
+ 63MGodfIzk5+ucX0PYPpaAHA+7RzAvQEw3SqzupJukUUd5nS5oCYJ6P0lmJqr+sDsqx9
+ 9BSA==
+X-Gm-Message-State: ALoCoQkcmGHtMkHUwkLbve4XaOj5Vp5CvbLpK/sXl5gbPhQn72bJLbwVtsa2TIuC4wk4GoHWGIXa
+X-Received: by 10.112.14.5 with SMTP id l5mr5415243lbc.12.1402092186648; Fri,
+ 06 Jun 2014 15:03:06 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.152.199.8 with HTTP; Fri, 6 Jun 2014 15:02:36 -0700 (PDT)
+X-Originating-IP: [85.251.84.81]
+From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es>
+Date: Sat, 7 Jun 2014 00:02:36 +0200
+Message-ID: <CA+8=xu+Bo5W+i__c-QMo+9sTTWzs4mi-wF9FFR1axPPRf5MO1A@mail.gmail.com>
+To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
+Content-Type: multipart/alternative; boundary=001a11c377d6ba5a3b04fb3206b5
+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: 1Wt2ED-0005fe-RP
+Subject: [Bitcoin-development] Possible attack: Keeping unconfirmed
+ transactions
+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: Fri, 06 Jun 2014 22:03:16 -0000
+
+--001a11c377d6ba5a3b04fb3206b5
+Content-Type: text/plain; charset=UTF-8
+
+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 might
+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 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 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 execute
+this kind of attack.
+
+Thanks for your time.
+
+--001a11c377d6ba5a3b04fb3206b5
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<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>
+
+--001a11c377d6ba5a3b04fb3206b5--
+
+