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

Dustin Dettmer dustinpaystaxes at gmail.com
Tue Jan 22 16:33:23 UTC 2019


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.

Would be nice to have the funds destroyed or sent somewhere specific. Like
if somehow the revealed key was actually itself a presigned transaction. Or
perhaps a 32 byte piece of a tx needed to complete it.

On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190122/0ef4688e/attachment.html>


More information about the bitcoin-dev mailing list