summaryrefslogtreecommitdiff
path: root/19/b486ba815b92ac08c715b5675f3dbe5bdcbce5
blob: 015b3d18ed5295653054c9a688bbebc548996f29 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
Return-Path: <thealanevans@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 13A34E9B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 18:16:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com
	[74.125.82.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44DB6203
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 18:16:15 +0000 (UTC)
Received: by mail-ot0-f178.google.com with SMTP id d7so4975431oti.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jan 2018 10:16:15 -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=lZvaYMqHYSaxdI8P3X2ezFCY2FCi8ePJqNOppOmmJ8g=;
	b=fRpfnvrSs/EU2QK/NB9BVBCd3wxIsp4Uq/PTH0za+AEQ4RMSyhpONZKeTuOfZT6TG8
	hE6jEAao3zmT+ha/w5qzLlitccO82V1jfv9MuE5rVzrFwM9d6FB7Tf/vg5QzcWKNNTEi
	Tu8AGsI8E/L1yCffRB2YupXWyJpFvC9xw2REVLOOeKGoR7xbgDhqdibfXZ5hciVEIP0Z
	dp8nuOZ/QECRQuIC54Zh3y98AomPad6ENCrQi+5zkKBEMa0sSS37V4rNCL/MuYZWS009
	89M0OQCm7vydej1qnLTWhBcgwzQ3Q6j4a7CfdttQbaCBcV3+SsI6H3nZc/rsqDtGvs1M
	FRdw==
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=lZvaYMqHYSaxdI8P3X2ezFCY2FCi8ePJqNOppOmmJ8g=;
	b=F4Rv/WDT3mGbBVPQzWhe0zKi5LWfNxn8Z6y0Kc5rcdhq/e2Ws/0xouUzhD/jNePj6n
	UJXKjVZXRNjoE5i0abc9lTkJgiZvkqHuewBaNLwhxQrYEVrH+YJ+cB/jktkwICtFcH+K
	UaFJt0uYvq8+6SGX3TGIz0UKP8nCJTrVM9AahlPAOEw7Cwg9DCnVaPtaMCgL9U68tT7b
	mOTNbFzsOxFqDJgwhR+GyRvLJ8uOqR3kxtNibfEJXA2f/87OZXndgS+Sc4LP9e15yUeI
	K9rMfAeN0AqP7rX1L0Zw0NB1kuIXNmedRtJsrO8DbBMXjV2mFqCQmivYnu3CQ8ILCnl8
	dUPA==
X-Gm-Message-State: AKwxytdr5QiVgODbJBZ3o0BBNAveJzItmqLks6ea1tCM7zJINuseQWL/
	UJeqCtncS+34YeRgHHIVnDE+xLItOKyDuYxe5Qs=
X-Google-Smtp-Source: AH8x224m9C92/foVeXg3mgd0P7gvCk5x0Rkd67GwIP8BUcdWIa58kdYAawRM4LdfUPbiTJ/Bk6HMgoCNkqFD3e77AuM=
X-Received: by 10.157.28.158 with SMTP id l30mr5095931ota.95.1516644974505;
	Mon, 22 Jan 2018 10:16:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.140.104 with HTTP; Mon, 22 Jan 2018 10:16:13 -0800 (PST)
In-Reply-To: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
From: Alan Evans <thealanevans@gmail.com>
Date: Mon, 22 Jan 2018 14:16:13 -0400
Message-ID: <CALPhJazXpUAsd9qeHPZdwK6eeoEfsM7i3FouMifkKNv9YFzQ9w@mail.gmail.com>
To: Rhavar <rhavar@protonmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f4030435adccf4b3b50563616c1e"
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:31:31 +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:16:16 -0000

--f4030435adccf4b3b50563616c1e
Content-Type: text/plain; charset="UTF-8"

> 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
>
>

--f4030435adccf4b3b50563616c1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">So now I still =
owe John 1 BTC, however it&#39;s not immediately clear if=C2=A0</span><span=
 style=3D"font-size:12.8px">it&#39;s safe to send to him</span><div style=
=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px">If you spen=
t 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.</div></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">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.linuxfounda=
tion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>So =
my half-baked idea is very simple:<br></div><div><br></div><div>Allow users=
 to merge multiple unconfirmed transactions, stripping extraneous inputs an=
d change as they go.<br></div><div><br></div><div>This is currently not pos=
sible because of the bip125 rule:<br></div><div>&quot;The replacement trans=
action pays an absolute fee of at least the sum paid by the original transa=
ctions.&quot;<br></div><div><br></div><div>Because the size of the merged t=
ransaction is smaller than the original transactions, unless there is a con=
siderable feerate bump, this rule isn&#39;t possible to observe.<br></div><=
div><br></div><div><br></div><div>I my question is: is it possible or reaso=
nable 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?=C2=
=A0<br></div><div><br></div><div><br></div><div>---<br></div><div>Full back=
story: 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 promised to pay him immediately: Instead of creating a w=
hole new transaction if I have an in-flight (unconfirmed) transaction, I ca=
n follow the rules of bip125 to create a replacement that accomplishes this=
 goal.<br></div><div><br></div><div>From a &quot;coin selection&quot; point=
 of view, this was significantly easier than<br></div><div>I had anticipate=
d. I was able to encode the rules in my linear model and<br></div><div>feed=
 in all my unspent and in-flight transactions and it can solve it without d=
ifficulty.<br></div><div><br></div><div>However, the real problem is tracki=
ng the mess. Consider this sequence of events:<br></div><div>1) I have unco=
nfirmed transaction A<br></div><div>2) I replace it with B, which pays John=
 1 BTC<br></div><div>3) Transaction A gets confirmed<br></div><div><br></di=
v><div>So now I still owe John 1 BTC, however it&#39;s not immediately clea=
r if<br></div><div>it&#39;s safe to send to him without waiting $n transact=
ions. However even<br></div><div>for a small $n, this breaks my promise to =
pay him immediately.<br></div><div><br></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 made t=
hat source the change, and provide safety in a reorg.<br></div><div><br></d=
iv><div>However, this will only work &lt;50% of the time for me (most trans=
actions<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 y=
ou can do to make it work in a few more cases, but nothing that is realisti=
c 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 transac=
tions, it would be easy get into production, and potentially offer some pre=
tty nice savings for everyone.<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>

--f4030435adccf4b3b50563616c1e--