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
|
Return-Path: <tom@commerceblock.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 50D38C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jun 2020 18:12:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 45211272B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jun 2020 18:12:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NaUK42ophntA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jun 2020 18:12:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com
[209.85.218.51])
by silver.osuosl.org (Postfix) with ESMTPS id 2A04220104
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jun 2020 18:12:05 +0000 (UTC)
Received: by mail-ej1-f51.google.com with SMTP id mb16so10993502ejb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jun 2020 11:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=BHS+T0gNLLww6LPYKcWxnNtmZqBDdMqSu8LLpBAUPkw=;
b=GqSiEsO+y49bTawRdDVYOqioNj5AgMn64c6Vv7HUwsPH0LmVi8Y6Xu0d1FOZ7CCN8v
JUTbx0K3MDNVWv1fvs+ULTuWD541AySXF6XkPn8vJda3Oe4nNVmL0uuWraW3bbZvn86w
8ma0cRxETlU/d040CKEq6mTFm8vQzf3G1K1PuFEYlDYvYSGMQhYA6wDy1OOiPDNPINxr
oAfRdtZ8z718moEcqJiczTMMwu8MRMLYQxZWvapU/bgbQ5oceEYnkg0csl9NhsHs59TS
hIZ6FRfuCXDtOjE99QfMaipue6RPVtvD6w7930WIJF2b/HO8xb4OardrXpROF7SuQh9Y
JhqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=BHS+T0gNLLww6LPYKcWxnNtmZqBDdMqSu8LLpBAUPkw=;
b=bk4kzUbgmnJy/rNU0s5dWJSNSOjL7WZk8BmFnlweBUsNFqs0LrBYkkKeZzshB81FKt
qIiKGYHm0+WNWoQCweiZw2cHdixtWIl4E+03uUCbXZvJvej1IJGuhX4CURQ+b5Vf307y
I+tlRVz+RrPh5mCLDEXYdNC39oZ9m7+xCMpsrQ9D6IThBYSbxtY10ErxIqpniQ3SlWYF
lUwDr7BfYd1CWjNjX9ngGvGVJZSMNOBiWLbMqsPTBj2HdMg9emGyK20jgbawCoiyJrO/
rVGWQ4x6f6NSDP/7PdtLws/S0xT2erdZkICKss/OhFWh/80ch+iupgjs9sAyXx3DMUkw
Lcsw==
X-Gm-Message-State: AOAM530q41NTJQiVp/IexdJaQcSSYnJ5yuI1NNDvKKoMJpn2E8NAwCaf
2e3VUUUo6Es910FvOHjyO+Y5gEcKLnJcwqoY7VcdvNAEQ8sI
X-Google-Smtp-Source: ABdhPJyeVBUdaG6ONF+4bI1hr4Buh4SgImNnc5Gr8brtP0ZIxlKNSD9BicmCY4EEd+Su71FxtPM6dtYdU4KfAcWdvRA=
X-Received: by 2002:a17:906:28da:: with SMTP id
p26mr13832807ejd.551.1591985522880;
Fri, 12 Jun 2020 11:12:02 -0700 (PDT)
MIME-Version: 1.0
From: Tom Trevethan <tom@commerceblock.com>
Date: Fri, 12 Jun 2020 19:11:52 +0100
Message-ID: <CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000094489205a7e703fb"
X-Mailman-Approved-At: Fri, 12 Jun 2020 19:23:26 +0000
Subject: [bitcoin-dev] Blind Statechains
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, 12 Jun 2020 18:12:06 -0000
--00000000000094489205a7e703fb
Content-Type: text/plain; charset="UTF-8"
Hello,
A statechain implementation and service co-signs 'backup' (off-chain)
transactions to transfer ownership of a UTXO from one owner to the next. A
suggested here
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
, this service (the statechain entity or SE) can be engineered to be
'blind' to the transactions it is signing (i.e. it does not and cannot know
the details of the transactions it is signing) which can give significant
privacy benefits. It would enable more private off-chain coin-swaps, and
make collusion more difficult.
The only downside of a blind SE is that it can no longer enforce the rules
governing the sequence of backup transactions it co-signs as owners can ask
the SE to cosign any transaction. So each new owner of a UTXO must receive,
store and verify the full sequence of previous owner backup transactions to
make sure that no previous owner has asked the SE to sign a transaction
that could be used to steal the UTXO. This may end up making wallets more
bloated and clunky, given that ownership of a UTXO could change hands
thousands of times off-chain.
In the case of a multisig, and Schnorr signatures, existing blind Schnorr
protocols could be used to implement a blind SE, however we are opting to
use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA
will give a much bigger anonymity set). There is no current 2P ECDSA
protocol that enables one of the two signers to be completely blinded, but
it seems that this would require only minor modifications to an existing 2P
ECDSA scheme (outlined here
https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md
based on Lindell 2017 https://eprint.iacr.org/2017/552 ).
Any comments on any of this gratefully received.
Tom
--00000000000094489205a7e703fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>A statechain implementation and service co-s=
igns 'backup' (off-chain) transactions to transfer ownership of a U=
TXO from one owner to the next. A suggested here <a href=3D"https://medium.=
com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae48=
45a4a39">https://medium.com/@RubenSomsen/statechains-non-custodial-off-chai=
n-bitcoin-transfer-1ae4845a4a39</a> , this service (the statechain entity o=
r SE) can be engineered to be 'blind' to the transactions it is sig=
ning (i.e. it does not and cannot know the details of the transactions it i=
s signing) which can give significant privacy benefits. It would enable mor=
e private off-chain coin-swaps, and make collusion more difficult. <br><br>=
The only downside of a blind SE is that it can no longer enforce the rules =
governing the sequence of backup transactions it co-signs as owners can ask=
the SE to cosign any transaction. So each new owner of a UTXO must receive=
, store and verify the full sequence of previous owner backup transactions =
to make sure that no previous owner has asked the SE to sign a transaction =
that could be used to steal the UTXO. This may end up making wallets more b=
loated and clunky, given that ownership of a UTXO could change hands thousa=
nds of times off-chain. <br><br>In the case of a multisig, and Schnorr sign=
atures, existing blind Schnorr protocols could be used to implement a blind=
SE, however we are opting to use two-party ECDSA (because there is no Schn=
orr yet, and in any case ECDSA will give a much bigger anonymity set). Ther=
e is no current 2P ECDSA protocol that enables one of the two signers to be=
completely blinded, but it seems that this would require only minor modifi=
cations to an existing 2P ECDSA scheme (outlined here <a href=3D"https://gi=
thub.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md">https://g=
ithub.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md</a> based=
on Lindell 2017 <a href=3D"https://eprint.iacr.org/2017/552">https://eprin=
t.iacr.org/2017/552</a> ). <br><br>Any comments on any of this gratefully r=
eceived. <br><br>Tom<br></div>
--00000000000094489205a7e703fb--
|
