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
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Return-Path: <dustinpaystaxes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 74B0A487F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 20:03:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com
[209.85.128.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5B4574A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 20:03:20 +0000 (UTC)
Received: by mail-wm1-f50.google.com with SMTP id a62so15462752wmh.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 12:03:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=xtCn6v3ssOz4h/bgwiSZEfE6xg94zwhDXZ+l7fRtv3Q=;
b=C0TWQVj7QCfzAB5sVC56xM5y4S4ndECME+S86+EGdrp3p69VyXwlQc7trG0zjEhVjp
u48gtB8jdqhBGlEUCR1QSbuTUJc4A0cLIuS3+NZ9vchAUqDb+yGNhimOCYUytpqm1wkG
Z/2k0tTmSTb/ej5AzdXxc4f52DB88Ly56l6ravP+Sam19FnwRaoyVDh7DHMPx1zHSoKK
LHNpCtYJhxwNv4zBe/PLkm5QQwb3nqNTbz/uqlx5wyQbTIyO7FIbF8XBAUcseehqwBEL
oRFtSaHneCJlYmFXs4wo2cjmiOzmpsz1D3jdkm2WVPoQN4WO55+Rj1p/RUGQUuk4otmM
9hRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=xtCn6v3ssOz4h/bgwiSZEfE6xg94zwhDXZ+l7fRtv3Q=;
b=TCjtNa0mg5fWgR3e+xsvHcDbiHGAS5s5heBB2qAFiacS+jpUmEfB+sUBhvW9rE8vWS
kZuYPUqClsZiMO0jVm6R7b9bwNb14bBnsiT5YKtzVlS1juNEa6gYHPI59/adsc/Ce1cq
qPTX9mv9q7PaT0iuzi08dlo4tfGOqhhNvfrKOM44+PofYBv4NWD+eBsn4olAXUaCVrDB
6sNbcf3wKxNkO6LWlUiT+9laP5BHXCw53STfOSbE97WXEPyv4GPWTlQHARXn/boo4KGF
75PyX0/tyU6P21rINRFYdgX0oL+yvffX71Utlt6P5m1vbZuX2iCJachASsVABtswkGke
s2ow==
X-Gm-Message-State: AJcUukcWj98YQPV0j8JYds7WTLsHSZFvbl59g1URrLuggllmSdnZU8c/
wgPbWNOBK8Nljjj/aMiIQ+GJUqgjDEe6+AZoxFEyzg==
X-Google-Smtp-Source: ALg8bN4QBodjUoAcgOkLSVvDYR8jpb0rrYWGXw3dz2i8bWCE4zjJ7RqJarm9ijK26MOGpcoTPoq6xwwz9bjVfNcWLn4=
X-Received: by 2002:a7b:cf0f:: with SMTP id l15mr5438205wmg.30.1548187398692;
Tue, 22 Jan 2019 12:03:18 -0800 (PST)
MIME-Version: 1.0
References: <CACV3+OU1ynRuR2SioW+O+CAp5M7ZQA6af_hEY5JZCVrXpqjtKQ@mail.gmail.com>
<BTyUDt_7oOQmFj_V61w2eUJ7rfi-eOuNphy5nN0xNAhY4sUHnR2-0U9m-ZEKip4YjFi2-hGBtucvFv7nCTVo3aBxZ94VQCa1Kx2pP_zgdxU=@protonmail.com>
<CACV3+OWjszx6istHo7yaNxiS22kyhHQhcPxGT3QLDx3KPUMU6g@mail.gmail.com>
<nq9NDv6z-EJuJ9jGMWdlIZbpVM6Rm8QyuWL3nRYtXWF90I-cErA_WS1ib28kt950bZYyfF1_eP153aDjhUy523wYSM9TVaeHqeZdp3xJpsk=@protonmail.com>
<CACV3+OXQsUsgquJWZ9o8tTtak=axnbsdiNgLzF-j6yz1dDv4bA@mail.gmail.com>
<wTXHV7W_AXHz5xdhXJVJr2OdSpEOaFh0PBQubFdZv4JyF6SlImszj2QyF9G-_Dem06A3iBWLF3vdgiHC_NlsVqy7DFX5XTphajNnMqiU6r0=@protonmail.com>
<9D2883DC-360C-401A-B518-B8205A3AAA53@mybitcoincenter.com>
In-Reply-To: <9D2883DC-360C-401A-B518-B8205A3AAA53@mybitcoincenter.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Tue, 22 Jan 2019 12:03:06 -0800
Message-ID: <CABLeJxT=ne=bP4LrVi=CQhXcSJ64t8FE8vJ=2S_yiVxET-4Xuw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Satoshin <satoshin@mybitcoincenter.com>
Content-Type: multipart/alternative; boundary="000000000000f1e692058011772c"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Wed, 23 Jan 2019 02:00:38 +0000
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
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: Tue, 22 Jan 2019 20:03:21 -0000
--000000000000f1e692058011772c
Content-Type: text/plain; charset="UTF-8"
How could you prove the private key is in the burning transaction?
On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This could could be a viable option. I think this is the right approach.
>
> Any downside to this and how much does this add to the blockweight if
> anything at all.
>
> Anonymouse
>
> > On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Good Morning Matt,
> >
> >> ### ZmnSCPxj,
> >>
> >> I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> > unique for each blockheight but still can be used to create signatures
> or verify?
> >
> > One possibility is to derive `R` using standard hierarchical derivation.
> > Then require that the staking pubkey be revealed to the sidechain
> network as actually being `staking_pubkey = P + hash(P || parent_R) * G`
> (possibly with some trivial protection against Taproot).
> > To sign for a blockheight `h`, you must use your public key `P` and the
> specific `R` we get from hierarchical derivation from `parent_R` and the
> blockheight as index.
> >
> >
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000f1e692058011772c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div><div dir=3D"auto">How could you prove the private key is in the burnin=
g transaction?</div></div><div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr">On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This co=
uld could be a viable option. I think this is the right approach.<br>
<br>
Any downside to this and how much does this add to the blockweight if anyth=
ing at all.<br>
<br>
Anonymouse<br>
<br>
> On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>> wrote:<br>
> <br>
> Good Morning Matt,<br>
> <br>
>> ### ZmnSCPxj,<br>
>> <br>
>> I'm intrigued by this mechanism of using fixed R values to pre=
vent multiple signatures, but how do we derive the R values in a way where =
they are<br>
> unique for each blockheight but still can be used to create signatures=
or verify?<br>
> <br>
> One possibility is to derive `R` using standard hierarchical derivatio=
n.<br>
> Then require that the staking pubkey be revealed to the sidechain netw=
ork as actually being `staking_pubkey =3D P + hash(P || parent_R) * G` (pos=
sibly with some trivial protection against Taproot).<br>
> To sign for a blockheight `h`, you must use your public key `P` and th=
e specific `R` we get from hierarchical derivation from `parent_R` and the =
blockheight as index.<br>
> <br>
> <br>
> <br>
> Regards,<br>
> ZmnSCPxj<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--000000000000f1e692058011772c--
|
