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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxLmU-0004r1-Jw for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 20:48:58 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of airmail.cc designates 75.102.27.230 as permitted sender) client-ip=75.102.27.230; envelope-from=joliver@airmail.cc; helo=cock.li; Received: from cock.li ([75.102.27.230]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YxLmT-0003FD-FD for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 20:48:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 May 2015 20:30:48 +0000 From: joliver@airmail.cc To: bitcoin-development@lists.sourceforge.net In-Reply-To: <20150526001034.GF21367@savin.petertodd.org> References: <20150525212638.GB12430@savin.petertodd.org> <20150526001034.GF21367@savin.petertodd.org> Message-ID: <475dfb44d4e54649839e6438ad748b59@airmail.cc> X-Sender: joliver@airmail.cc User-Agent: Roundcube Webmail/0.9.5 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YxLmT-0003FD-FD 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:48:58 -0000 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