Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4D73BC50 for ; Thu, 24 Jan 2019 18:46:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56F867C for ; Thu, 24 Jan 2019 18:46:24 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id n32so7795745qte.11 for ; Thu, 24 Jan 2019 10:46:24 -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=guyJbR/Vyv5562krnXrrRJCRDAu+tZOhJtMlLWjCu1A=; b=B+/qzV20Hc722Ctrt8SOf3P6HXp4SFr/H31czXW1HoarOrZuSP83BBbF7qun3ur4DJ uAiuUtf4mvFn0DSsCk9idAEG6ov3M2r20qKqFq5qSBdJ/S0nL4IagvVn7oLqXMJ/aml7 3xcZVhCPx5VF4gLpyA7A4WKNdfzrj+6mXTQqWTfm5BNrjPEQjl00OuZvok7vekQ4FJ8z WM0CGRM6S2ZMutZoneVDm74nGBvnI3SgL4V4WdnW6mUpbFLfuKes6SM9zNrEwf1BTRBl uiTrJOpgDtxbt6bEz2vitUkxRL1O1N7y/wusiLuwsKu1wcAQ2iYKDz14KlEe6g/Z/oWn gedA== 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=guyJbR/Vyv5562krnXrrRJCRDAu+tZOhJtMlLWjCu1A=; b=rhywYHlnG2F4+SKBSCipUAKUB0diBnlKXqdU/EX99YOhcOVPjHdYAiIB4rANvQX2UN RohqFnnqySEKru3nd+bmMrrrcZ/1BmoWCjS5tp0jN8xbEVaWz5A1lZCLUHY4HvgI6z/W QjpTpjW77WhUnnpLcJQUOraEOUvo3VbpQ540gH1Y9nA+J97rm0haSUokd++4uI+dVexT erP0r7zzR+pfsJE8dfRa2QHBvDqxcW6UjoflQn9CLUfyyTUylqxD0/xrJhA1scFHuMLn HdLTqV9GFNCKhjRpahH5eveS1eawMhXoYNFySx2t6v6zfBcqzBoeRfKhWh3ucx89SDBw bmXQ== X-Gm-Message-State: AJcUukeQE0LegDW7PBpNd7Ahzblr5xka/jlemMu7TEHaoIn51vI8DUFm LwYSdd47g1+Y4C3aJo7vZFg4QSv01+NH4SixZPQ= X-Google-Smtp-Source: ALg8bN505G2V9pN5Jc9mO99nwsiay2vMg7XHTIY/sbxio0JyQJxOFDOC/Wmw5Xf95mSi03D+4Zg+plwGgJ2s7ebMO8g= X-Received: by 2002:ac8:f2a:: with SMTP id e39mr8083097qtk.262.1548355583151; Thu, 24 Jan 2019 10:46:23 -0800 (PST) MIME-Version: 1.0 References: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com> In-Reply-To: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com> From: Matt Bell Date: Thu, 24 Jan 2019 10:46:11 -0800 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000008511f0058038a08c" 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: Thu, 24 Jan 2019 18:47:51 +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 18:46:26 -0000 --0000000000008511f0058038a08c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems that miners would always claim the stake for themselves, why not since the private key is public knowledge anyway? This is a nice security property since it wouldn't make economical sense for a miner to take a bribe from an attacker since it would have to be less than the stake amount= . It still becomes very unlikely that the staker will win unless the staker > already has a significant mining hashpower (and if the staker has > significant hashpower, then the Bitoin layer itself is at peril anyway, > never mind sidechains built on top of it). Since the likelihood of a successful attack is proportional to the attacker's share of the Bitcoin hashrate, the sidechain's integrity essentially has the same security level as the Bitcoin main chain. Although, the Bitcoin which was moved to the sidechain is susceptible to being stolen if 67% of the stakers collude, which does makes storing funds on it weaker to some degree. On Thu, Jan 24, 2019 at 2:03 AM ZmnSCPxj wrote: > Good morning Dustin, > > > 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. > > 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 who is not the original staker would be willing to pay miners a fe= e > up to the entire staked amount minus dustlimit satoshis; obviously a stak= er > would be far less willing to pay up such a fee, so the random person > slashing the funds 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 > already has a significant mining hashpower (and if the staker has > significant hashpower, then the Bitoin layer itself is at peril anyway, > never mind sidechains built on top of it). > > Regards, > ZmnSCPxj > > > > > 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 signature= s > 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= ` > (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 > > > --0000000000008511f0058038a08c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems that miners would always claim t= he stake for themselves, why not since the private key is public knowledge = anyway? This is a nice security property since it wouldn't make economi= cal sense for a miner to take a bribe from an attacker since it would have = to be less than the stake amount.

It still becomes very unlikely that the staker will win un= less the staker already has a significant mining hashpower (and if the stak= er has significant hashpower, then the Bitoin layer itself is at peril anyw= ay, never mind sidechains built on top of it).

<= /div>
Since the likelihood of a successful attack is proportional to th= e attacker's share of the Bitcoin hashrate, the sidechain's integri= ty essentially has the same security level as the Bitcoin main chain. Altho= ugh, the Bitcoin which was moved to the sidechain is susceptible to being s= tolen if 67% of the stakers collude, which does makes storing funds on it w= eaker to some degree.

On Thu, Jan 24, 2019 at 2:03 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wro= te:
Good morning= Dustin,

> 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 ad= vantage but it would still just be a race.

If Bitcoin had implemented RBF "properly" (i.e. not have the sill= y "opt-out" rule) then such races are won by bidding up the fees.= =C2=A0 A random person who is not the original staker would be willing to p= ay miners a fee up to the entire staked amount minus dustlimit satoshis; ob= viously a staker would be far less willing to pay up such a fee, so the ran= dom person slashing the funds 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 <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 signa= tures or verify?
> >
> > One possibility is to derive `R` using standard hierarchical deri= vation.
> > Then require that the staking pubkey be revealed to the sidechain= network as actually being `staking_pubkey =3D 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` a= nd 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.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev


--0000000000008511f0058038a08c--