From: Aaron Voisine <voisine@gmail•com>
To: Danny Thorpe <danny.thorpe@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Date: Tue, 26 May 2015 11:42:37 -0700 [thread overview]
Message-ID: <CACq0ZD7pu0q1P9cMWK-F1s_CHTWuHhawjwiJ_rQT7isYqQ4OFw@mail.gmail.com> (raw)
In-Reply-To: <CAJN5wHV=bVgM16PPQqsOd1Qu+pALeAPmGz4-6xEV1qG6Fo+ToA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5472 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 7254 bytes --]
next prev parent reply other threads:[~2015-05-26 18:42 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 [this message]
2015-05-26 18:47 ` Adam Back
2015-05-26 20:18 ` Matt Whitlock
2015-05-26 20:30 ` joliver
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=CACq0ZD7pu0q1P9cMWK-F1s_CHTWuHhawjwiJ_rQT7isYqQ4OFw@mail.gmail.com \
--to=voisine@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=danny.thorpe@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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