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 only > 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 the > transaction. Therefore, Alice cannot intercept the transaction and prevent > the rest of the network from seeing it. > > Toshi > > > > On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez 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 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. >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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/sfu/NeoTech >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >