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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 74835C0035
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Feb 2022 02:39:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 617FB408FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Feb 2022 02:39:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 99YdYOE-FfmF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Feb 2022 02:39:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by smtp4.osuosl.org (Postfix) with ESMTPS id 68901408FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Feb 2022 02:39:58 +0000 (UTC)
Date: Sun, 20 Feb 2022 02:39:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1645324795;
bh=EtW9S6uDxVo/ugRrYtgZm5qgPalVGC5Bue4jEcetKGg=;
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=HGnlg/l8vfFIOck06xlZNRH8RdOuwoC704r8sMH1vHDAvPTWNaI0m4Zr6w4uo0cr6
ABq48KCS6PeJMYRzwR2sS6dIQhe8VStqAXKyJ69HwShXTyxrXeRVriYkze+uq5FfNT
O1/0iBJ/ryuBwKiy5x7Fqgm6N2cjpVKfjRRMkFOUIr501ZdZ0oWh/Qmblb3qhzYRok
hq/cGFLWVmZyto8O29+wdbDX97uRJV1YHDhRWY6ME2rz+tTxzt5b6FaBP247t3GgCt
FlnwKT0utHtttGu/f7rwDK0SspgwsgSq0l62QKxV8NgZZsR0XwvxWpIQRhX7eL6PES
3X14CLk018Aow==
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <sU815XyMYVgcVVo1yHJSUgfiraHeug7GNMMPxu_PQhv_Zhld3XPa82DawQp3vOsWppvvBZkPEt4h95fwALOcMPIy-wOvMp3fYb_xzV92V-E=@protonmail.com>
In-Reply-To: <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.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>
<YhFUiA9/YlY99Bok@petertodd.org>
<Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>,
Jeremy <jlrubin@mit.edu>
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 02:39:59 -0000
Good morning Peter and Jeremy,
> Good morning Peter and Jeremy,
>
> > On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
> >
> > > > Necromancing might be a reasonable name for attacks that work by ge=
tting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an "attack"? There is no such thing as an out-of-date transa=
ction, if
> > > you signed and broadcasted it in the first place. You can't rely on t=
he fact that
> > > a replacement transaction would somehow invalidate a previous version=
of it.
> >
> > Anyone on the internet can send you a packet; a secure system must be a=
ble to
> > receive any packet without being compromised. Yet we still call packet =
floods
> > as DoS attacks. And internet standards are careful to avoid making pack=
et
> > flooding cheaper than it currently is.
> > The same principal applies here: in many situations transactions do bec=
ome
> > out of date, in the sense that you would rather a different transaction=
be
> > mined instead, and the out-of-date tx being mined is expensive and anno=
ying.
> > While you have to account for the possibility of any transaction you ha=
ve
> > signed being mined, Bitcoin standards should avoid making unwanted necr=
omancy a
> > cheap and easy attack.
>
> This seems to me to restrict the only multiparty feebumping method to be =
some form of per-participant anchor outputs a la Lightning anchor commitmen=
ts.
>
> Note that multiparty RBF is unreliable.
> While the initial multiparty signing of a transaction may succeed, at a l=
ater time with the transaction unconfirmed, one or more of the participants=
may regret cooperating in the initial signing and decide not to cooperate =
with the RBF.
> Or for that matter, a participant may, through complete accident, go offl=
ine.
>
> Anchor outputs can be keyed to only a specific participant, so feebumping=
of particular transaction can only be done by participants who have been a=
uthorized to feebump.
>
> Perhaps fee accounts can include some kind of proof-this-transaction-auth=
orizes-this-fee-account?
For example:
* We reserve one Tapscript version for fee-account-authorization.
* Validation of this tapscript version always fails.
* If a transaction wants to authorize a fee account, it should have at leas=
t one Taproot output.
* This Taproot output must have tapleaf with the fee-account-authorizatio=
n Tapscript version.
* In order for a fee account to feebump a transaction, it must also present=
the Taproot MAST path to the fee-account-authorization tapleaf of one outp=
ut of that transaction.
This gives similar functionality to anchor outputs, without requiring an ex=
plicit output on the initial transaction, saving blockspace.
In particular, once the number of participants grows, the number of anchor =
outputs must grow linearly with the number of participants being authorized=
to feebump.
Only when the feerate turns out to be too low do we need to expose the auth=
orization.
Revelation of the fee-account-authorization is O(log N), and if only one pa=
rticipant decides to feebump, then only a single O(log N) MAST treepath is =
published.
Regards,
ZmnSCPxj
|
