From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B4B6DF8A for ; Tue, 23 Jan 2018 21:56:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C928627B for ; Tue, 23 Jan 2018 21:56:42 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id m65so1456981oig.5 for ; Tue, 23 Jan 2018 13:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Rw3zBeTkWmGGmUJSS0L5wmmfuKYjutWhqlUz6vo7M7E=; b=goPD75ju4nY0HIIEZcRL8fiYL0wgDwzzA5oXvcQ9ufybaeSY6Qz0IpRniAPIMg27hS tBKuHse48PDTZ7d0bnjdYmeMFEOP2rkmksf/uYWIhWvD0JcDYT3hvlnjCs76Z6MEnKAz a95A1xvDNMoNyQ8iUsiQDEU36Z45UXSRUfee757+lw99m/NgYS1HDA3aK8nMSCvQvrD9 jZuWKHzGwIWon0xjC0iTgoW7Syyg/kFDHepC/9Mnf2SEyay+g8S20F4zHMPmbycDqiqX g7YmPMw4reeAm3ZYnoY23mDBOh0g6lZj6U/ZfiBE58258ZXNZO2YbLQ/cX+Jep4uhFbC mFmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Rw3zBeTkWmGGmUJSS0L5wmmfuKYjutWhqlUz6vo7M7E=; b=NWb+8+44Uqs0gAev8aYsDUVMNf1EmLN9HdC0mP5PQdS2M9Z6sxWbfqxrcSzlCmDouF gpbX34lkhFVXqoTYzp7vqXGJ8y3fq23JCQu56vSLuvTW/YomDFWWXl5RMPldgmAg6elJ l4dsBEpwFRzoJqV+rq8VzFUxnIeuaapw9t/APBHnAbSz9Esqv8dooKAqXFD9R9C9FGgq twDQBmDFng4R1yxWjpejyeiI6+SkYw80kJVkc22MGcHCjRN1lnPp0Klg41aoPBsris6W CBxl+SPWVifm5nGiqsZtZfycz4aIINg+7MQaEPPlmYtHFjxf3z2SvgpIXaYauDpC+EM0 20tA== X-Gm-Message-State: AKwxyteXWQQKLRzroMZThchsmPp2NlgHfqtpG34k/ZcB4zm2T2CyEFyi Or0+/qTF2Ef3t9khaehjA6aY2pEOZgc7x+wbfLs= X-Google-Smtp-Source: AH8x227qfdSdVzRP5GqvnFfleqx1+FHMX35z46ub1PNrlIb25DKMUMTFIRpdLUnNlaWg990+apt5HxnBLANN2tFLyBE= X-Received: by 10.202.8.209 with SMTP id 200mr7150179oii.284.1516744602104; Tue, 23 Jan 2018 13:56:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.64.239 with HTTP; Tue, 23 Jan 2018 13:56:41 -0800 (PST) In-Reply-To: <7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com> References: <20180122200023.GA1055@savin.petertodd.org> <7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com> From: Moral Agent Date: Tue, 23 Jan 2018 16:56:41 -0500 Message-ID: To: Rhavar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c13039039394f0563789fdd" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 23 Jan 2018 21:57:21 +0000 Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 21:56:43 -0000 --94eb2c13039039394f0563789fdd Content-Type: text/plain; charset="UTF-8" Another way to limit abuse would be to have the fee *rate* be required to increase, which is kind of the spirit of RBF, applied to this situation. That is to say, if you wished to replace transactions A and B with C which spends the same inputs as A and B, then the following must be true before C will be relayed: (Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Getting back on topic: > > > It would definitely introduce DoS vectors by making it much cheaper to use > relay bandwidth. > > > I think I'm missing something, as I don't really understand this DoS > vector. Relay bandwidth is already very cheap and easy to use by repeatedly > fee bumping. And it's not obvious to me that requiring an absolute higher > fee actually makes such an attack more expensive. > > I can see that my "proposed" change would make it cheaper to evict low-fee > transactions from other node's mempool. Maybe I'm being naive, but I don't > really see why this would be such a big deal. > > But what about a compromise, and require that the absolute fee must be >= > half the original fees. I know everyone hates magic values, but I think in > practice it will allow legitimate and useful use of "retroactive > transaction merging" without much downside. > > And really the great thing about "retroactive transaction merging" is just > how easy it is to implement. In fact, right now it's quite possible to do > -- but because of the "higher absolute fee" rule the benefits are pretty > muted (although if you can compress 2 change into 1, that's still likely > worthwhile) > > > > -Ryan > > > -------- Original Message -------- > On January 22, 2018 3:00 PM, Peter Todd 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: > > 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 > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c13039039394f0563789fdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another way to limit abuse would be to have the fee *= rate* be required to increase, which is kind of the spirit of RBF, applied = to this situation.

That is to say, if you wished t= o replace transactions A and B with C which spends the same inputs as A and= B, then the following must be true before C will be relayed:

(Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight= _C

On = Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:
Getting back on topic:
=C2=A0
It would definitely introduce DoS vect= ors by making it much cheaper to use
relay bandwidth.

I think I'm = missing something, as I don't really understand this DoS vector. Relay = bandwidth is already very cheap and easy to use by repeatedly fee bumping. = And it's not obvious to me that requiring an absolute higher fee actual= ly makes such an attack more expensive.

=
I can see that my "proposed" change would make it cheaper to= evict low-fee transactions from other node's mempool. Maybe I'm be= ing naive, but I don't really see why this would be such a big deal.

But what about a compromise, and requ= ire that the absolute fee must be >=3D half the original fees. I know ev= eryone hates magic values, but I think in practice it will allow legitimate= and useful use of "retroactive transaction merging" without much= downside.

And really the great thing about=C2= =A0"retroactive transaction merging" is just how easy it is to im= plement. In fact, right now it's quite possible to do -- but because of= the "higher absolute fee" rule the benefits are pretty muted (al= though if you can compress 2 change into 1, that's still likely worthwh= ile)



=
-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 c= hange as they go.
This is currently not possible because= of the bip125 rule:
"The replacement transaction pays a= n 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 i= n its entirety, does it introduce any DoS vectors? Or can it be changed to = allow my use-case?
=C2=A0
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.
=C2=A0
=

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 promis= ed 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 bip= 125 to create a replacement that accomplishes this goal.
From a "coin selection" point of view, this was significantly ea= sier than
I had anticipated. I was able to encode the rules i= n my linear model and
feed in all my unspent and in-flight tr= ansactions and it can solve it without difficulty.
Howe= ver, the real problem is tracking the mess. Consider this sequence of event= s:
  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 imme= diately 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 mad= e 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 comp= lexity.

=C2=A0=
Most transactions don't have change?! Under what circums= tance? For most
use-cases the reverse is true: almost all all= transactions have change, because
it's rare for the inpu= ts to exactly math the requested payment.
=C2=A0


_______________________________________________<= br> bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--94eb2c13039039394f0563789fdd--