[Bitcoin-development] Possible attack: Keeping unconfirmed transactions
rme at i-rme.es
Fri Jun 6 22:21:48 UTC 2014
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.
*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 should broadcast the transaction(s) on the Bitcoin p2p
2014-06-07 0:11 GMT+02:00 Toshi Morita <toshi at peernova.com>:
> From what I know, Alice does not know to which node Bob will broadcast the
> transaction. Therefore, Alice cannot intercept the transaction and prevent
> the rest of the network from seeing it.
> On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez <rme at 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.
>> Alice is selling a pizza to Bob, Bob is now making the payment with
>> 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
>> 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.
>> 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!
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev