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
|
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 A9295C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Oct 2023 13:36:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 846F94050E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Oct 2023 13:36:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 846F94050E
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=SOXTKq9B
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, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 P5TKusG0bHfk
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Oct 2023 13:36:19 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
[51.77.79.158])
by smtp4.osuosl.org (Postfix) with ESMTPS id 81C2B40069
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 Oct 2023 13:36:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 81C2B40069
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1697376970; x=1697636170;
bh=aLNK9tGpEEtOj1Oda63joaR7DnK5vg9q7hnM52zadPc=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=SOXTKq9B42ql21dXqx6YDuU+ndYcN9pQgoxR922aor7RMQqTpIIZK2k1ZQI2HQz3V
7vsKxP8rVpko0vvii4YcEbFy6VMK4wtkAWujQvBm8+xV2wpyrPcB0Cd9uKyhTCA2I9
diYOxhMWoOnqYbTUV6OzKP7IbMGxstGsAqRqsltPPAL8iha0bo468nnqEQtTYR/f7j
jy9Z+VWXX+H901Pl9cgTTEKv3daWb4CQKER6AExoM8QvJ05B+wHcxV2QepNJVFZgI3
jjyrt4a5gV5VVK9bTGXeeoL0GHHVf4qhx96ZYiMpwsLbUidlV6tKct68MgrWimk03t
j1PslIN6oSGSQ==
Date: Sun, 15 Oct 2023 13:36:00 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6I7jG9PNNaWUZ8OnqAAQg0TJQ9PwGvD05iXYSOuN0XiezIJCChGlsxKZ30RwYfpeKlJyj7gB_rq1kPSR8UX6tOm-X7zanL_MXVrGEon3txc=@protonmail.com>
In-Reply-To: <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
<EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
<dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Sun, 15 Oct 2023 13:36:20 -0000
Good morning list,
I have been thinking further on this with regards to BitVM.
By my initial analyses, it seems that BitVM *cannot* be used to improve thi=
s idea.
What we want is to be able to restrict the actuary to only signing for a pa=
rticular spend exactly once.
The mechanism proposed in the original post is to force `R` reuse by fixing=
`R`.
This requires a change in Bitcoin consensus on top of `SIGHASH_ANYPREVOUT` =
(which is desirable not only for its enablement of Decker-Russell-Osuntokun=
, which is multiparticipant, but also makes it more convenient as we can ma=
ke changes in the offchain mechanism state asynchronously with the particip=
ants and actuary signing off on new transactions; we can "lock" the next st=
ate to some set of transactions occurring, then have the actuary "confirm" =
new transactions by signing them, then have the signature still be valid on=
the new state due to `SIGHASH_ANYPREVOUT` ignoring the actual input transa=
ction ID).
The best I have been able to come up with is to have a program that checks =
if two signatures sign different things but have the same public key.
If this program validates, then the actuary is known to have cheated and we=
can arrange for the actuary to lose funds if this program validates.
However, BitVM triggers on DIShonest execution of the program, so that prog=
ram cannot be used as-is.
Honest execution of the program leads to the BitVM contract resolving via t=
imeout.
I have tried to figure out some way to change the "polarity" of the logic s=
o that the actuary is punished, but it requires that the actuary act as val=
idator instead of prover (and the aggrieved participant who was expecting t=
he actuary to not violate the sign-only-once is the prover, which makes lit=
tle sense, as the participant can challenge the actuary and force it to put=
up funds, then neglect to actually prove anything and enter the default ti=
meout case where the prover gets the funds --- it has to be the actuary in =
the prover position, only getting back its funds after a timeout).
The opposite of showing that there exists two signatures with different mes=
sages but the same public key is to show that there does not exist any othe=
r signatures with a different message but same public key.
If such a program were written, then it would be trivial to make that progr=
am pass by simply denying it an input of any other signature, and an actuar=
y in prover position can always commit to an input that lacks the second si=
gnature it made.
The actuary can run a program *outside* of BitVM, so it is also pointless t=
o have the signing algorithm be written in BitVM.
Finally, in the actuarial system, the actuary is supposed to provide *somet=
hing* that would make a transaction be immediately confirmable, instead of =
after a timeout.
But in BitVM, the *something* that the prover provides that makes some tran=
saction immediately confirmable is to provide a dishonest execution of a Bi=
tVM program; it is the timeout that is the honest execution of the BitVM pr=
ogram.
In addition, the actuary should be restricted so that it can only show this=
for *one* transaction, and not for any other transactions.
There are more possible dishonest executions of a BitVM program than just o=
ne, but only one honest execution, which is the opposite of what we want.
So, so far, I have not been able to figure out how to use BitVM to replace =
the current forced `R` reuse mechanism for preventing multiple times the ac=
tuary commits.
Regards,
ZmnSCPxj
|
