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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 274414C38
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 20:27:52 +0000 (UTC)
X-Greylist: delayed 00:05:02 by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A4E8603
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 20:27:51 +0000 (UTC)
Received: from mail-qt1-f174.google.com ([209.85.160.174]) by
mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id
0M2vwG-1h23mo0wBq-00saHZ for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 21:22:48 +0100
Received: by mail-qt1-f174.google.com with SMTP id i7so29135558qtj.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Jan 2019 12:22:47 -0800 (PST)
X-Gm-Message-State: AJcUukfHqQLs8uhUYqsSMySOFtrV3F+UpIwMZoJKcubFtPaCTFx+U8t0
EjyYvARbEsPh9Oa2LpwYqHdtaKsT7KL2XWNZVzg=
X-Google-Smtp-Source: ALg8bN5BsE/jSMqPo3rYZUes10Vco9aBibBwc2fqnqEDBQs2MwxF3cWwUpogTpOwqdCLkXrPG4tSbIbmLSyf32ndiOE=
X-Received: by 2002:ac8:1941:: with SMTP id g1mr31551570qtk.193.1548188567360;
Tue, 22 Jan 2019 12:22:47 -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: Dr Adam Back <adam@cypherspace.org>
Date: Tue, 22 Jan 2019 21:22:36 +0100
X-Gmail-Original-Message-ID: <CALqxMTFC9uEarJ7wA3LcLbpNtWfqrkqbadADgpbeUA7ixVDhcQ@mail.gmail.com>
Message-ID: <CALqxMTFC9uEarJ7wA3LcLbpNtWfqrkqbadADgpbeUA7ixVDhcQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Provags-ID: V03:K1:AkJFfI0hvYMcfu4oa1ocXFvwU4u2Cb2QlGk8BtSjzGi43mlhdjM
069N833a21PseCoPR2F/RLnEOYIpGa99Isnaa37Rybf23JQ+nev853PjGxsHlAHRmSW/nfE
DyTKkk6Pwd8z6jCubMcQKKbJqkBOz+a4fked2xbM8gHRjQyTblN0wQLs/SkVFMbjxCVIZzu
qsqa1D18F/DNpgr6VTiFw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vgoekwKxCUA=:LeOnT1j2/gJDCOPkdfIDEn
4EsHoJr3Y0g7D+CcgSzi83sq3AKyYlyxwF4xSFGG3sA8eK7J5CYMIaTwXxu/iqoLxytgyUpHk
skBIzcnlNXvJP4LjNlAoTfsOh2dpcPhyOIv2yVnI1k9r6n06FJjKPhKI9znbVxpucpxACV5ax
mWZNDNgcmxeM96WQb32megGC+4lkpcDVnk2vKPDlHsdl8sm7/cpznRdSzTglA5CY5QEjxKXbq
UWPCUaLubKhtSRGXY1+9glDg0ihGVZOSKBnXxsebMojPXvpmw371etStLe4pY/m3+XlnUNGB9
rVt5+yXtiVH/QLcFN605XZKmEe8FyJFaA9/IqoTH2908mBpgzAhSputcZqdN73yZ43VjAANIp
MiQCq+gVei1cJhN0StsRIsL3CbVjYdi1UbfBYveiAloONffp0KYc5n316wSvQzY7TgadQbqCm
mwpphslubk22BnN4xVP3rMA2e4ZPf7v0AJLvghniiR2VfRpqdmzve/u8oRdNkyqAEm6QiRD5o
v0byaU/ep2lg7TTG83uNv0+HO5Z4cBVqIGiGdOwvL3/5zMY/nv3aFxAKMD2ACkHLw4NgC+3DF
INSQe0MER3tl7R6ELA+WGlKjK1ukPWiaQBIA/oAaPaClAmhoCFpdQfW3w4TDw2yDMzxSIQhAd
UYq1LJIN9PyLHutkRbWHa6+XER2EvvEMAyed4oEyhEhq7BZ2w5mMpgeCePnU8FuRgBK8FxQOd
on9HlcvTKppIE3Fp4Wj7YIs065dJ925zBHZJF35PeRSjJ0P+VITr/+Ka7Ng=
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
T_HK_NAME_DR 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:27:52 -0000
Brands credentials use this single show, and multiple show
credentials. It's based on the representation problem which is the
generalisation to multiple bases where Schnorr is one base, Pedersen
Commitments are two bases, Representation problem is n>2 bases.
The method used would work for Schnorr or DSA and there was some 2013
era #bitcoin-wizards discussion on this topic, where if you spend
twice miners can take your money, as a strong way to "discourage"
address reuse. One side effect though is you force ACID log oriented
storage on the wallet, and many wallets are low power devices or even
a few in VMs that could be snapshotted or rolled back. Similar risk
model to the lightning penalty for accidentally doing a hostile close
in the current model (where ELTOO has non-penalty based close).
You would have to be careful to not use related nonces (k=nonce
committed to by R=kG), as Schnorr and DSA are highly vulnerable to
that, like simultaneous equation two samples solvable.
What the Brands n-show credential looks like is a precommitment like
single show the address becomes A=H(R,Q) where Q is the public key,
and n-show becomes A=H(R1,...,Rn,Q).
Signing becomes providing i,Ri,Q in the Script to satisfy a
ScriptPubKey that includes the three. You would need to in practice
store the Ri values in a merkle tree probably so that you don't need
to provide n inputs, but log(n) or some other structuring.
Anyway main point being the fragility to related nonces, and cost of
ACID log structured storage levels of reliability in wallets.
Adam
On Tue, 22 Jan 2019 at 15:14, 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
|
