From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 274414C38 for ; 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 ; 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 ; Tue, 22 Jan 2019 21:22:48 +0100 Received: by mail-qt1-f174.google.com with SMTP id i7so29135558qtj.10 for ; 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: In-Reply-To: From: Dr Adam Back Date: Tue, 22 Jan 2019 21:22:36 +0100 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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