Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

From: Matt Bell <mappum@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
Date: Thu, 24 Jan 2019 10:46:11 -0800	[thread overview]
Message-ID: <CACV3+OX-mx6eLMOvk5eh6nKGmS_6ZHR=G76LCCCkiPugB9NgRg@mail.gmail.com> (raw)
In-Reply-To: <8u0ExA_vvhRGzmFmxUoyqk6IBrnUEtEHAEMKzqLWLxC6IgBtvZR24jZBgeMeJlsPcjJKYgVar_rC388ZNjP09ZUkukfP1KRcL9NMDkrVrQM=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

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 <ZmnSCPxj@protonmail•com> wrote:

> Good morning Dustin,
>
> > Wouldn’t 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 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 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 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 4126 bytes --]