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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A3BA5C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 03:38:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7E11181F35
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 03:38:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7E11181F35
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=PWpx3xnT
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 smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id d33QzZwHIx8k
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 03:38:02 +0000 (UTC)
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18])
by smtp1.osuosl.org (Postfix) with ESMTPS id 4C37B81F34
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 03:38:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4C37B81F34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1695008278; x=1695267478;
bh=jBw2T3g9RSLT8X4Wu7K8/V1q3HBwGxAuFc6GbTSszx8=;
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=PWpx3xnTz9wLOWFIn1w9mDX7Vt03eq0E20xYKsC5o07TymFYuyrmfV6hxlujRbmVz
mIJdSt3Fezc1qFSvzayv8PR45UkYGQmmU3td+SJkX3vsf8Sw9NAMOkIkfeFTJuU/v3
2xt/1jYYxYuwpPOaYZHILv0QgsR7ir6Y6zJGONGM0LGJOWDil/elUn/iMSTOAru2TS
rfTBf3iQC+i4EtsUphBm+hCDHu15SLsKKq+9LbbeDBYhTSqrr5DqgqsMYDZRXZKgWL
oJvNHDvnKn0smQfJ0weoTaHoZ0B42TG0+8//sey7aqy+nqdts3oLjQEBJPRg93DClR
2k4VxAm/LS8vA==
Date: Mon, 18 Sep 2023 03:37:46 +0000
To: "David A. Harding" <dave@dtrt.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dsTMsMJ5WkE8-OInpB-9jqgBoDuQbJXV7uGxTGPYQGdfBKhR-edq7HZIuR8aKJ2TwPY6pIV1vAF1BTTMxrn68h0Qa0TfOoQRGZ_OwBfwoUM=@protonmail.com>
In-Reply-To: <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
<EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
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: Mon, 18 Sep 2023 03:38:02 -0000
Good morning Dave,
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, September 18th, 2023 at 12:12 AM, David A. Harding <dave@dtrt.or=
g> wrote:
>=20
> On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev bitcoin-dev=
@lists.linuxfoundation.org wrote:
>=20
> > Now, suppose that participant A wants B to be assured that
> > A will not double-spend the transaction.
> > Then A solicits a single-spend signature from the actuary,
> > getting a signature M:
> >=20
> > current state +--------+----------------+
> > ---------+-------------+ | | (M||CSV) && A2 |
> > |(M||CSV) && A| ----> | M,A +----------------+
> > +-------------+ | | (M||CSV) && B2 |
> > |(M||CSV) && B| +--------+----------------+
> > +-------------+
> > |(M||CSV) && C|
> > ---------+-------------+
> >=20
> > The above is now a confirmed transaction.
>=20
>=20
> Good morning, ZmnSCPxj.
>=20
> What happens if A and M are both members of a group of thieves that contr=
ol a moderate amount of hash rate? Can A provide the "confirmed transaction=
" containing M's sign-only-once signature to B and then, sometime[1] before=
the CSV expiry, generate a block that contains A's and M's signature over =
a different transaction that does not pay B? Either the same transaction or=
a different transaction in the block also spends M's fidelity bond to a ne=
w address exclusively controlled by M, preventing it from being spent by an=
other party unless they reorg the block chain.
Indeed, the fidelity bond of M would need to be separately locked to `(M &&=
B) || (M && CSV(1 year))`, and the actuary would need to lock new funds be=
fore the end of the time period or else the participants would be justified=
in closing the mechanism with the latest state.
And of course the bond would have to be replicated for each participant `A`=
, `B`, `C`.... as well, reducing scalability.
If possible, I would like to point attention at developing alternatives to =
the "sign-only-once" mechanism.
Basically: the point is that we want a mechanism that allows the always-onl=
ine party (the "actuary") to *only* select transactions, and not move coins=
otherwise.
This is the nearest I have managed to get, without dropping down to a proof=
-of-work blockchain.
As noted, in a proof-of-work blockchain, the miners (the always-online part=
y of the blockchain) can only select transactions, and cannot authorize mov=
es without consent of the owners.
That is what we would want to replicate somehow, to reduce interactivity re=
quirements.
Regards,
ZmnSCPxj
|
