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
|
Return-Path: <decker.christian@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4F4D3C004C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 10:38:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 3EEED84C19
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 10:38:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2QBtoMfvMhaj
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 10:38:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com
[209.85.218.48])
by fraxinus.osuosl.org (Postfix) with ESMTPS id D8A35849DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2020 10:38:33 +0000 (UTC)
Received: by mail-ej1-f48.google.com with SMTP id kq25so28906792ejb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Aug 2020 03:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=88uM8A6Hd3yclt8ZTHWna57u2Ykmn/HjGQt9HTQlEMQ=;
b=pM2FQtDHHhTTiAgrsvi4iHc5fgrRIcpmAEV4Ux77IHrf4gbtohESxM/42B8pgABXOE
qpBBrMSELQOLKrkxU4KWKQKOY54Sbr8LztvmN77VMmWTVYnbvm4mWlYps/nEGLBbuTrY
EbgHJKq8uhXYCVs0BYSqVo0n05yXglUWtH0HqdX98TGTs6AFqkvflYdEtjn4Nofhr6MG
hxj3pwqJ8nvDhnDuNwzWOTheUlpeCXAFJVda5lHUJXKEF+T5QfSh1siPw0gm9ZHrL4Ph
8gnNfWN/n96MNJV8Wi+iH6BqgBQ/W1I4ixsTY/gP9PAorA4RBp5Lsz7sbyCAbploM31t
iuag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=88uM8A6Hd3yclt8ZTHWna57u2Ykmn/HjGQt9HTQlEMQ=;
b=YYAn/L22s+4fEKwQa8I7qxgbq6EQBhsPpQIrrNuZXFz8/OxWjn7o22JVsmz92CkXTM
He9lwNf6FAF9KUNpN0XB146plVcBXhEAGSUFGUfVoHes7E9FazhZqLfviT4iL0acpjkO
qNwteqqTJG3Iyd26H3cWjifd4p1gOm1m7KtohcGt9p7sFqP1q4DAi+/1dmfK4SUNNJq7
spSmGLDvZ4qhA+YihbRAleRiT/wwwSXPMEk0EcUAvEzL6RKSYG4Cz842HLDmvCCsrc0X
bHUCtKJVpclWdvKZB1XBpg/8YV6wCgzGY9MBlwDyuOmVpMnLJCEq+7mB8KpHpFylchVy
IeIw==
X-Gm-Message-State: AOAM533ij2iYDO8GC5J7xoL4rLa5tO6VVvVKtHudyPAqurXjtAfzy6w+
OatAaKCXmV0eiWcj//lsL/k=
X-Google-Smtp-Source: ABdhPJzwtR6Q2zP1+sBqn58wjmutqQYawAPviueefQfHhtBOtFKwzp9lheKLWUjDILadZCG3vA9OIQ==
X-Received: by 2002:a17:906:1104:: with SMTP id
h4mr20752414eja.456.1596537512098;
Tue, 04 Aug 2020 03:38:32 -0700 (PDT)
Received: from localhost (243.86.254.84.ftth.as8758.net. [84.254.86.243])
by smtp.gmail.com with ESMTPSA id x20sm18444142edl.8.2020.08.04.03.38.29
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Tue, 04 Aug 2020 03:38:29 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lf-lists\@mattcorallo.com" <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au>
<4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com>
<i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
Date: Tue, 04 Aug 2020 12:38:20 +0200
Message-ID: <87zh7ay9ur.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
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: Tue, 04 Aug 2020 10:38:35 -0000
> Ah, right.
>
> A feasible attack, without the above, would be to connect to the
> fullnode of the victim, and connect to miners separately. Then you
> broadcast to the victim one of the old txes, call it tx A, but you
> broadcast to the miners a *different* old tx, call it B. The victim
> reacts only to tA, but does not react to B since it does not see B in
> the mempool.
>
> On the other hand --- what the victim needs to react to is *onchain*
> confirmed transactions. So I think all the victim needs to do, in a
> Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based
> mechanisms, is to monitor onchain events and ignore mempool events.
>
> So if we give fairly long timeouts for our mechanisms, it should be
> enough, I think, since once a transaction is confirmed its txid does
> not malleate without a reorg and a `SIGHASH_NOINPUT` signature can
> then be "locked" to that txid, unless a reorg unconfirms the
> transaction. We only need to be aware of deep reorgs and re-broadcast
> with a malleated prevout until the tx being spent is deeply confirmed.
This is indeed part of the reason why we chose to describe the protocol
on-chain first in the paper and lift it off-chain after showing the
basic functionality. This means that the protocol is still correct even
if executed solely on information derived from blocks and confirmed
transactions in those blocks. The timeouts have to be chosen carefully
to allow reacting in a timely fashion, however that is true for all
off-chain protocols.
> In addition, we want to implement scorch-the-earth,
> keep-bumping-the-fee strategies anyway, so we would keep
> rebroadcasting new versions of the spending transaction, and spending
> from a transaction that is confirmed.
Correct, it might be desirable to give a misbehaving node a papercut by
letting their update transaction confirm (taking their fee along with
it) and then reacting to the outdated update by overriding the effects
with a new update-settlement pair.
So, while being able to react to a transaction in the memory pool early
might be a nice addition, it is not strictly required for safety of the
protocol. I say nice addition, because it can allow replacing the
outdated transaction directly, thus saving the misbehaving node from the
fee papercut, but also save a bit of blockspace which that fee would
have paid for, and leave it available for other transactions.
Cheers,
Christian
|
