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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CF7A220F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jun 2019 01:22:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3A1B2174
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jun 2019 01:22:42 +0000 (UTC)
Date: Thu, 13 Jun 2019 01:22:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1560388960;
bh=jQl87smcBMC5aqa4O2ANXrpzJE4+9nJo0TLAsIjvbxo=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=DT1uHpVV3em7pZADsXefegQYSqx/YV8hUOv30vZ0HsJUudYjHIzcgCATtkdoHJHnL
Jfe4jTiU516yzCZaQXLZ1ka1HmY8fTx7b94b3b3WBgy/bynwON+u1vztED9wBFCJ+B
x7ZfGFjq+1Pq9Gq3YzeO7y0fFwuqOByFuS3scgcs=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xc6X8fAM-1Aow8xjcyCFL7Z5r0s7Vmr_FFo1Mjoz5Hh12I0_6VAU-mlX9nj0aNZjJZ3qq5ehICalNeOqgEh1ziaZiF-Zvz7s42HGK-LXoM0=@protonmail.com>
In-Reply-To: <CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com>
References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
<8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com>
<CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com>
<L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com>
<CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 13 Jun 2019 13:26:27 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic
blind signing server
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 13 Jun 2019 01:22:44 -0000
Good morning Ruben,
> > an early draft
>
> I meant an early draft of Statechains, sorry if that was confusing.
> But yes, it's essentially no different from channel factories without
> eltoo.
Sorry, I am referring to current issues with channel factories, which were =
not addressed in the original channel factories paper.
Basically, the "Stale Factory" and "Broken Factory" problems.
Broken factory seems unsolvable.
Stale factory is fixable if the channels within the factory use `SIGHASH_NO=
INPUT` (assuming it gets into Bitcoin) for all unilateral paths (use `SIGHA=
SH_ALL` for cooperative paths).
>
> > If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it see=
ms this transitory/common key can be used for the chaperone.
>
> That is a good point. One thing I have not yet fully analysed are the
> privacy considerations. Perhaps we don't want to reveal X on-chain.
On reflection, probably best not to.
It requires a script that reveals the pubkeys.
And it now becomes possible for the server to monitor the blockchain for re=
velation of server pubkey in a spend path.
This will let the server know, after-the-fact, that it was signing blockcha=
in transactions.
This might not let it preemptively censor or otherwise disrupt, but it *cou=
ld* sell the private fact that a statechain was used.
Combining it via MuSig is probably best, as the server is now unable to rec=
ognize even the pubkey (assuming it never is informed `X`).
>
> > This would be nearer to my own Smart Contracts Unchained
>
> Adding scripting is not my preferred approach. The beauty of the
> system is that the server doesn't evaluate any scripts whatsoever.
On reflection, this is probably best.
As the server is blinded, it cannot determine anything about the message be=
ing signed.
On the other cognition sub-agent, however, a simple scripting that allows "=
if somebody provides x of H(x) plus signature A, sign a blinded message M1,=
else if after 2:30PM PST on Jun 24 2019 if somebody provides signature of =
B, sign a blinded message M2" could still potentially be useful, and might =
allow "programmable escrow" like I imagine Smart Contracts Unchained could =
allow.
>
> That being said, Smart Contracts Unchained (SCU) can be inserted quite
> elegantly as a separate smart contracting layer.
>
> The observation is that anything that can be done with a UTXO
> on-chain, can also be done off-chain via Statechains, including SCU.
The Real (TM) observation is that anything that can be done with a UTXO onc=
hain, can also be done offchain via any updateable offchain cryptocurrency =
system, whether Statechains, Spillman, Decker-Wattenhofer, Poon-Dryja, or D=
ecker-Russell-Osuntokun.
(I should probably look up the authors of the Statechains paper to make my =
naming convention consistent)
One might observe that any updateable offchain cryptocurrency system worth =
its salt would have some way of unilaterally dropping transactions onchain.
Those transactions would create new UTXOs that can be spent by further tran=
sactions.
By presenting those "further transactions" to the offchain system, we can p=
rovide an argument that the offchain system can just "append" those "furthe=
r transactions" to the existing unilateral-case transactions, then cut-thro=
ugh the further transactions on its next update (i.e. delete the current UT=
XOs spent and insert the new UTXOs introduced by the "further transactions"=
).
(In the case of Statechains, you would present this argument to the signers=
of the latest `userPubKey`, not to the server, who is unaware of the seman=
tics of what it is signing)
Regards,
ZmnSCPxj
|
