Dustin Dettmer [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-22 📝 Original message:How could you prove the ...

📅 Original date posted:2019-01-22
📝 Original message:How could you prove the private key is in the burning transaction?

On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> This could could be a viable option. I think this is the right approach.
>
> Any downside to this and how much does this add to the blockweight if
> anything at all.
>
> Anonymouse
>
> > On Jan 22, 2019, at 4:19 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
>
> _______________________________________________
> 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/46b08c8b/attachment-0001.html>;