path: root/36/df786a95a99d3e8982c7822a695da75ee64fa8

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 B4B6DF8A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 Jan 2018 21:56:42 +0000 (UTC)
Received: by mail-oi0-f46.google.com with SMTP id m65so1456981oig.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
	<20180122200023.GA1055@savin.petertodd.org>
	<7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Tue, 23 Jan 2018 16:56:41 -0500
Message-ID: <CACiOHGw=XUe6Fxmh8JkNPZWK1d3hWaaVPsNy1dPNoU1qULckrA@mail.gmail.com>
To: Rhavar <rhavar@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <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:
>
>    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

<div dir=3D"ltr"><div>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.</div><div><br></div><div>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:<br></div><div=
><br></div><div>(Fee_A + Fee_B) / (Weight_A + Weight_B) &lt; Fee_C / Weight=
_C</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <span dir=3D"ltr">&lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><div>Getting back on topic:<br></div><span class=
=3D""><div>=C2=A0<br></div><blockquote type=3D"cite" class=3D"m_-4369415664=
037851525protonmail_quote"><div><div>It would definitely introduce DoS vect=
ors by making it much cheaper to use<br></div><div>relay bandwidth.<br></di=
v></div></blockquote><div><div><br></div></div></span><div>I think I&#39;m =
missing something, as I don&#39;t really understand this DoS vector. Relay =
bandwidth is already very cheap and easy to use by repeatedly fee bumping. =
And it&#39;s not obvious to me that requiring an absolute higher fee actual=
ly makes such an attack more expensive.<br></div><div><div><br></div></div>=
<div>I can see that my &quot;proposed&quot; change would make it cheaper to=
 evict low-fee transactions from other node&#39;s mempool. Maybe I&#39;m be=
ing naive, but I don&#39;t really see why this would be such a big deal.<br=
></div><div><div><br></div></div><div>But what about a compromise, and requ=
ire that the absolute fee must be &gt;=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 &quot;retroactive transaction merging&quot; without much=
 downside.<br></div><div><br></div><div>And really the great thing about=C2=
=A0&quot;retroactive transaction merging&quot; is just how easy it is to im=
plement. In fact, right now it&#39;s quite possible to do -- but because of=
 the &quot;higher absolute fee&quot; rule the benefits are pretty muted (al=
though if you can compress 2 change into 1, that&#39;s still likely worthwh=
ile)<br></div><div><div><br></div></div><div><div><br></div></div><div><br>=
</div></div><span class=3D""><div class=3D"m_-4369415664037851525protonmail=
_signature_block"><div class=3D"m_-4369415664037851525protonmail_signature_=
block-user"><div>-Ryan<br></div></div><div class=3D"m_-4369415664037851525p=
rotonmail_signature_block-proton m_-4369415664037851525protonmail_signature=
_block-empty"><br></div></div><div><br></div><div>-------- Original Message=
 --------<br></div><div>On January 22, 2018 3:00 PM, Peter Todd &lt;<a href=
=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;=
 wrote:<br></div><div><br></div></span><blockquote type=3D"cite" class=3D"m=
_-4369415664037851525protonmail_quote"><span class=3D""><div>On Mon, Jan 22=
, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:<br></div><blockqu=
ote><div>So my half-baked idea is very simple:<br></div><div>Allow users to=
 merge multiple unconfirmed transactions, stripping extraneous inputs and c=
hange as they go.<br></div><div><div>This is currently not possible because=
 of the bip125 rule:<br></div><div>&quot;The replacement transaction pays a=
n absolute fee of at least the sum paid by the original transactions.&quot;=
<br></div></div><div>Because the 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>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?<br></div></blockquote><div><div>=C2=A0<br></div><div>It =
would definitely introduce DoS vectors by making it much cheaper to use<br>=
</div><div>relay bandwidth. You&#39;d also be able to push others&#39; txs =
out of the mempool.<br></div><div>=C2=A0<br></div></div></span><blockquote>=
<div><hr><br></div><span class=3D""><div>Full backstory: I have been trying=
 to use bip125 (Opt-in Full Replace-by-Fee) to do &quot;transaction merging=
&quot; on the fly. Let&#39;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.<br></div><div><div=
From a &quot;coin selection&quot; point of view, this was significantly ea=
sier than<br></div><div>I had anticipated. I was able to encode the rules i=
n my linear model and<br></div><div>feed in all my unspent and in-flight tr=
ansactions and it can solve it without difficulty.<br></div></div><div>Howe=
ver, the real problem is tracking the mess. Consider this sequence of event=
s:<br></div></span><ol><span class=3D""><li>I have unconfirmed transaction =
A<br></li></span><span class=3D""><li>I replace it with B, which pays John =
1 BTC<br></li></span><li>Transaction A gets confirmed<br></li></ol><span cl=
ass=3D""><div><div>So now I still owe John 1 BTC, however it&#39;s not imme=
diately 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 breaks my=
 promise to pay him immediately.<br></div></div><div>One possible solution =
is to only consider a transaction &quot;replaceable&quot; 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.<br></div><div><div=
>However, this will only work &lt;50% of the time for me (most transactions=
<br></div><div>don&#39;t have change) and opens a pandora&#39;s box of comp=
lexity.<br></div></div></span></blockquote><span class=3D""><h2><div>=C2=A0=
<br></div><div>Most transactions don&#39;t have change?! Under what circums=
tance? For most<br></div><div>use-cases the reverse is true: almost all all=
 transactions have change, because<br></div><div>it&#39;s rare for the inpu=
ts to exactly math the requested payment.<br></div><div>=C2=A0<br></div></h=
2></span><span class=3D""><div><a href=3D"https://petertodd.org" target=3D"=
_blank">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://pe=
tertodd.org" target=3D"_blank">petertodd.org</a><br></div></span></blockquo=
te><div><br></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>

--94eb2c13039039394f0563789fdd--