Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 74B0A487F for ; 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 ; Tue, 22 Jan 2019 20:03:20 +0000 (UTC) Received: by mail-wm1-f50.google.com with SMTP id a62so15462752wmh.4 for ; 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: <9D2883DC-360C-401A-B518-B8205A3AAA53@mybitcoincenter.com> In-Reply-To: <9D2883DC-360C-401A-B518-B8205A3AAA53@mybitcoincenter.com> From: Dustin Dettmer Date: Tue, 22 Jan 2019 12:03:06 -0800 Message-ID: To: Bitcoin Protocol Discussion , Satoshin 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
How could you prove the private key is in the burnin= g transaction?

On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
This co= uld 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 anyth= ing 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 pre= vent 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 derivatio= n.
> 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).
> 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.
>
>
>
> 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/mail= man/listinfo/bitcoin-dev
--000000000000f1e692058011772c--