<div dir="ltr">I am not the one presenting this as some kind of novel attack on transactions in general.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 1:43 PM, Raystonn <span dir="ltr"><<a href="mailto:raystonn@hotmail.com" target="_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Trust, regulation, law, and the threat of force. Are you serious?<br>
</p>
<div class="gmail_quote"><span class="">On 26 May 2015 11:38 am, Allen Piscitello <<a href="mailto:allen.piscitello@gmail.com" target="_blank">allen.piscitello@gmail.com</a>> wrote:<br type="attribution"></span><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr">What prevents you from writing a bad check using today's systems?</div></span><div><div class="h5"><div><br><div>On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe <span dir="ltr"><<a href="mailto:danny.thorpe@gmail.com" target="_blank">danny.thorpe@gmail.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br><div><div><div>On Mon, May 25, 2015 at 5:10 PM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br></div></div><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:<br>
> CPFP also solves it just fine.<br>
<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>
<br>
<br>
Case 1: CPFP vs. RBF for increasing the fee on a single tx<br>
----------------------------------------------------------<br>
<br>
Creating an spending a P2PKH output uses 34 bytes of txout, and 148<br>
bytes of txin, 182 bytes total.<br>
<br>
Let'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's 226 bytes in size.<br>
I forget to click on the "priority fee" 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's 192 bytes in size. I want to pay<br>
1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of<br>
transaction fees.<br>
<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>
<br>
Cost savings: 48%<br>
<br>
<br>
Case 2: Paying multiple recipients in succession<br>
------------------------------------------------<br>
<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's change address. Normally t2 would be<br>
another 226 bytes in size, resulting in 226uBTC additional fees.<br>
<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>
<br>
Cost savings: 84%<br>
<br>
<br>
Case 3: Paying multiple recipients from a 2-of-3 multisig wallet<br>
----------------------------------------------------------------<br>
<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>
<br>
Cost savings: 90%<br>
<br>
<br>
Case 4: Dust defragmentation<br>
----------------------------<br>
<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>
<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>
<br>
With RBF I'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>
<br>
Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF<br>
costs you more than you save<br>
<font color="#888888"><br>
--<br>
'peter'[:-1]@<a href="http://petertodd.org" target="_blank">petertodd.org</a><br>
0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f<br>
</font><br></div></div>------------------------------------------------------------------------------<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" target="_blank">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>
<br></blockquote></div><br></div>
<br>------------------------------------------------------------------------------<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" target="_blank">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>
<br></blockquote></div><br></div>
</div></div></blockquote></div></blockquote></div><br></div>