Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C166CF5A for ; Mon, 22 Jan 2018 18:50:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1BA6271 for ; Mon, 22 Jan 2018 18:50:32 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id t16so6662140oif.10 for ; Mon, 22 Jan 2018 10:50:32 -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=US2P85x5piRa4yvrspTGZi3bWTSOSAZ9Nv9433kcC3o=; b=LBVtVuO6iBgO0Wm1XBeHMwUEZx9lLvsHqT+xHV9ZM61k3Aas+7hMJ+KeKRoZMx0DzH osnHm4LEVwXc01ec6ohwlXa07lBlucz9f8rYMyI8EpuyUUH7XTkPq7yaJrIIpHLhaPJr 6lw9i7xW56FRw58k1d4zGTVzFa95BukvO3e+VMAbs9BKoksjoGjeCRmHe/niqwXaNCeE J3ZA2A7YjOpZaB7w9714IvbuC1pBWGaFlcrScmVva29GO9u241qOg+VaP/yt5rKRcd1m oTWLpVOhTGDpsHtT+jNbQUmom1xn1wGtBIqWkjxL/ZrcgO87s3M4fomaVs8YjuApOxqd kqsw== 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=US2P85x5piRa4yvrspTGZi3bWTSOSAZ9Nv9433kcC3o=; b=CJjRff1fgLtpdrB+atWybSkWUc7Xhi2lU3YxXpavpMDKp/mm9nsYcGS5WTuNZEXbYC j2odpTpVxg81IDmoKJR/0t069VknF98bmeu0Uph6G7ZPwSJ6tqHvL06VS6fKsBEDxP1D 7pa8g5BwmIwGphrOmfbDO9HykAZQMcCkNh1oNGFmyAh9Y/qv5dk/Dhi/dYF4sc0/yAgT uJZbkB1XGy+KgBMKa6yc2FmO9jh/Cnh99OeS6seN73gQXa2WiqXuFXqDNyoowMoxUnMq YZ6W00ambbCsG7FqvvHz7hQ/cEFF2WsCktS/4jZomvf70mr7JTG0/PA0PTFEvrB3KRyc 7PPA== X-Gm-Message-State: AKwxytd5J/qNk3O0Fo81pSD4iC641aY3xzQ/1GN/7ghVemAshn0GxjO3 ESDe0m6mLIs6WiLKobfDocbQ5hxzRAEzLIVAjBw= X-Google-Smtp-Source: AH8x2270htR2Z/RMhgW4v5Asnom8yrohxS37t0dUR+JLvsJg50X06cCX+5r3GKff2jKQvtDUTpaVMkNmfFeGdQsAIEY= X-Received: by 10.202.106.67 with SMTP id f64mr4616752oic.92.1516647032281; Mon, 22 Jan 2018 10:50:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.64.239 with HTTP; Mon, 22 Jan 2018 10:50:31 -0800 (PST) In-Reply-To: References: From: Moral Agent Date: Mon, 22 Jan 2018 13:50:31 -0500 Message-ID: To: Rhavar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1141b6889bdfd9056361e78d" 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: Mon, 22 Jan 2018 18:51:18 +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: Mon, 22 Jan 2018 18:50:33 -0000 --001a1141b6889bdfd9056361e78d Content-Type: text/plain; charset="UTF-8" Along the same lines, I wonder if unrelated people with tx that are not confirming could cooperate to merge their disparate tx into a CoinJoin tx with a higher fee rate? Perhaps they could even replace old tx with economically equivalent summary transactions? The mempool seems like nature's accumulator for pre-mining compression opportunities. On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > If you spent your change from transaction A, that would be safe. There'd > be no way you John could end up with 2 BTC from you then. > > Yes, that's what the following paragraph says -- along with it's > limitations =) > > -Ryan > > > -------- Original Message -------- > On January 22, 2018 1:16 PM, Alan Evans wrote: > > > So now I still owe John 1 BTC, however it's not immediately clear if it's > safe to send to him > > If you spent your change from transaction A, that would be safe. There'd > be no way you John could end up with 2 BTC from you then. > > On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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? >> >> >> --- >> 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. >> >> There's a few other hacks you can do to make it work in a few more cases, >> but nothing that is realistic to expect anyone to implement any time soon. >> >> However, if there was a straight foward way to merge N unconfirmed >> transactions, it would be easy get into production, and potentially offer >> some pretty nice savings for everyone. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1141b6889bdfd9056361e78d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Along the same lines, I wonder if unrelated people with tx= that are not confirming could cooperate to merge their disparate tx into a= CoinJoin tx with a higher fee rate?

Perhaps they could = even replace old tx with economically equivalent summary transactions?
<= /div>

The mempool seems like nature's accumulator fo= r pre-mining compression opportunities.

On Mon, Jan 22, 2018 at 1:18 PM, Rhav= ar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> wrote:
>=C2=A0If you spent your change from transaction A, that would be= safe. There'd be no way you John could end up with 2 BTC from you then= .

Yes, that's what the following pa= ragraph says -- along with it's limitations =3D)

-Ryan
<= /div>


-------- Original Message --------
On January 22, 2018 1:16 PM, Alan Eva= ns <thealane= vans@gmail.com> wrote:

>=C2=A0So now I still owe John 1 BTC, however it's not immediately clea= r if=C2=A0it's safe to send to him

If you spent your c= hange from transaction A, that would be safe. There'd be no way you Joh= n could end up with 2 BTC from you then.

On Mon, Jan 22, 2018= at 1:40 PM, Rhavar via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> wrote:
So my half-baked idea is very simple:

=
Allow users to merge multiple unconfirmed transactions, strippin= g extraneous inputs and change as they go.

Thi= s 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 th= e 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: i= s 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 a= llow my use-case?=C2=A0


---
=
Full backstory: I have been trying to use bip125 (Opt-in Full Re= place-by-Fee) to do "transaction merging" on the fly. Let's s= ay that I owe John 1 bitcoin, and have promised to pay him immediately: Ins= tead of creating a whole new transaction if I have an in-flight (unconfirme= d) transaction, I can follow the rules of bip125 to create a replacement th= at accomplishes this goal.

From a "coin s= election" point of view, this was significantly easier than
<= div>I had anticipated. I was able to encode the rules in my linear model an= d
feed in all my unspent and in-flight transactions and it ca= n solve it without difficulty.

However, the re= al problem is tracking the mess. Consider this sequence of events:
1) I have unconfirmed transaction A
2) I replace it wit= h 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 b= reaks my promise to pay him immediately.

One p= ossible solution is to only consider a transaction "replaceable" = if it has change, so if the original transaction confirms -- payments can i= mmediately be made that source the change, and provide safety in a reorg.

However, this will only work <50% of the tim= e for me (most transactions
don't have change) and opens = a pandora's box of complexity.

There's= a few other hacks you can do to make it work in a few more cases, but noth= ing that is realistic to expect anyone to implement any time soon.

However, if there was a straight foward way to merge N= unconfirmed transactions, it would be easy get into production, and potent= ially offer some pretty nice savings for everyone.

=
_______________________________________________
bi= tcoin-dev mailing list



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


--001a1141b6889bdfd9056361e78d--