From: Rhavar <rhavar@protonmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
Date: Mon, 22 Jan 2018 15:09:20 -0500 [thread overview]
Message-ID: <tSFdDDXQYpeVlmLo43wABP1gQfqSflgWxl5xKnVErxHDet9hzqFNI2MXU4BWbi-iGK2gIjENeqHxu_9ni0g_BJZX9trx7o_1T_0AV62Ph90=@protonmail.com> (raw)
In-Reply-To: <20180122200023.GA1055@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
It's actually a common misconception. With good coin selection, I am able to avoid change about ~75% of the time in my simulations (on my real world data). In practice it's a bit lower, probably about 40-50% of the time because of the need to keep the majority of my funds offline where they can't be used for coin selection, and I have not been able to accurate simulate how I consolidate.
Also the other misconception is that inputs don't need to match exactly the requested payment, it's totally fine to do something I call a "miner sacrifice" where you overpay txfees up to the amount that that would otherwise be the total cost (immediate + consolidation) of creating change.
Also another trick I use, is something I call "output selection". If I have N queued non-time sensitive payments, I don't really need to send them all at the same time. So I can pick the best combination of inputs+outputs.
Obviously none of this applies to consumer wallets, who typically have less than a handful of options. But for a service, avoiding change can be the norm with good coin selection.
---
-Ryan
-------- Original Message --------
On January 22, 2018 3:00 PM, Peter Todd <pete@petertodd•org> wrote:
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
>> So my half-baked idea is very simple:
>> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>> ---------------------------------------------------------------
>>
>> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>> However, the real problem is tracking the mess. Consider this sequence of events:
>>
>> - I have unconfirmed transaction A
>> - I replace it with B, which pays John 1 BTC
>> - Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Type: text/html, Size: 5143 bytes --]
next prev parent reply other threads:[~2018-01-22 20:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 17:40 Rhavar
2018-01-22 18:16 ` Alan Evans
2018-01-22 18:18 ` Rhavar
2018-01-22 18:50 ` Moral Agent
2018-01-22 18:59 ` Rhavar
2018-01-22 20:00 ` Peter Todd
2018-01-22 20:09 ` Rhavar [this message]
2018-01-23 16:31 ` Rhavar
2018-01-23 21:56 ` Moral Agent
2018-01-23 22:19 ` Rhavar
2018-01-23 22:49 ` Gregory Maxwell
2018-01-24 7:44 ` Peter Todd
2018-01-24 13:43 ` Alan Evans
2018-01-24 16:05 ` Rhavar
2018-01-28 16:43 ` Sjors Provoost
2018-01-28 17:29 ` David A. Harding
2018-01-28 17:58 ` Rhavar
2018-01-28 18:08 ` Moral Agent
2018-01-23 21:31 ` Gregory Maxwell
2018-01-24 7:28 ` Peter Todd
2018-01-23 23:31 Adam Ficsor
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='tSFdDDXQYpeVlmLo43wABP1gQfqSflgWxl5xKnVErxHDet9hzqFNI2MXU4BWbi-iGK2gIjENeqHxu_9ni0g_BJZX9trx7o_1T_0AV62Ph90=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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