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
|
Return-Path: <dave@dtrt.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 95DCFC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 00:12:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5A51060EF9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 00:12:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5A51060EF9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, 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 6yX70nG66Hsg
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 00:12:54 +0000 (UTC)
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp3.osuosl.org (Postfix) with ESMTPS id 835E560EF6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 00:12:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 835E560EF6
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id C87992800043;
Sun, 17 Sep 2023 17:12:50 -0700 (PDT)
Received: from [127.0.0.1] (unknown [173.197.107.5])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Sun, 17 Sep 2023 17:12:49 -0700 (PDT)
Date: Sun, 17 Sep 2023 14:12:45 -1000
From: "David A. Harding" <dave@dtrt.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
User-Agent: K-9 Mail for Android
In-Reply-To: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
References: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
Message-ID: <EB311DE7-171B-4D58-B6CF-44E6627D8F14@dtrt.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 488e.65079601.aa646.0
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 00:12:55 -0000
On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev <bitcoin-dev=
@lists=2Elinuxfoundation=2Eorg> wrote:
>Now, suppose that participant A wants B to be assured that
>A will not double-spend the transaction=2E
>Then A solicits a single-spend signature from the actuary,
>getting a signature M:
>
> current state +--------+----------------+
> ---------+-------------+ | | (M||CSV) && A2 |
> |(M||CSV) && A| ----> | M,A +----------------+
> +-------------+ | | (M||CSV) && B2 |
> |(M||CSV) && B| +--------+----------------+
> +-------------+
> |(M||CSV) && C|
> ---------+-------------+
>
>The above is now a confirmed transaction=2E
Good morning, ZmnSCPxj=2E
What happens if A and M are both members of a group of thieves that contro=
l 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 o=
r a different transaction in the block also spends M's fidelity bond to a n=
ew address exclusively controlled by M, preventing it from being spent by a=
nother party unless they reorg the block chain=2E
If the CSV is a significant amount of time in the future, as we would prob=
ably want it to be for efficiency, then the thieving group A and M are part=
of would not need to control a large amount of hash rate to have a high pr=
obability of being successful (and, if they were unsuccessful at the attemp=
ted theft, they might not even lose anything and their theft attempt would =
be invisible to anyone outside of their group)=2E
If A is able to double spend back to herself funds that were previously in=
tended to B, and if cut through transactions were created where B allocated=
those same funds to C, I think that the double spend invalidates the cut-t=
hrough even if APO is used, so I think the entire mechanism collapses into =
reputational trust in M similar to the historic GreenAddress=2Eit co-signin=
g mechanim=2E
Thanks,
-Dave
[1] Including in the past, via a Finney attack or an extended Finney attac=
k supported by selfish mining=2E =20
|
