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
|
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 DAF584864
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 16:33:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com
[209.85.221.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20966102
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 16:33:38 +0000 (UTC)
Received: by mail-wr1-f41.google.com with SMTP id r10so28057165wrs.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 08:33:37 -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=U41BAvxqPVR5t3pwgiQV58WFWjY11zxUql49+AWaNEQ=;
b=NhY9P2z7mcfs3ImESoG/qYDC4ekeagvMs2oftLf57bfqvtsfvctx6T3gFFxVt25nZb
dRhkZTbMMPtbzmhbTEmn0dEWpCuhsin5llhqFeoV+l3C0/9ifBDpG0PydCtHgAQ71/Zp
Foui552naZuK42J/B75+0yqgmYn1krWC124HiDk3FxEWk1zk0iTX9EYeBuiL1Rj1zJ95
kqBtiFvGc3lNehh4oq3S4V8ext1X3jkinF6drjbQH/sPbXMNDwIyCt3SZLVrVIF9QDiz
eKGpFa0E7PaWdc+aM5HRubNoJHV7w/Vl+n/gJulJZkAe4j5xNuh/EduJ91a/AjQVatsI
ozIQ==
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=U41BAvxqPVR5t3pwgiQV58WFWjY11zxUql49+AWaNEQ=;
b=JVknh/xX7myrorE6VdSaBByVCcXtVmN1qg/ZcSgkG7BMNAFczhdzVOBXQctDmUcfvu
HT03THiBOAGFn2kOu4A1YTjA5cU+6vyIxx02CqqxQ/0UHO3WsjHrxHuIc29TVzDeUWJ8
cgxpRUtQUf7iRkqzrC9WrZWVru4zM985GMbSiiDzv0TUVP32N8ghBc2ePPlDB6w1dBxy
NlZp8Zlh8Aly40ISpekzdUHbs7G4Dj9H+nGcf/B9yx363ViYHrCHRrwtHVWTmQ/PgKVR
sU21ArOLFydykHvvmJw22C+z2UsZmez2eojA1Zu8Qw46gLwybCX4axkGqHw6guyJ5KLy
KnyA==
X-Gm-Message-State: AJcUukeNOQi3qDpatLyYUl2CJs58aRAS6giSLnoaoZTtIKgmPHOh6nbS
3+ipYi3H0u4WIMKv4T9ppEUpikwCgxJ4bnn/Zpb0dQ==
X-Google-Smtp-Source: ALg8bN5Cek7Bq1/zSsSyXZQGzRbwBWByFnP6Sd4ekVtHXT+UXOtwFA0L5sLIZYeX1IUW6X3rG2mgke/t9pgMUtgscUQ=
X-Received: by 2002:a5d:6647:: with SMTP id f7mr33481200wrw.225.1548174816209;
Tue, 22 Jan 2019 08:33:36 -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>
In-Reply-To: <wTXHV7W_AXHz5xdhXJVJr2OdSpEOaFh0PBQubFdZv4JyF6SlImszj2QyF9G-_Dem06A3iBWLF3vdgiHC_NlsVqy7DFX5XTphajNnMqiU6r0=@protonmail.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Tue, 22 Jan 2019 08:33:23 -0800
Message-ID: <CABLeJxRmdccf2tVZ4MsdsEj6H9+NnOpp+AeMLZwYh-zTMkWJXw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f875fb05800e8961"
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: Tue, 22 Jan 2019 19:53:57 +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 16:33:39 -0000
--000000000000f875fb05800e8961
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Wouldn=E2=80=99t a revealed private key for time locked funds create a race=
to
spend? I imagine miners who are paying attention would have the advantage
but it would still just be a race.
Would be nice to have the funds destroyed or sent somewhere specific. Like
if somehow the revealed key was actually itself a presigned transaction. Or
perhaps a 32 byte piece of a tx needed to complete it.
On Tue, Jan 22, 2019 at 6:14 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 the=
y
> 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 =3D P + hash(P || parent_R) * G` (possi=
bly
> 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
>
--000000000000f875fb05800e8961
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div><div dir=3D"auto">Wouldn=E2=80=99t a revealed private key for time loc=
ked funds create a race to spend? I imagine miners who are paying attention=
would have the advantage but it would still just be a race.</div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Would be nice to have the funds =
destroyed or sent somewhere specific. Like if somehow the revealed key was =
actually itself a presigned transaction. Or perhaps a 32 byte piece of a tx=
needed to complete it.</div><div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good =
Morning Matt,<br>
<br>
> ### ZmnSCPxj,<br>
><br>
> 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<br>
unique for each blockheight but still can be used to create signatures or v=
erify?<br>
<br>
One possibility is to derive `R` using standard hierarchical derivation.<br=
>
Then require that the staking pubkey be revealed to the sidechain network a=
s actually being `staking_pubkey =3D P + hash(P || parent_R) * G` (possibly=
with some trivial protection against Taproot).<br>
To sign for a blockheight `h`, you must use your public key `P` and the spe=
cific `R` we get from hierarchical derivation from `parent_R` and the block=
height 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"_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>
--000000000000f875fb05800e8961--
|
