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 4C8E7F24 for ; Thu, 24 Jan 2019 10:03:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 613F4180 for ; Thu, 24 Jan 2019 10:03:36 +0000 (UTC) Date: Thu, 24 Jan 2019 10:03:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1548324212; bh=Jx+EQvN59P5MficRXMc/3DIr5BEBxCwxjBctnlROc/Q=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=NS/PDAhkS6XI3lf8+QiSEE36VysYllOn6JUEyBUJHVUGl1lU6Cu+sjwdcHpPiACdt CEAtsa/v+mnvBDizJ10JE2TUQCOPMEH4ocgUbHmG/6SnsHpU5VgIjLAf2r9y+mQnfY OT8tFpNBPPBrTVrxQoV34EVDP3sjbS5blsa+yfUI= To: Dustin Dettmer From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com> In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Thu, 24 Jan 2019 18:47:50 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 24 Jan 2019 10:03:37 -0000 Good morning Dustin, > Wouldn=E2=80=99t a revealed private key for time locked funds create a ra= ce to spend? I imagine miners who are paying attention would have the advan= tage but it would still just be a race. If Bitcoin had implemented RBF "properly" (i.e. not have the silly "opt-out= " rule) then such races are won by bidding up the fees. A random person wh= o is not the original staker would be willing to pay miners a fee up to the= entire staked amount minus dustlimit satoshis; obviously a staker would be= far less willing to pay up such a fee, so the random person slashing the f= unds would have a major advantage in that race. Thus the race will be won by whoever mines the highest-fee transaction. It still becomes very unlikely that the staker will win unless the staker a= lready has a significant mining hashpower (and if the staker has significan= t hashpower, then the Bitoin layer itself is at peril anyway, never mind si= dechains built on top of it). Regards, ZmnSCPxj > > On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev wrote: > > > Good Morning Matt, > > > > > ### ZmnSCPxj, > > > > > > I'm intrigued by this mechanism of using fixed R values to prevent mu= ltiple signatures, but how do we derive the R values in a way where they ar= e > > 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 netwo= rk as actually being `staking_pubkey =3D P + hash(P || parent_R) * G` (poss= ibly 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 b= lockheight as index. > > > > Regards, > > ZmnSCPxj > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev