Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.177 as permitted sender)
	client-ip=209.85.220.177; envelope-from=voisine@gmail.com;
	helo=mail-qk0-f177.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAJN5wHV=bVgM16PPQqsOd1Qu+pALeAPmGz4-6xEV1qG6Fo+ToA@mail.gmail.com>
References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
	<CANEZrP0DL8yA=neK0DTq0npEqc0q+RvTQD57OndNVg0vi2=yMg@mail.gmail.com>
	<20150525212638.GB12430@savin.petertodd.org>
	<CANEZrP1k-rUBSj2GMKqOEZsOuHp=axKUSxShOiN01DorzkFODQ@mail.gmail.com>
	<20150526001034.GF21367@savin.petertodd.org>
	<CAJN5wHV=bVgM16PPQqsOd1Qu+pALeAPmGz4-6xEV1qG6Fo+ToA@mail.gmail.com>
Date: Tue, 26 May 2015 11:42:37 -0700
Message-ID: <CACq0ZD7pu0q1P9cMWK-F1s_CHTWuHhawjwiJ_rQT7isYqQ4OFw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: multipart/alternative; boundary=001a1146918a92e6c30517007dff
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cost savings by using replace-by-fee,
	30-90%
Precedence: list

--001a1146918a92e6c30517007dff
Content-Type: text/plain; charset=UTF-8

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 <danny.thorpe@gmail.com>
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 <pete@petertodd.org> 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
>
>

--001a1146918a92e6c30517007dff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">See the &quot;first-seen-safe replace-by-fee&quot; thread<=
/div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_=
signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aaron Voisine</d=
iv><div>co-founder and CEO<br><a href=3D"http://breadwallet.com" target=3D"=
_blank">breadwallet.com</a></div></div></div></div></div></div>
<br><div class=3D"gmail_quote">On Tue, May 26, 2015 at 11:22 AM, Danny Thor=
pe <span dir=3D"ltr">&lt;<a href=3D"mailto:danny.thorpe@gmail.com" target=
=3D"_blank">danny.thorpe@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">What prevents RBF from being used for frau=
dulent payment reversals? =C2=A0<div><br></div><div>Pay 1BTC to Alice for h=
ard goods, then after you receive the goods broadcast a double spend of tha=
t transaction to pay Alice nothing? Your only cost is the higher network fe=
e of the 2nd tx.</div><div><br></div><div>Thanks,</div><div>-Danny</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div clas=
s=3D"h5">On Mon, May 25, 2015 at 5:10 PM, Peter Todd <span dir=3D"ltr">&lt;=
<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org<=
/a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><d=
iv class=3D"h5">On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:=
<br>
&gt; 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&#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 si=
ze.<br>
I forget to click on the &quot;priority fee&quot; option, so it goes out wi=
th 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<b=
r>
1mBTC/KB for a fast confirmation, so I&#39;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&#39;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&#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>
<br>
Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 costs you more than you sa=
ve<br>
<span><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f<br>
</font></span><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=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</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=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a1146918a92e6c30517007dff--