public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Rhavar <rhavar@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
Date: Mon, 22 Jan 2018 15:00:23 -0500	[thread overview]
Message-ID: <20180122200023.GA1055@savin.petertodd.org> (raw)
In-Reply-To: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

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:
> 1) I have unconfirmed transaction A
> 2) I replace it with B, which pays John 1 BTC
> 3) 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: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2018-01-22 20:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 17:40 [bitcoin-dev] Transaction Merging (bip125 relaxation) 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 [this message]
2018-01-22 20:09   ` Rhavar
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=20180122200023.GA1055@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rhavar@protonmail.com \
    /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