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