See the "first-seen-safe replace-by-fee" thread Aaron Voisine co-founder and CEO breadwallet.com On Tue, May 26, 2015 at 11:22 AM, Danny Thorpe wrote: > What prevents RBF from being used for fraudulent payment reversals? > > Pay 1BTC to Alice for hard goods, then after you receive the goods > broadcast a double spend of that transaction to pay Alice nothing? Your > only cost is the higher network fee of the 2nd tx. > > Thanks, > -Danny > > On Mon, May 25, 2015 at 5:10 PM, Peter Todd wrote: > >> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: >> > CPFP also solves it just fine. >> >> CPFP is a significantly more expensive way of paying fees than RBF, >> particularly for the use-case of defragmenting outputs, with cost >> savings ranging from 30% to 90% >> >> >> Case 1: CPFP vs. RBF for increasing the fee on a single tx >> ---------------------------------------------------------- >> >> Creating an spending a P2PKH output uses 34 bytes of txout, and 148 >> bytes of txin, 182 bytes total. >> >> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to >> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. >> I forget to click on the "priority fee" option, so it goes out with the >> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, >> creating a new transaction t2 that's 192 bytes in size. I want to pay >> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of >> transaction fees. >> >> On the other hand, had I use RBF, my wallet would have simply >> rebroadcast t1 with the change address decreased. The rules require you >> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new >> fee level, or 218uBTC of fees in total. >> >> Cost savings: 48% >> >> >> Case 2: Paying multiple recipients in succession >> ------------------------------------------------ >> >> Suppose that after I pay Alice, I also decide to pay Bob for his hard >> work demonstrating cryptographic protocols. I need to create a new >> transaction t2 spending t1's change address. Normally t2 would be >> another 226 bytes in size, resulting in 226uBTC additional fees. >> >> With RBF on the other hand I can simply double-spend t1 with a >> transaction paying both Alice and Bob. This new transaction is 260 bytes >> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth >> consumed broadcasting it, resulting in an additional 36uBTC of fees. >> >> Cost savings: 84% >> >> >> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet >> ---------------------------------------------------------------- >> >> The above situation gets even worse with multisig. t1 in the multisig >> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC >> in fees. With RBF we rewrite t1 with an additional output, resulting in >> a 399 byte transaction, with just 36uBTC in additional fees. >> >> Cost savings: 90% >> >> >> Case 4: Dust defragmentation >> ---------------------------- >> >> My wallet has a two transaction outputs that it wants to combine into >> one for the purpose of UTXO defragmentation. It broadcasts transaction >> t1 with two inputs and one output, size 340 bytes, paying zero fees. >> >> Prior to the transaction confirming I find I need to spend those funds >> for a priority transaction at the 1mBTC/KB fee level. This transaction, >> t2a, has one input and two outputs, 226 bytes in size. However it needs >> to pay fees for both transactions at once, resulting in a combined total >> fee of 556uBTC. If this situation happens frequently, defragmenting >> UTXOs is likely to cost more in additional fees than it saves. >> >> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 >> bytes in size, paying 374uBTC. Even better, if one of the two inputs is >> sufficiently large to cover my costs I can doublespend t1 with a >> 1-in-2-out tx just 226 bytes in size, paying 226uBTC. >> >> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF >> costs you more than you save >> >> -- >> 'peter'[:-1]@petertodd.org >> 0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >