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
|
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C81C4258
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Jul 2017 04:17:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
[209.85.223.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19ABACE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Jul 2017 04:17:10 +0000 (UTC)
Received: by mail-io0-f169.google.com with SMTP id r36so49883763ioi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 02 Jul 2017 21:17:09 -0700 (PDT)
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
:cc; bh=qDnpguaer7ecH9RErxsppP6JRUC0L3mY+6QrlYK0NJk=;
b=T79I5+dTJSkg3B3k3aIdbzlWhKHTtgmL+DVRg326ptqA7XIcTG0gvKgIoRS6K+yMMh
i+hfIqxvDWqg7oPqkXfjO+K501BcRcnyBNOFjuHY5LN7F2TmO2AO4A6HFxpHhTvRGdF5
VwEabYTVXyQL2s//Br7LdZKkAUdBNh/7gWyhTbz7MZ3rNm+BJ1GsjRXEeAUOMgVG1q14
/Jf3+jkOBCd27tlBDp2lN7XgsZzpYDJvKpXeyGmMOyUHfL4ZuHCKNMcxktGgxtyKBsyM
WDxlFm0fkLJE3PIZ8+p2g2EuPNwHGWgS1Bjf/cyNyECcgPZZ6yJiXd70ZJ3nCA4g9iG/
4bmA==
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:cc;
bh=qDnpguaer7ecH9RErxsppP6JRUC0L3mY+6QrlYK0NJk=;
b=lNABRs7IQKrj2UYE2LZY6Pmci57LV+uPS209Lpjii24vypJoKl18X0K7h0pkx5ZWzp
giSzcTyuTe5sIb2ooXYCI6U/og1FRdLenPvMyHN57fxG8PdTVY7yJcN/ky8M0+mGoCEE
nPZlATD16gu47V7y8EwE4ymcSP/4xJWO/FVd37Nyh29M02IQ0EXP27KUHe+Au70nZGJG
RyVUdiBxGjtfVuaOVAy+XTQe+kMvdCWXQrFgQMXZ9e/Fc9mtNqqoc4WUZIxoCSil7ITv
Fo1qlaJlCVhKDgnm+06bzucwzW288qMV0IiN21lJ294sH+hEPQSTnuCHAfNDqTHv3Hrp
yKTw==
X-Gm-Message-State: AKS2vOwfAOSmDp0V4IJuZWMIWpAWfyi4RBvdzbwGQItb9wq2iduYFIv8
3hxrRl/2Stu0TH3LnyRHWlCEkceSqA==
X-Received: by 10.202.4.73 with SMTP id 70mr16824449oie.105.1499055429417;
Sun, 02 Jul 2017 21:17:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.74.165 with HTTP; Sun, 2 Jul 2017 21:17:08 -0700 (PDT)
In-Reply-To: <g7lk-YxVIztIZUQxt6-I3FCQoagNsr7Ol787gAnQD-ZGc_Py_v42lmOzeIdgb447960GqhtezPOVHYefjkn88w0Myw-bYXgiU_CooQ4rX-w=@protonmail.com>
References: <uupN1N30M_M_-fb7bBfHgn2XnpTpRNWCP3BpFiHXDHQiWqUf4u3POgd58tpDZS5fQjSst59JaxFdIRb7qt9Hb8V9QHHKqe0YBAW0XnRBqiw=@protonmail.com>
<CAAS2fgQGDFOm+vmPuJJU2=hpdZE6KC5WPzY6utvFk_g5wPQ58g@mail.gmail.com>
<i0RP2rjFVA8h3PMYT7lbELniTxCKKpcjayO9cRygp2qVyURqIbGPMXvJ1RVjgsJIRU9HcE4-ud2Vt5d8qYWGKfDxE1jeFtbRMSim5Mis-6c=@protonmail.com>
<CAAS2fgTwYJ+paz5k8HP5Y0jz3_9a9sjApyUsYpZEmrYea5VhpQ@mail.gmail.com>
<g7lk-YxVIztIZUQxt6-I3FCQoagNsr7Ol787gAnQD-ZGc_Py_v42lmOzeIdgb447960GqhtezPOVHYefjkn88w0Myw-bYXgiU_CooQ4rX-w=@protonmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Sun, 2 Jul 2017 23:17:08 -0500
Message-ID: <CADvTj4oWV9iWi1OvnopucgF-Jwbr=ssEeH8FHsFQfSRb+zD6DQ@mail.gmail.com>
To: Rhavar <rhavar@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
transactions
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, 03 Jul 2017 04:17:13 -0000
This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement. Basically you allow the fee bumped replacement
to evict the sweep transaction+parent if there is more than 1MB of
transactions(or whatever the block size/weight limit is) of
transactions between the sweep transaction+parent feerate and bumped
fee replacement feerate. This way the sweep transaction parent only
gets replaced if it is unlikely that miners would ever produce a block
template with transactions at the sweep transaction+parent feerate at
the same time as the replacement transaction feerate. From the miners
point of view this give a higher fee block template overall since it
would be unlikely that one would see transactions with the feerate of
both the CPFP sweep and the replacement parent in the same block
template.
On Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
> It actually doesn't really matter much.
>
> Let's say I want to pay Alice and Bob (unrelated entities), so I send it to
> them (together) with a low-fee transaction of paying 50 sat/byte. After an
> hour it's obvious that it's not confirmed (maybe there was a big backlog, or
> no blocks mined), so I want to replace my small transaction with one that
> pays 70 sat/byte.
>
> But in the mean time, Alice has swept her wallet (or used a service that has
> done so) and generated 50KB of descendant transactions paying 40 sat/byte
> (i.e. total fees of 0.02 BTC or $50).
>
> According to the BIP125 rules, I would need to pay for the cost of
> invalidating all the transactions (an absolute higher amount of fee) along
> with the replay cost of the descendant transactions.
>
> So in this case, for me to fee bump the transaction I'm looking at throwing
> away $50 because of descendant transactions that were totally out of my
> control. If I don't fee bump, I violate my promise to Bob to pay in a
> timely manner (and also probably Alice, as it wasn't in her control she was
> using an exchange that did this).
>
> If I guarantee to fee bump, the amount I risk is effectively unbounded. And
> even if the descendant transactions have a higher fee rate, and are
> assisting by CPFP boosting my transaction -- it very well might not be
> enough.
>
> --
>
> The idea of this proposal comes from the problems *in practice* of trying to
> low-ball fee estimation with scheduled continuous fee bumps until it
> confirms. At the moment it's not viable, but if this proposal was adopted
> then it would be.
>
> Personally I think it's of critical piece of having a stable fee market. Fee
> estimation is a fools game, even the new and improved fee estimation in
> master today was suggesting x30 fees to what was required (and I
> successfully made transactions with). People (and especially services) being
> able to be able to dynamically increase their fees sanely when dealing with
> withdrawals (and especially batched ones) will go a long way to helping the
> overall ecosystem.
>
>
> -Ryan
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: greg@xiph.org
> To: Rhavar <rhavar@protonmail.com>
> bitcoin-dev@lists.linuxfoundation.org
> <bitcoin-dev@lists.linuxfoundation.org>
>
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar@protonmail.com> wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to
>> pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
>
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
