path: root/dd/14c443f39cb7237ce3ad5ba497a800adb618c4

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YxLtv-0004Ru-Jo
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 20:56:39 +0000
X-ACL-Warn: 
Received: from mail-ig0-f177.google.com ([209.85.213.177])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YxLtq-0001gb-Cz
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 20:56:39 +0000
Received: by igbpi8 with SMTP id pi8so68796454igb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 26 May 2015 13:56:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=PJtssXAapL9kf7EvgSDZ+WTrR4twkDEcWlJZJuePsaw=;
	b=c9JKkUNboDh0YY8t+egY5cDtwPLR4hNUYRzqBWg512ykQW8oG5t5jshiXbPsWVie6m
	oEhBfI/h3cwKuSe0hWIxj/BMgU5PaF5KNfBeFGJTfoW/2OWUgI2EBF+ZwEeRDis0qa2R
	UBH9JJamCAkr/70vGoEbCwMt5x3zbl1lA18XMGjjBgTCO7SYda4sJhnMKxob9tctVfE0
	M/IkpB7cIPBjaAYDMf63yZqOZx7IhiNcWrMiscAB/oob4bbeG20R0mKCxnYJE19SeFFZ
	8aM8nigN5aRtETL1CQg5s6Bx4EOJm711p199vlin1a72hJqa1RAmO9/5E5ieLN2uQOQf
	FUGg==
X-Gm-Message-State: ALoCoQlhrr4K8/QNiFuvf6dl6yFoTd/FE4VxBG0Z3/kbv/RWCdsy8fZmLg2tkOSU8/FYOvwZRCdQ
X-Received: by 10.50.85.113 with SMTP id g17mr32163183igz.46.1432673786943;
	Tue, 26 May 2015 13:56:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.197 with HTTP; Tue, 26 May 2015 13:56:06 -0700 (PDT)
X-Originating-IP: [96.90.217.22]
In-Reply-To: <475dfb44d4e54649839e6438ad748b59@airmail.cc>
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>
	<475dfb44d4e54649839e6438ad748b59@airmail.cc>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 26 May 2015 13:56:06 -0700
Message-ID: <CAOG=w-vmYh_KJk7zpVP0=gvKTod7yYy9jhORNQJNRg=rDBHDOA@mail.gmail.com>
To: joliver@airmail.cc
Content-Type: multipart/alternative; boundary=089e014954e02671d80517025c5b
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YxLtq-0001gb-Cz
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cost savings by using replace-by-fee,
	30-90%
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 20:56:39 -0000

--089e014954e02671d80517025c5b
Content-Type: text/plain; charset=UTF-8

Please let's at least have some civility and decorum on this list.

On Tue, May 26, 2015 at 1:30 PM, <joliver@airmail.cc> wrote:

> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
>
>
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>
> On 2015-05-26 00:10, 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
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr">Please let&#39;s at least have some civility and decorum o=
n this list.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Tue, May 26, 2015 at 1:30 PM,  <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:joliver@airmail.cc" target=3D"_blank">joliver@airmail.cc</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">You&#39;re the Chief Scientist of=
 __ViaCoin__ a alt with 30 second blocks<br>
and you have big banks as clients. Shit like replace-by-fee and leading<br>
the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.<br=
>
<br>
Peter Todd - 8930511 Canada Ltd.<br>
1214-1423 Mississauga Valley Blvd.<br>
Mississauga ON L5A 4A5<br>
Canada<br>
<br>
<a href=3D"https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.h=
tml?corpId=3D8930511" target=3D"_blank">https://www.ic.gc.ca/app/scr/cc/Cor=
porationsCanada/fdrlCrpDtls.html?corpId=3D8930511</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 2015-05-26 00:10, Peter Todd wrote:<br>
&gt; On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:<br>
&gt;&gt; CPFP also solves it just fine.<br>
&gt;<br>
&gt; CPFP is a significantly more expensive way of paying fees than RBF,<br=
>
&gt; particularly for the use-case of defragmenting outputs, with cost<br>
&gt; savings ranging from 30% to 90%<br>
&gt;<br>
&gt;<br>
&gt; Case 1: CPFP vs. RBF for increasing the fee on a single tx<br>
&gt; ----------------------------------------------------------<br>
&gt;<br>
&gt; Creating an spending a P2PKH output uses 34 bytes of txout, and 148<br=
>
&gt; bytes of txin, 182 bytes total.<br>
&gt;<br>
&gt; Let&#39;s suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BT=
C to<br>
&gt; Alice. This results in a 1in/2out transaction t1 that&#39;s 226 bytes =
in<br>
&gt; size.<br>
&gt; I forget to click on the &quot;priority fee&quot; option, so it goes o=
ut with the<br>
&gt; minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,<br>
&gt; creating a new transaction t2 that&#39;s 192 bytes in size. I want to =
pay<br>
&gt; 1mBTC/KB for a fast confirmation, so I&#39;m now paying 418uBTC of<br>
&gt; transaction fees.<br>
&gt;<br>
&gt; On the other hand, had I use RBF, my wallet would have simply<br>
&gt; rebroadcast t1 with the change address decreased. The rules require yo=
u<br>
&gt; to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the<b=
r>
&gt; new<br>
&gt; fee level, or 218uBTC of fees in total.<br>
&gt;<br>
&gt; Cost savings: 48%<br>
&gt;<br>
&gt;<br>
&gt; Case 2: Paying multiple recipients in succession<br>
&gt; ------------------------------------------------<br>
&gt;<br>
&gt; Suppose that after I pay Alice, I also decide to pay Bob for his hard<=
br>
&gt; work demonstrating cryptographic protocols. I need to create a new<br>
&gt; transaction t2 spending t1&#39;s change address. Normally t2 would be<=
br>
&gt; another 226 bytes in size, resulting in 226uBTC additional fees.<br>
&gt;<br>
&gt; With RBF on the other hand I can simply double-spend t1 with a<br>
&gt; transaction paying both Alice and Bob. This new transaction is 260<br>
&gt; bytes<br>
&gt; in size. I have to pay 2.6uBTC additional fees to pay for the bandwidt=
h<br>
&gt; consumed broadcasting it, resulting in an additional 36uBTC of fees.<b=
r>
&gt;<br>
&gt; Cost savings: 84%<br>
&gt;<br>
&gt;<br>
&gt; Case 3: Paying multiple recipients from a 2-of-3 multisig wallet<br>
&gt; ----------------------------------------------------------------<br>
&gt;<br>
&gt; The above situation gets even worse with multisig. t1 in the multisig<=
br>
&gt; case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC=
<br>
&gt; in fees. With RBF we rewrite t1 with an additional output, resulting i=
n<br>
&gt; a 399 byte transaction, with just 36uBTC in additional fees.<br>
&gt;<br>
&gt; Cost savings: 90%<br>
&gt;<br>
&gt;<br>
&gt; Case 4: Dust defragmentation<br>
&gt; ----------------------------<br>
&gt;<br>
&gt; My wallet has a two transaction outputs that it wants to combine into<=
br>
&gt; one for the purpose of UTXO defragmentation. It broadcasts transaction=
<br>
&gt; t1 with two inputs and one output, size 340 bytes, paying zero fees.<b=
r>
&gt;<br>
&gt; Prior to the transaction confirming I find I need to spend those funds=
<br>
&gt; for a priority transaction at the 1mBTC/KB fee level. This transaction=
,<br>
&gt; t2a, has one input and two outputs, 226 bytes in size. However it need=
s<br>
&gt; to pay fees for both transactions at once, resulting in a combined<br>
&gt; total<br>
&gt; fee of 556uBTC. If this situation happens frequently, defragmenting<br=
>
&gt; UTXOs is likely to cost more in additional fees than it saves.<br>
&gt;<br>
&gt; With RBF I&#39;d simply doublespend t1 with a 2-in-2-out transaction 3=
74<br>
&gt; bytes in size, paying 374uBTC. Even better, if one of the two inputs i=
s<br>
&gt; sufficiently large to cover my costs I can doublespend t1 with a<br>
&gt; 1-in-2-out tx just 226 bytes in size, paying 226uBTC.<br>
&gt;<br>
&gt; Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0costs you more t=
han you save<br>
&gt;<br>
</div></div><span class=3D"im HOEnZb">&gt; --------------------------------=
----------------------------------------------<br>
&gt; One dashboard for servers and applications across<br>
&gt; Physical-Virtual-Cloud<br>
&gt; Widest out-of-the-box monitoring support with 50+ applications<br>
&gt; Performance metrics, stats and reports that give you Actionable<br>
&gt; Insights<br>
&gt; Deep dive visibility with transaction tracing using APM Insight.<br>
&gt; <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" ta=
rget=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a>=
<br>
&gt;<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">&gt; _______________________=
________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
---------------------------------------------------------------------------=
---<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>
</div></div></blockquote></div><br></div>

--089e014954e02671d80517025c5b--