path: root/8c/11f153bbbfe687c8b3e435a5ce9b2ccb2b1130

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C166CF5A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 18:50:32 +0000 (UTC)
Received: by mail-oi0-f48.google.com with SMTP id t16so6662140oif.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <vdr3w_poTPTx_YFFvEdLugS0a_wbKTRx00npKupZqVNWPO0lwxIEMxMaC9xyPSGNmtuRn2behoLMq4iR0YTwDoQxR6AZds8HA-RccVr_ZPw=@protonmail.com>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
	<CALPhJazXpUAsd9qeHPZdwK6eeoEfsM7i3FouMifkKNv9YFzQ9w@mail.gmail.com>
	<vdr3w_poTPTx_YFFvEdLugS0a_wbKTRx00npKupZqVNWPO0lwxIEMxMaC9xyPSGNmtuRn2behoLMq4iR0YTwDoQxR6AZds8HA-RccVr_ZPw=@protonmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Mon, 22 Jan 2018 13:50:31 -0500
Message-ID: <CACiOHGwdy3BAgJJx1kjU8jLxmt+QZx-OBDxdHB0L2+D=ix7zYw@mail.gmail.com>
To: Rhavar <rhavar@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <thealanevans@gmail.com> 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

<div dir=3D"ltr">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?<div><br></div><div>Perhaps they could =
even replace old tx with economically equivalent summary transactions?<br><=
/div><div><br></div><div>The mempool seems like nature&#39;s accumulator fo=
r pre-mining compression opportunities.<br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Mon, Jan 22, 2018 at 1:18 PM, Rhav=
ar via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
"><div>&gt;=C2=A0If you spent your change from transaction A, that would be=
 safe. There&#39;d be no way you John could end up with 2 BTC from you then=
.<br></div><div><br></div></span><div>Yes, that&#39;s what the following pa=
ragraph says -- along with it&#39;s limitations =3D)<br></div><div><br></di=
v><div class=3D"m_-4228913475869382548protonmail_signature_block"><div clas=
s=3D"m_-4228913475869382548protonmail_signature_block-user"><div>-Ryan<br><=
/div></div><div class=3D"m_-4228913475869382548protonmail_signature_block-p=
roton m_-4228913475869382548protonmail_signature_block-empty"><br></div></d=
iv><div><br></div><div>-------- Original Message --------<br></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5"><div> On January 22, 2018 1:16 PM, Alan Eva=
ns &lt;<a href=3D"mailto:thealanevans@gmail.com" target=3D"_blank">thealane=
vans@gmail.com</a>&gt; wrote:<br></div><div> <br></div><blockquote class=3D=
"m_-4228913475869382548protonmail_quote" type=3D"cite"><div dir=3D"ltr"><di=
v>&gt;=C2=A0<span class=3D"m_-4228913475869382548size" style=3D"font-size:1=
2.8px">So now I still owe John 1 BTC, however it&#39;s not immediately clea=
r if=C2=A0</span><span class=3D"m_-4228913475869382548size" style=3D"font-s=
ize:12.8px">it&#39;s safe to send to him</span><br></div><div style=3D"font=
-size:12.8px"><br></div><div style=3D"font-size:12.8px">If you spent your c=
hange from transaction A, that would be safe. There&#39;d be no way you Joh=
n could end up with 2 BTC from you then.<br></div></div><div class=3D"gmail=
_extra"><div><br></div><div class=3D"gmail_quote"><div>On Mon, Jan 22, 2018=
 at 1:40 PM, Rhavar via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br></div><blockquote style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class=3D=
"gmail_quote"><div>So my half-baked idea is very simple:<br></div><div><br>=
</div><div>Allow users to merge multiple unconfirmed transactions, strippin=
g extraneous inputs and change as they go.<br></div><div><br></div><div>Thi=
s is currently not possible because of the bip125 rule:<br></div><div>&quot=
;The replacement transaction pays an absolute fee of at least the sum paid =
by the original transactions.&quot;<br></div><div><br></div><div>Because th=
e size of the merged transaction is smaller than the original transactions,=
 unless there is a considerable feerate bump, this rule isn&#39;t possible =
to observe.<br></div><div><br></div><div><br></div><div>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<br></div><div><br></div><div><br></div><div>---<br>=
</div><div>Full backstory: I have been trying to use bip125 (Opt-in Full Re=
place-by-Fee) to do &quot;transaction merging&quot; on the fly. Let&#39;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.<br></div><div><br></div><div>From a &quot;coin s=
election&quot; point of view, this was significantly easier than<br></div><=
div>I had anticipated. I was able to encode the rules in my linear model an=
d<br></div><div>feed in all my unspent and in-flight transactions and it ca=
n solve it without difficulty.<br></div><div><br></div><div>However, the re=
al problem is tracking the mess. Consider this sequence of events:<br></div=
><div>1) I have unconfirmed transaction A<br></div><div>2) I replace it wit=
h B, which pays John 1 BTC<br></div><div>3) Transaction A gets confirmed<br=
></div><div><br></div><div>So now I still owe John 1 BTC, however it&#39;s =
not immediately clear if<br></div><div>it&#39;s safe to send to him without=
 waiting $n transactions. However even<br></div><div>for a small $n, this b=
reaks my promise to pay him immediately.<br></div><div><br></div><div>One p=
ossible solution is to only consider a transaction &quot;replaceable&quot; =
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.<b=
r></div><div><br></div><div>However, this will only work &lt;50% of the tim=
e for me (most transactions<br></div><div>don&#39;t have change) and opens =
a pandora&#39;s box of complexity.<br></div><div><br></div><div>There&#39;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.<br></div=
><div><br></div><div>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.<br></div><div><br></div>=
<div>______________________________<wbr>_________________<br></div><div> bi=
tcoin-dev mailing list<br></div><div> <a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>io=
n.org</a><br></div><div> <a rel=3D"noreferrer" href=3D"https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists=
.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></div><d=
iv> <br></div></blockquote></div></div></blockquote><div><br></div></div></=
div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1141b6889bdfd9056361e78d--