<p dir="ltr">Trust, regulation, law, and the threat of force. Are you serious?<br>
</p>
<div class="gmail_quote">On 26 May 2015 11:38 am, Allen Piscitello <allen.piscitello@gmail.com> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What prevents you from writing a bad check using today's systems?</div><div><br /><div class="elided-text">On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe <span dir="ltr"><<a href="mailto:danny.thorpe@gmail.com">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 class="elided-text"><div><div>On Mon, May 25, 2015 at 5:10 PM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org">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">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">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">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">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">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br />
<br /></blockquote></div><br /></div>
</blockquote></div>