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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D653FC64
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jan 2018 20:00:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com
[62.13.148.113])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 954A8271
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jan 2018 20:00:28 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0MK0Q7u061526;
Mon, 22 Jan 2018 20:00:26 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w0MK0Ovh073219
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Mon, 22 Jan 2018 20:00:25 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 2D71C400F7;
Mon, 22 Jan 2018 20:00:24 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 5D9C8209B1; Mon, 22 Jan 2018 15:00:23 -0500 (EST)
Date: Mon, 22 Jan 2018 15:00:23 -0500
From: Peter Todd <pete@petertodd.org>
To: Rhavar <rhavar@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180122200023.GA1055@savin.petertodd.org>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: e334c842-ffae-11e7-8106-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAAUElQaAgsB Am4bWVReUF17W2Y7 bghPaBtcak9QXgdq
T0pMXVMcUwUVehx+ QEYeVRpwdgwIcHZz Zwg3XXNfD0x+d1sr
FB8BCGwHMGB9YGEf Vl1YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z
GA41ejw8IwAXFD5c RBoEJk4TRkBDOzMm SBEEEn1vF0wdHn9u
ZwYrLlcMFVoQNUNz WQAA
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
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 20:10:59 +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 20:00:29 -0000
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
> So my half-baked idea is very simple:
>=20
> Allow users to merge multiple unconfirmed transactions, stripping extrane=
ous inputs and change as they go.
>=20
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum pai=
d by the original transactions."
>=20
> Because the size of the merged transaction is smaller than the original t=
ransactions, unless there is a considerable feerate bump, this rule isn't p=
ossible to observe.
>=20
> I my question is: is it possible or reasonable to relax this rule? If thi=
s rule was removed in its entirety, does it introduce any DoS vectors? Or c=
an 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 bi=
tcoin, and have promised to pay him immediately: Instead of creating a whol=
e new transaction if I have an in-flight (unconfirmed) transaction, I can f=
ollow the rules of bip125 to create a replacement that accomplishes this go=
al.
>=20
> 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 wit=
hout difficulty.
>=20
> 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
>=20
> 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 imme=
diately be made that source the change, and provide safety in a reorg.
>=20
> 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, bec=
ause
it's rare for the inputs to exactly math the requested payment.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJaZkLRAAoJECSBQD2l8JH7f84IAIHgCCqvqQabIi/h1uxTBUuV
ucazL47BXF9PfPCCyM6ukX34Kw1Qkww9qsEFfHWk6sIQ1usF6nAUujHKbuYlpjoy
R/AHwgFcbUymC+MaEPd3N9Bl8MpDmOzD0eS0BCdZauQ4X86wUat0A2+VLNkukp28
00TG+S542Q/Gup+i+awU30XQELaHsMhEY+cKCcuz70gRUX6b6pjHKQnzN7b93dnS
6k0dArgd8fn+Y2VRTY9UYjZJQneuGfcIEPJGVOkQW2C809jEK27JWkC5PZZg8BUw
5FzU3/oSjE26gVDfHQGQgOshkQXNjQzMZmBsDDjMbybQvdVsYP0kXtXP/v4tvpk=
=me3p
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
|
