diff options
author | Raúl Martínez <rme@i-rme.es> | 2014-06-07 00:02:36 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-06-06 22:03:16 +0000 |
commit | 3225283409968bdedb375c39f7374c7244860209 (patch) | |
tree | b507fad64c7899ff9af43b6d7faa00c29d922304 | |
parent | 55f5c370a82c1523f5511dd6fe339cdd4c60f061 (diff) | |
download | pi-bitcoindev-3225283409968bdedb375c39f7374c7244860209.tar.gz pi-bitcoindev-3225283409968bdedb375c39f7374c7244860209.zip |
[Bitcoin-development] Possible attack: Keeping unconfirmed transactions
-rw-r--r-- | cf/5cf708b763031b69db6f6e7aca20fd23a97204 | 166 |
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 = +"canceled forever", 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-- + + |