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