📅 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
Satoshin [ARCHIVE] /
npub1t8…8yvcq
2023-06-07 18:15:59
in reply to nevent1q…yasd
Author Public Key
npub1t8mtmcsvng40065nhp3d2e43esyr3wryrw3m4zqrwev0e0fzdyuq38yvcqSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:15:59Event 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"
}