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
|
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 8E711EA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Feb 2018 02:07:37 +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 45D40180
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Feb 2018 02:07:36 +0000 (UTC)
Date: Tue, 13 Feb 2018 21:07:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1518574052;
bh=faPS8AzNOekOiwQ3IaTJrkkL+Xc5wE1DgaE/J7sLMbw=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=yilWM4N9kzLG7I2xHb1bS7KB3Cv6MRpo6Gz2Kew+mD/44eh0nIQ2xmCafoYunYE0x
k0cN+noh4YQawQtap/QMe63rumm01sGGeGlkVIz0iptS1KVn02nMNK16enRCrqLVlL
EZ8i2lBcbWt6sEerGb/B/k1+DaQpoB0rqMREKYmI=
To: Peter Todd <pete@petertodd.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <IoXsS2vxicFBvVPa_4p0ERi684PMJySPwFt82NRUTzcFJ1xzTEBsuDYkDN3GIc6GDKqLTfcWtw_bn8JvCxQKPsh9nZII65536x2XL9nzC_8=@protonmail.com>
In-Reply-To: <20180213184034.GA10642@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
<20180213184034.GA10642@fedora-23-dvm>
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: Wed, 14 Feb 2018 02:35:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
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, 14 Feb 2018 02:07:37 -0000
On February 13, 2018 1:40 PM, Peter Todd <pete@petertodd.org> wrote:
> Yeah, sorry, I just misread what scenario you guys were talking about. II=
RC the
> term "pinned" may have even been invented by myself, as IIRC I noticed th=
e
> issue when the RBF patch was being developed years ago. I don't think I h=
ad a
> solution at the time so I just punted on it.
Yeah. I posted that before it was clarified, it's just my message got held =
up in the moderation queue so it came out of order at an inconvenient time =
><
> I'm not sure that's actually true, as you're only creating transactions s=
ets
> that are reorg safe. Though I don't have a detailed design in mind so I m=
ay be
> missing something.
It is. T_a and T_ab are "reorg" safe, but if T_a confirms you will still ne=
ed to pay Bob in way. But you need to pay him such that in a reorg occurs a=
nd suddenly T_ab is mined, you haven't doubled paid him.=20
I've been working on it's implementation, but it's honestly really complex =
and hard to test. I outlined the procedure here: https://gist.github.com/RH=
avar/cff76a026ece8446c898470db4f35682 which I call "Super Withdrawals".
My point though isn't that it's impossible, it's that it's sufficiently com=
plex that it's unreasonable to expect anyone to be doing it any time soon. =
By relaxing any unnecessary restrictions on bip125, just makes it _drastica=
lly_ easier to do certain things.
> So here's a question: how many wallets have actually implemented CPFP fee=
bumps
> for incoming transactions?
Never tried it, but I recall seeing it in the electrum gui. I originally tr=
ied supporting this myself, but it's kind of annoying. It's generally a bi=
t cost-prohibitive to create a transaction specifically for the purpose of =
a CPFP fee bump, but since I made transactions pretty frequently (averaged =
say every 8 minutes) it doesn't add an additional input for the purpose of =
bumping selected incoming transactions.
The work flow is reasonably smooth: Alice has sent me 1 BTC with low fees, =
I owe Bob some money. I source Alice's output in the payment to Bob, giving=
her transaction a fee bump. Both transactions confirm, everyone is happy.
However during the whole time I need to watch Alice's transaction because i=
f it ever is replaced/conflicted, I need to immediately pay Bob (in a reorg=
safe way, so I don't double-pay). It's not terribly hard to do, by making =
sure when I pay Bob I use an additional input that I also use for any "repa=
yment" but it's enough complexity and hard enough to test that I gave up.
The really nice thing of most current send systems (and now especially so w=
ith segwit) is everything is pretty much fire and forget. (although I just=
schedule in 0.5, 1, 2, 4, .... 32 hours fee bump attempts. But that's just=
background that can fail/succeed blindly)
>
>1. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/01468=
8.html
>
> --
>https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
|
