Dustin Dettmer [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-22 📝 Original message:Wouldn’t a revealed ...
đź“… Original date posted:2019-01-22
📝 Original message: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>
📝 Original message: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>