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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7CA0EC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Mar 2022 23:01:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 5720884849
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Mar 2022 23:01:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, 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=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
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 wfv2ikeziERN
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Mar 2022 23:01:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8C3758480A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Mar 2022 23:01:49 +0000 (UTC)
Date: Fri, 18 Mar 2022 23:01:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1647644507;
bh=1zoaYGzaSOfMab/6MFdpJGS818611PV8Biuh+iWcTfg=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=i4SJyZd976UMxxbCvkeVVydtmW0pS2O3UiDGgUipck6Ki1/S30EieEO7a+wzPJEeH
HXbrzxe3DUvguSdE9o+5QHaypC6xFxUV+sW345bHHHiXnoxEO7wTeVGgRNGf/gFmkh
NYeYrZqcb0cY4R8x2lPr29tT6IwQwG89ISI5mdKNYXwG0TJSWvzJR4y3TL+kaQDFkZ
WFxIuB7PfyNbgLjy9d4upZT0c2UwnueLEQ0JLlgyDxyGKDGw5tv+UgVdh+FkyuB1DG
44H2/4WojIU7F2Ozi8y3i0ipEBrsSSzKda6b1cDMP7z/Sxv+jqvtZ5mdGh4iI5EizB
GVNLLTLZPGmEw==
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com>
In-Reply-To: <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
<CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
<CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
<CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
<CAMZUoKkPF6gPGpDWy1U+0GCONF-_qsTcOz0S1X+vx8_Kfqr8mw@mail.gmail.com>
<CABm2gDpFCcNcJEwia-nBhpWSjQv7DPEpqTu-bRC8RDHaoDU-=g@mail.gmail.com>
<CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Speedy Trial
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: Fri, 18 Mar 2022 23:01:50 -0000
Good morning Billy,
> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a=
=C2=A0coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% su=
pport:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been =
spent.
> C. Poll results are considered only at each particular block height, wher=
e the support and opposition responses are weighted by the UTXO amount (and=
the support/oppose fraction in the message). This means you'd basically se=
e a rolling poll through the blockchain as new signed poll messages come in=
and as their UTXOs are spent.=C2=A0
>
> This is not vulnerable to sybil attacks because it requires access to UTX=
Os and response-weight is directly tied to UTXO amount. If someone signs a =
poll message with a key that can unlock (or is in some other designated way=
associated with) a UTXO, and then spends that UTXO, their poll response st=
ops being counted for all block heights after the UTXO was spent.=C2=A0
>
> Why put support and oppose fractions in the message? Who would want to bo=
th support and oppose something? Any multiple participant UTXO would. Eg li=
ghtning channels would, where each participant disagrees with the other. Th=
ey need to sign together, so they can have an agreement to sign for the fra=
ctions that match their respective channel balances (using a force channel =
close as a last resort against an uncooperative partner as usual).=C2=A0
This does not quite work, as lightning channel balances can be changed at a=
ny time.
I might agree that you have 90% of the channel and I have 10% of the channe=
l right now, but if you then send a request to forward your funds out, I ne=
ed to be able to invalidate the previous signal, one that is tied to the fu=
lfillment of the forwarding request.
This begins to add complexity.
More pointedly, if the signaling is done onchain, then a forward on the LN =
requires that I put up invalidations of previous signals, also onchain, oth=
erwise you could cheaty cheat your effective balance by moving your funds a=
round.
But the point of LN is to avoid putting typical everyday forwards onchain.
> This does have the potential issue of public key exposure prior to spendi=
ng for current addresses. But that could be fixed with a new address type t=
hat has two public keys / spend paths: one for spending and one for signing=
.=C2=A0
This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, wi=
th "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of th=
e fund, with "hot" key being delegates who are semi-trusted, but not as tru=
sted as the "cold" key.
So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much =
as possible for security.
I suppose the "cold" key could be put online just once to create the signal=
message, but vault owners might not want to vote because of the risk, and =
their weight might be enough to be important in your voting scheme (conside=
r that the point of vaults is to protect large funds).
A sub-issue here with the spend/signal pubkey idea is that if I need to be =
able to somehow indicate that a long-term-cold-storage UTXO has a signaling=
pubkey, I imagine this mechanism of indioating might itself require a soft=
fork, so you have a chicken-and-egg problem...
Regards,
ZmnSCPxj
|
