From mboxrd@z Thu Jan 1 00:00:00 1970 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'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"><<a href=3D"mai= lto:joliver@airmail.cc" target=3D"_blank">joliver@airmail.cc</a>></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'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> > 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 BT= C to<br> > Alice. This results in a 1in/2out transaction t1 that's 226 bytes = in<br> > size.<br> > I forget to click on the "priority fee" option, so it goes o= ut 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 yo= u<br> > to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the<b= r> > 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<br> > bytes<br> > in size. I have to pay 2.6uBTC additional fees to pay for the bandwidt= h<br> > consumed broadcasting it, resulting in an additional 36uBTC of fees.<b= r> ><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 i= n<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.<b= r> ><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 need= s<br> > to pay fees for both transactions at once, resulting in a combined<br> > 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 3= 74<br> > bytes in size, paying 374uBTC. Even better, if one of the two inputs i= s<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 =C2=A0costs you more t= han you save<br> ><br> </div></div><span class=3D"im HOEnZb">> --------------------------------= ----------------------------------------------<br> > One dashboard for servers and applications across<br> > Physical-Virtual-Cloud<br> > Widest out-of-the-box monitoring support with 50+ applications<br> > Performance metrics, stats and reports that give you Actionable<br> > Insights<br> > Deep dive visibility with transaction tracing using APM Insight.<br> > <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> ><br> </span><div class=3D"HOEnZb"><div class=3D"h5">> _______________________= ________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <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--