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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id BC20EC0033;
Sun, 20 Feb 2022 16:34:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 9D08460A81;
Sun, 20 Feb 2022 16:34:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aOhDAJh2ieo0; Sun, 20 Feb 2022 16:34:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp3.osuosl.org (Postfix) with ESMTPS id C5C9C6058C;
Sun, 20 Feb 2022 16:34:48 +0000 (UTC)
Date: Sun, 20 Feb 2022 16:34:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645374886;
bh=+mzDtmn/eUPdxoBb1ZrYmfv/hMkwYPKQTObk/+UVP/k=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=LpsxxnnVwc1bMewUDnbpfZedgWmcY0xve9mAqQdQZTqjqInTv7ER/2hFJFOsOB6LM
UYWLc43piPVyxt1NuGf57RjOdu/pVgmEtDTPlA0FhSpWnTG0pbo9xBKK8s/+dvDHby
tmwni38v1jvbWFyDfVLxqjPfAEYPWW0hdlb6JJrEhUkZglFJQ5Mn0kY7JTdIKuKMae
+ntrzPAfDXMR+Aet1X2GgjV8DaIC4czMULc75A+VfKYM2S3/oEFhXBcYyhLi8XPE7I
a7wNOXWs6WvpytzN/Vn0ewcOi6nA3aKs0dJz4fBeWkb0f69F5dPUIj6UqqmxxdqTUD
/Fpf1Qm+oQ+NA==
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <erAXod9aNdpQ3eMQQsfHwcaCe0S0rGU1Z9VnDy2yxlywBaSdaMJOEZ0XnGbIMSjRm9e3M4rJCwQuIgoNzrvw57e3jYxvi1cZPTeFYCjZ9vU=@protonmail.com>
In-Reply-To: <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
<YgS3sJvg6kG3WnVJ@petertodd.org>
<CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
<YhAwr7+9mGJAe2/p@petertodd.org>
<CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
<YhC6yjoe3bAfBS+W@petertodd.org>
<kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com>
<590cf52920040c9cf7517b219624bbb5@willtech.com.au>
<W70OBHZ0-DtXNdUQfA6YOmC3BVrl0zSo-xl8IQRIRSkKh7xnEV3QQwOYrgSQ8L1HvWML_bPEXB23tad6ta4lnb3caVR4rPu0mjCmVMRD264=@protonmail.com>
<CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sun, 20 Feb 2022 16:34:49 -0000
Good morning Jeremy,
> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit k=
ey required means you have to pre-plan.... suppose you're building a vault =
meant to distribute funds over many years, do you really want a *specific* =
precommitted=C2=A0key you have to maintain? What happens to your ability to=
bump should it be compromised (which may be more likely if it's intended t=
o be a hot-wallet function for bumping).
>
> Furthermore, it's quite often the case that someone might do a transactio=
n that pays you that is low fee that you want to bump but they choose to op=
t-out... then what? It's better that you should always be able to fee bump.
Good point.
For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves =
relative locktimes, of course.
Once could point out as well that Peter Todd gave just a single example, Op=
enTimeStamps, for this, and OpenTimeStamps is not the only user of the Bitc=
oin blockchain.
So we can consider: who benefits and who suffers, and does the benefit to t=
he former outweigh the detriment of the latter?
It seems to me that the necromancing attack mostly can *only* target users =
of RBF that might want to *additionally* add outputs (or in the case of OTS=
, commitments) when RBF-ing.
For example, a large onchain-paying entity might lowball an onchain transac=
tion for a few withdrawals, then as more withdrawals come in, bump up their=
feerate and add more withdrawals to the RBF-ed transaction.
Such an entity might prefer to confirm the latest RBF-ed transaction, as if=
an earlier transaction (which does not include some other withdrawals requ=
ested later) is necromanced, they would need to make an *entire* *other* tr=
ansaction (which may be costlier!) to fulfill pending withdrawal requests.
However, to my knowledge, there is no actual entity that *currently* acts t=
his way (I do have some sketches for a wallet that can support this behavio=
r, but it gets *complicated* due to having to keep track of reorgs as well.=
.. sigh).
In particular, I expect that many users do not really make outgoing payment=
s often enough that they would actually benefit from such a wallet feature.
Instead, they will generally make one payment at a time, or plan ahead and =
pay several in a batch at once, and even if they RBF, they would just keep =
the same set of outputs and just reduce their change output.
For such low-scale users, a rando third-party necromancing their old transa=
ctions could only make them happy, thus this nuisance attack cannot be exec=
uted.
We could also point out that this is really a nuisance attack and not an ec=
onomic-theft attack.
The attacker cannot gain, and can only pay in order to impose costs on some=
body else.
Rationally, the only winning move is not to play.
So --- has anyone actually implemented a Bitcoin wallet that has such a fea=
ture (i.e. make a lowball send transaction now, then you can add another se=
nd later and if the previous send transaction is unconfirmed, RBF it with a=
new transaction that has the previous send and the current send) and if so=
, can you open-source the code and show me?
Regards,
ZmnSCPxj
|
