public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: joliver@airmail.cc
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Date: Tue, 26 May 2015 20:30:48 +0000	[thread overview]
Message-ID: <475dfb44d4e54649839e6438ad748b59@airmail.cc> (raw)
In-Reply-To: <20150526001034.GF21367@savin.petertodd.org>

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



  parent reply	other threads:[~2015-05-26 20:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-09 17:09 [Bitcoin-development] A suggestion for reducing the size of the UTXO database Jim Phillips
2015-05-09 18:45 ` Peter Todd
2015-05-09 19:02   ` Jim Phillips
2015-05-09 19:00 ` Andreas Schildbach
2015-05-09 19:05   ` Jim Phillips
2015-05-09 19:06   ` Pieter Wuille
2015-05-09 19:16     ` Jim Phillips
2015-05-09 19:43       ` Ross Nicoll
     [not found] ` <3862E01F-FD0F-48F5-A6D9-F8E0FB0AB68F@newcastle.ac.uk>
     [not found]   ` <CANe1mWys1gAO1CgPEpD7rdtXF2KYfvXA6bc0q-rAzg9xOFc-5A@mail.gmail.com>
     [not found]     ` <8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk>
2015-05-09 19:28       ` Jim Phillips
2015-05-10  2:11 ` Matt Whitlock
2015-05-10 12:11   ` Jim Phillips
2015-05-25 18:41   ` Mike Hearn
2015-05-25 20:03     ` Matt Whitlock
2015-05-25 20:29       ` Andreas Schildbach
2015-05-25 21:05         ` Peter Todd
2015-05-26 12:40           ` Andreas Schildbach
2015-05-25 21:14         ` Warren Togami Jr.
2015-05-25 21:12       ` Mike Hearn
2015-05-10 13:35 ` Bob McElrath
2015-05-10 14:33   ` Jeff Garzik
2015-05-10 14:42     ` Bob McElrath
2015-05-12 19:50 ` Danny Thorpe
2015-05-25 18:44 ` Mike Hearn
2015-05-25 21:26   ` Peter Todd
2015-05-25 22:03     ` Mike Hearn
2015-05-26  0:10       ` [Bitcoin-development] Cost savings by using replace-by-fee, 30-90% Peter Todd
2015-05-26 18:22         ` Danny Thorpe
2015-05-26 18:38           ` Allen Piscitello
2015-05-26 18:42           ` Aaron Voisine
2015-05-26 18:47           ` Adam Back
2015-05-26 20:18           ` Matt Whitlock
2015-05-26 20:30         ` joliver [this message]
2015-05-26 20:56           ` Mark Friedenbach
2015-05-26 21:29           ` s7r
2015-05-26 22:06             ` Adam Back
2015-05-27  1:25             ` Peter Todd
2015-05-27 19:28               ` s7r
2015-05-26 22:29           ` Jeff Garzik
2015-05-26 18:43 Raystonn
2015-05-26 20:12 ` Allen Piscitello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=475dfb44d4e54649839e6438ad748b59@airmail.cc \
    --to=joliver@airmail.cc \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox