📅 Original date posted:2019-01-22 📝 Original message:This could could be a ...

Satoshin [ARCHIVE] /

npub1t8m…yvcq

2023-06-07 18:15:59

in reply to nevent1q…yasd

📅 Original date posted:2019-01-22
📝 Original message: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

Author Public Key

npub1t8mtmcsvng40065nhp3d2e43esyr3wryrw3m4zqrwev0e0fzdyuq38yvcq

Show more details

Published at

2023-06-07 18:15:59

Kind type

1 Short Text Note

Event JSON

{ "id": "aad4d47a20b40591517454ffe3ba413a195a254b28cb9aa3f8f31334fa574798", "pubkey": "59f6bde20c9a2af7ea93b862d566b1cc0838b8641ba3ba88037658fcbd226938", "created_at": 1686161759, "kind": 1, "tags": [ [ "e", "4df79c01c3ed2b69e2412feaaaf51b7a98cb72fa692aaad7d28519466f8f3082", "", "root" ], [ "e", "098f7cbadb56cfd480368382b53fd0d7de8dff7f2d72d026ea4be4fe1aa06cd4", "", "reply" ], [ "p", "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861" ] ], "content": "📅 Original date posted:2019-01-22\n📝 Original message:This could could be a viable option. I think this is the right approach.\n\nAny downside to this and how much does this add to the blockweight if anything at all.\n\nAnonymouse\n\n\u003e On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Good Morning Matt,\n\u003e \n\u003e\u003e ### ZmnSCPxj,\n\u003e\u003e \n\u003e\u003e 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\n\u003e unique for each blockheight but still can be used to create signatures or verify?\n\u003e \n\u003e One possibility is to derive `R` using standard hierarchical derivation.\n\u003e 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).\n\u003e 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.\n\u003e \n\u003e \n\u003e \n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev", "sig": "3771e2f3cb477687d98df010ee4ff4ba0aacb021c011cfdbe9de76f879bee19904bd42377679ce2864096384d611810b336c2834a8cc30842fa082113d0b92a7" }