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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A2884C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2023 09:41:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 89FF5610CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2023 09:41:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 89FF5610CD
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=F8YmT6MQ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, 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=no autolearn_force=no
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 2f_YO6BPBOW6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2023 09:41:52 +0000 (UTC)
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp3.osuosl.org (Postfix) with ESMTPS id B66C060B0B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Sep 2023 09:41:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B66C060B0B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1694511710; x=1694770910;
bh=36F/4Mek9x1bP/JBsT+s65Sqc2urWIjb5/tBEBA9kzc=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=F8YmT6MQJfiFXttCL9lLRob98QDeXmtudw27gsiZSY5hs4MeFT/UlmnK+wbhqAH2e
XrBxkajlHz3WO2YbZYgzTiqALMxPIwZp9cx0uWXJN5xIF+YtfwJvnY2nQi0B1VGq/X
AnH636azGioKko56VAcSnxteF1dFSI9dhAb1uRtZyCRVrps1SjejK6uM9XJivijWYv
Pnm6LQPU3Ipfjqx9iroiFrmm1NrAZzEldcl+hfnm96nITuieESEDFEnueY9Tm7UXTp
X0pu2inb6ZZon6dkMwkAGuuj7x+gYyTwq/SRCYd4xvhDts9dO23GlLn7WISoRe+cjG
L7nheTFRGiaaA==
Date: Tue, 12 Sep 2023 09:41:18 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6iN_WxykhKvHyD1bZRwbbPnePA36zekfcmUFDAchzjw6j7uSYXVmhrHRBhvAU-igU4AAGAggcV1FI9ScujGOZN8fN1GRZWN5u8rs1FMpSCQ=@protonmail.com>
In-Reply-To: <CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
<CALZpt+ECDxM5mD3e0UjsS+r+E+xYLim-yUYoJ_P9Vpjk32_pPA@mail.gmail.com>
Feedback-ID: 2872618:user:proton
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>
Subject: Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In
N-of-N (N > 2) Multiparticipant Offchain Mechanisms
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, 12 Sep 2023 09:41:53 -0000
Good morning Antoine,
> Hi Zeeman
>=20
> > What we can do is to add the actuary to the contract that
> > controls the funds, but with the condition that the
> > actuary signature has a specific `R`.
>=20
> > As we know, `R` reuse --- creating a new signature for a
> > different message but the same `R` --- will leak the
> > private key.
>=20
> > The actuary can be forced to put up an onchain bond.
> > The bond can be spent using the private key of the actuary.
> > If the actuary signs a transaction once, with a fixed `R`,
> > then its private key is still safe.
>=20
> > However, if the actuary signs one transaction that spends
> > some transaction output, and then signs a different
> > transaction that spends the same transaction output, both
> > signatures need to use the same fixed `R`.
> > Because of the `R` reuse, this lets anyone who expected
> > one transaction to be confirmed, but finds that the other
> > one was confirmed, to derive the secret key of the
> > actuary from the two signatures, and then slash the bond
> > of the actuary.
>=20
> From my understanding, if an off-chain state N1 with a negotiated group o=
f 40 is halted in the middle of the actuary's R reveals due to the 40th par=
ticipant non-interactivity, there is no guarantee than a new off-chain stat=
e N1' with a new negotiated group of 39 (from which evicted 40th's output i=
s absent) do not re-use R reveals on N1. So for the actuary bond security, =
I think the R reveal should only happen once all the group participants hav=
e revealed their own signature. It sounds like some loose interactivity is =
still assumed, i.e all the non-actuary participants must be online at the s=
ame time, and lack of contribution is to blame as you have a "flat" off-cha=
in construction (i.e no layering of the promised off-chain outputs in subgr=
oups to lower novation interactivity).
Yes, there is some loose interactivity assumed.
However:
* The actuary is always online and can gather signatures for the next state=
in parallel with signing new transactions on top of the next state.
* This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top =
of the next state might spend either the actual next state (if the next sta=
te is successfully signed), or the current state plus additional transactio=
ns (i.e. the transaction that move from current state to next state) (if th=
e next state fails to get fully signed and the participants decide to give =
up on the next state getting signed).
> More fundamentally, I think this actuarial system does not solve the "mul=
ti-party off-chain state correction" problem as there is no guarantee that =
the actuary does not slash the bond itself. And if the bond is guarded by u=
sers' pubkeys, there is no guarantee that the user will cooperate after the=
actuary equivocation is committed to sign a "fair" slashing transaction.
Indeed.
One can consider that the participants other than the actuary would generat=
e a single public key known by the participants.
But then only one sockpuppet of the actuary is needed to add to the partici=
pant set.
Basically, the big issue is that the actuary needs to bond a significant am=
ount of funds to each participant, and that bond is not part of the funding=
of the construction.
Other ways of ensuring single-use can be replaced, if that is possible.
Do you know of any?
Regards,
ZmnSCPxj
|
