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: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EB98C09
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 16:05:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 07BFE37C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 16:05:11 +0000 (UTC)
Date: Wed, 24 Jan 2018 11:05:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1516809904;
bh=YAYiy+dyeSvB3Nm7/skRmQ8EAsU6x8XnYQm6YbrWZkA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=h1aI+VrBF7mu1MXPnR+7OfthCg55Cg0GAB/BhznAEhCIfYEb9NNMqdLUxWMQ28+8x
Nl+Gh8uipJQ1eEA5UTE66Pzwl7j8kOqVkMFg3v6UM96hRBBiA6Ljc7yA+A2/Ak7COb
zxJDBfEumfSe+q0sgSJLXAur1WMUDJocfCFrKqzs=
To: Alan Evans <thealanevans@gmail.com>
From: Rhavar <rhavar@protonmail.com>
Reply-To: Rhavar <rhavar@protonmail.com>
Message-ID: <PdUSy7mO1QTH-sAU_gBRjZOhLi1FoZRPUhNZt80kPL8d0lOgsCfMeNzf52Ae7_wrcTBy7d-tROvRLqBuHMMtmduzAskGuzPlwxI2yG4yY64=@protonmail.com>
In-Reply-To: <CALPhJayjSopa6qPDAo=8-FVCz5+SjXneGMmoYF2Yi2p3FrCb0g@mail.gmail.com>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
<20180122200023.GA1055@savin.petertodd.org>
<7yyS0mCgC8UWMYR_Jf1hB_GkkGj6Iu8tnIO7TeXWWyCrg9j4RZ7ziprCPZcv2xsFZdUzcFuHyeMU2-RBujzlSXdUAWlqdricuL2abaX0PWE=@protonmail.com>
<CACiOHGw=XUe6Fxmh8JkNPZWK1d3hWaaVPsNy1dPNoU1qULckrA@mail.gmail.com>
<oY5fxEk2FEJwHTtN9hKit2Unfu9C6CpSKLOVr0Tu99W_ctym_TNtEPLjgSg77e_RePgWHLBF7sNZoXa11aDgm6ClDxT33Jz2M-q3HZC1n40=@protonmail.com>
<CAAS2fgQBMSOhDBUZ6d9cG7fHg4tRr8o+E0j3ZXhdHkxv4kTwUA@mail.gmail.com>
<20180124074453.GC12767@savin.petertodd.org>
<CALPhJayjSopa6qPDAo=8-FVCz5+SjXneGMmoYF2Yi2p3FrCb0g@mail.gmail.com>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: Thu, 25 Jan 2018 21:02:35 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 24 Jan 2018 16:05:13 -0000
>I'm confused, the mempool=C2=A0only sees 1 transaction at a time, first A,=
then later B. "the original transactions", plural, should not exist in the=
mempool.
>
>B's fee and rate needs to be larger than A's, but B will be greater than o=
r equal to A anyway. So, just increasing the fee rate will cause a larger f=
ee anyway.
>
>Am I missing something?
Kind of. The first case is that you do the "smarter" type of merging, where=
you get an original transaction and then say add an additional output(s) t=
o it.
The issue with this, is from a practical perspective is _very_ complex. Bec=
ause you really need to do a lot of tracking to see which of the two transa=
ctions actually confirm. And if you are promising fast payments, you can be=
stuck in a weird limbo state where you're waiting for the original one to =
"safely" confirm before it's safe to make a re-payment (even a non-maliciou=
s will likely contain the replacement).
bip125 already supports this use-case, but I will suggest that the logic to=
deploy this is sufficiently complex that no one is going to attempt any ti=
me in the near future.
But "retroactive transaction merging" is actually pretty approachable probl=
em for a service to implement. You just get N valid transactions you've mad=
e, merge them into one. Strip extraneous inputs[1], and combine and alter t=
he change amount.
The reason this is so appealing to implement, is there is very little compl=
exity. If the "retroactive transaction merge" fails, or doesn't get confirm=
ed, it actually has no impact. If it does get confirmed, that's just pure c=
ost-savings.
However, the rules of bip125 currently make it (unnecessarily?) unappealing=
, because I can never lower the absolute amount of fees I pay. Hence I thin=
k it'd be pretty sweet if they could be relaxed to support this if it can b=
e done in a pretty risk free way.
[1] Need to be very careful with that, if you're ever merging a merged tran=
saction.
>
>
>On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>>On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev=
wrote:
>> > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > > Interesting. I didn't think about this before, but it seems like bip=
125 is
>> > > rather incentive incompatible right now? If we're assuming a competi=
tive
>> > > mempool, it really doesn't seem generally rational to accept a repla=
cement
>> > > transaction of a lower fee rate.
>> >
>> > BIP125 replacement requires that the fee rate increases.=C2=A0 The tex=
t of
>> > the BIP document is written in a confusing way that doesn't make this
>> > clear.
>>
>>In fact I considered only requiring an increase in fee rate, based on the
>> theory that if absolute fee went down, the transaction must be smaller a=
nd thus
>> miners could overall earn more from the additional transactions they cou=
ld fit
>> into their block. But to do that properly requires considering whether o=
r not
>> that's actually true in the particular state the mempool as a whole happ=
ens to
>> be in, so I ditched that idea early on for the much simpler criteria of =
both a
>> feerate and absolute fee increase.
>>
>> --
>>https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>>_______________________________________________
>> bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
|
