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
|
Return-Path: <tom@commerceblock.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id C9BBBC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 16:32:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 8B94F61225
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 16:32:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8B94F61225
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=commerceblock-com.20221208.gappssmtp.com
header.i=@commerceblock-com.20221208.gappssmtp.com header.a=rsa-sha256
header.s=20221208 header.b=g0HCMfHP
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham 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 st1SbgunpP5V
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 16:32:22 +0000 (UTC)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
[IPv6:2a00:1450:4864:20::52e])
by smtp3.osuosl.org (Postfix) with ESMTPS id 98B8E610B1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 16:32:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 98B8E610B1
Received: by mail-ed1-x52e.google.com with SMTP id
4fb4d7f45d1cf-51bece5d935so10269085a12.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jul 2023 09:32:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690389139;
x=1690993939;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=vAGvSvOVUJjqi7v6GfM3wdup03BUwloY/J0uQbD2ghA=;
b=g0HCMfHP31vN1oSTSlQ4yt2CfzCZbo0PQ2QH3Rf9j5c7iVltBKuarRmujHxef2N616
EMRpUUm3SPYsFGXclrZZUxefIWNslv6NeI5Fz31uNcVLjG0iyS6hGAjc/xZtKZTwXU9k
e3FyFwoTB3CaqOZBvMTgoL68zJ4/c/WP2+XFiiB2eX9OvWew1Tj2cooSwo5swX1nQQHh
WgzVOG+avD8FPGkeigmcaBkgzrGtW0F7Sn4yqjT5IbVHbppE4wavLcly+XPVhyta+Orz
D1Cwk0bII6zpiM4cruGC4q4E7CUjpaWmpsF6JYxnkLKOFKHpFC8xIVl3yU6Oxhq8iD1q
MMYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1690389139; x=1690993939;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=vAGvSvOVUJjqi7v6GfM3wdup03BUwloY/J0uQbD2ghA=;
b=MHRlAe1iPTyQsoAqcNqcF0W0mHWQsfZxEIgHiSLTTLky98pLn9+WuvKJQyX+ckH5Wz
Uv/vvJlAprn6BcfKhunZCVY50/4oZGKM84RZsNoCqT+Tfa+SBrlsnLt9CRMsu8S1oRfe
OYU4MZbOhgVDSJQmHI7e7EWXjA4ViSpE+vO3yfzHzWeJavZyjKqkqyhyQOiFcCieTXnM
2reBy+cQYVF2n7iAGcx7gis729BLjS8MpRUdFXAmu/J8q2O2Qy56aSaPub+d6A67AR3+
kBmmqLA/AwdE5ZYylpRG/LO7ldjv0BHMfxbtufqyaC2IE4iJO/8FBebnYB0eiwjWNxnJ
tLxw==
X-Gm-Message-State: ABy/qLYZA3Q3a+PImuyO6IZ7wmEZeWdXc+5y2suMWtWU0mkIO+K4GC2S
woJuuofv3F9eetVP4qSrR6TPAEZo3+AxkkQP4L5JgLPJaVY4HHRlDg==
X-Google-Smtp-Source: APBJJlF0olt/ltvagyxSdfq3o7CfARuagM1961uZku1wijx8codAe5gFzERtWQnTmyW5A1e4O2y3vDN908LeBljjTIk=
X-Received: by 2002:aa7:c2d6:0:b0:522:37f1:5fd0 with SMTP id
m22-20020aa7c2d6000000b0052237f15fd0mr2045148edp.5.1690389139088; Wed, 26 Jul
2023 09:32:19 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
From: Tom Trevethan <tom@commerceblock.com>
Date: Wed, 26 Jul 2023 17:32:06 +0100
Message-ID: <CAJvkSsft_z6s90oVnewmFU66hiURDHSvmGdmQETVJOW1C1xEyQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002afa1006016664e3"
X-Mailman-Approved-At: Thu, 27 Jul 2023 00:19:01 +0000
Subject: [bitcoin-dev] Blinded 2-party Musig2
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: Wed, 26 Jul 2023 16:32:23 -0000
--0000000000002afa1006016664e3
Content-Type: text/plain; charset="UTF-8"
@moonsettler
Your scheme for blinding the challenge (e in your notation) works as far as
I can tell. It is better than the way I suggested as it doesn't require
modifying the aggregated pubkey (and the blinding nonce can be different
for each signature).
@AdamISZ and @Jonas
It is not necessarily the server that would need to verify that the
challenge is 'well formed', but the receiver of a statecoin. The concept of
having a blinded statechain server is that each signature generated for a
shared public key must be verified by the receiver of the corresponding
coin. So a receiver would retrieve the number of co-signings performed by
the server (K) and then verify each of the K signatures, and K transactions
that they have received from the sender. They can additionally verify that
each of the K R values has been correctly formed with a proof of secret
value for creating R2 (along with the R1 from the server).
--0000000000002afa1006016664e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><a class=3D"gmail_plusreply" id=
=3D"plusReplyChip-0">@</a>moonsettler<br>
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Your =
scheme for blinding the challenge (e in your notation) works as far as I ca=
n tell. It is better=C2=A0than the way I suggested as it doesn't requir=
e modifying the aggregated pubkey (and the blinding nonce can be different =
for each signature).=C2=A0</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote"><a class=3D"gmail_plusreply" id=3D"plusReplyChip-1">@<=
/a>AdamISZ and @Jonas<br></div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">It is not necessarily the server that would need to ver=
ify that the challenge is 'well formed', but the receiver=C2=A0of a=
statecoin. The concept of having a blinded statechain server is that each =
signature generated for a shared public key must be verified by the receive=
r of the corresponding coin. So a receiver=C2=A0would retrieve the number o=
f co-signings performed by the server (K) and then verify each of the K sig=
natures, and K transactions that they have received=C2=A0from the sender. T=
hey can additionally verify that each of the K R values has been correctly =
formed with a proof of secret value for creating R2 (along with the R1 from=
the server).=C2=A0</div></div>
--0000000000002afa1006016664e3--
|
