summaryrefslogtreecommitdiff
path: root/1a/9a1d8dc3882c2c14898f94ad4ba80536248261
blob: 7e483bf91eb8b5d2f1ccff83742b48e66c5c77a8 (plain)
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
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EF2A9C0033
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Feb 2022 02:24:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id DD1BB40871
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Feb 2022 02:24:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 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, 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 M3OvqIhZ7oE8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Feb 2022 02:24:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by smtp4.osuosl.org (Postfix) with ESMTPS id CDD8A4049F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Feb 2022 02:24:44 +0000 (UTC)
Date: Sun, 20 Feb 2022 02:24:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1645323881;
 bh=Bw0I8iJOUDQpaAW6dIzyQHGEu2pExEXw17tWrpPG2TM=;
 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=e9phC6L2P3J6gyiSSwYlPuXMqQHtyTdrKrGSenCds8uMx0boIqmfent419h9ifqI/
 5qlwYhqK1evkeP7ZBSaEwE3qbKjizB2MtY57vTn/t/NAKqvPhcsn3KivOzxb8Ad+GH
 XFA/yRXuRzlO62GjM5RsPLGUqhWB/SqQcXU53rGtwOGw52M8Nv1rUEDAOyRnMlQh5e
 AGrGSFDVdh1F1Ni/EyH4OAHRLwBB3n6G+uRtp8lteXTqzaFzGfzrDAFn9WXZlkIRk7
 wKPKYlKA/Xx+gKttSGbxGIlwLj2Iz7YhvXUvpb+VKb/74sczOck/J03dBA0bI8Smv+
 HCePyla6CPOfQ==
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Id0jz_ihSCY4KpH4iCljOInrvHVpKIbxsrmROOdqY3mwCFDqSvGVkmFnYgFKzIhOTaqj3SI2Hc4WIZEusT_aJNURHR6nAMPtgwwA9ia2Ahw=@protonmail.com>
In-Reply-To: <YhFUiA9/YlY99Bok@petertodd.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Jeremy <jlrubin@mit.edu>,
 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 02:24:47 -0000

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 gett=
ing an
> > > out-of-date version of a tx mined.
> >
> > It's not an "attack"? There is no such thing as an out-of-date transact=
ion, if
> > you signed and broadcasted it in the first place. You can't rely on the=
 fact that
> > a replacement transaction would somehow invalidate a previous version o=
f it.
>
> Anyone on the internet can send you a packet; a secure system must be abl=
e to
> receive any packet without being compromised. Yet we still call packet fl=
oods
> as DoS attacks. And internet standards are careful to avoid making packet
> flooding cheaper than it currently is.
>
> The same principal applies here: in many situations transactions do becom=
e
> out of date, in the sense that you would rather a different transaction b=
e
> mined instead, and the out-of-date tx being mined is expensive and annoyi=
ng.
> While you have to account for the possibility of any transaction you have
> signed being mined, Bitcoin standards should avoid making unwanted necrom=
ancy a
> cheap and easy attack.
>

This seems to me to restrict the only multiparty feebumping method to be so=
me form of per-participant anchor outputs a la Lightning anchor commitments=
.

Note that multiparty RBF is unreliable.
While the initial multiparty signing of a transaction may succeed, at a lat=
er time with the transaction unconfirmed, one or more of the participants m=
ay regret cooperating in the initial signing and decide not to cooperate wi=
th the RBF.
Or for that matter, a participant may, through complete accident, go offlin=
e.

Anchor outputs can be keyed to only a specific participant, so feebumping o=
f particular transaction can only be done by participants who have been aut=
horized to feebump.

Perhaps fee accounts can include some kind of proof-this-transaction-author=
izes-this-fee-account?

Regards,
ZmnSCPxj