š
Original date posted:2016-08-10
š Original message:
The method of using a revocation key is compatible with shachain/elkrem so
has log(n) storage; I'll describe what I developed which omits hashing in
the commit script and uses only signature verification. If Laolu has made
a different key revocation scheme I'm not aware, but please do post if so.
The script is:
DUP
[Revocable Pubkey]
CHECKSIG
NOTIF
[Timeout Pubkey]
CHECKSIGVERIFY
[timeout period]
CHECKSEQUENCEVERIFY
ENDIF
This is a little ugly as the less likely checksig (the revocable one)
happens first. Saves space in the script though and we don't pay any more
for a checksig than any other 1 byte opcode.
As an if statement, it ends up being:
if (revocable sig) || (timeout sig && CSV > timeout)
To build the revocable pubkey, Alice takes their elkrem sender hash from
state n, which we'll call EHn. Alice multiples EHn * G, getting a point
EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
pubkey (BP, which is never seen raw) to EPn. The result, (RPub n = BP +
EPn), is the revocable pubkey for state n. At state n+1, Alice sends Bob
EHn. Bob can then compute the private key for Rpub n, as it's just their
commitment private key plus EHn, modulo the order of the curve.
A similar procedure is used for the timeout key; Alice adds a point to
their own timeout key, which seems kindof pointless because they know both
scalars. It obscures the commitment script by making both pubkeys
different each state, as they're all generated from the hash tree. Bob
only needs to keep track of the most recent "elkrem points" and the hash
tree itself.
Hope this is clear and sorry if I'm describing something completely
different than what you're asking about!
-Tadge
ā
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/54c17813/attachment.html>;
Tadge Dryja [ARCHIVE] /
npub1v5ā¦6l74f
2023-06-09 12:46:35
in reply to nevent1qā¦w7cc
Author Public Key
npub1v5856g02zudlkawxh4ut5kc6at8z5evt77lwxeaaudekq4dlfckst6l74fPublished at
2023-06-09 12:46:35Event JSON
{
"id": "b10d51f4eefcc801eec1b1cf15f3bd12c1687724ec1f8967d7959426c5021621",
"pubkey": "650f4d21ea171bfb75c6bd78ba5b1aeace2a658bf7bee367bde3736055bf4e2d",
"created_at": 1686314795,
"kind": 1,
"tags": [
[
"e",
"ccc2d459792b926854b04bc74e6ea324d2314fff88991806647cc195016ae9ae",
"",
"root"
],
[
"e",
"2c19b1f7eae43f406501e29b0f33ebff3e7c1663fbe72d9f6e014edc169f3d20",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2016-08-10\nš Original message:\nThe method of using a revocation key is compatible with shachain/elkrem so\nhas log(n) storage; I'll describe what I developed which omits hashing in\nthe commit script and uses only signature verification. If Laolu has made\na different key revocation scheme I'm not aware, but please do post if so.\n\nThe script is:\n\nDUP\n[Revocable Pubkey]\nCHECKSIG\nNOTIF\n[Timeout Pubkey]\nCHECKSIGVERIFY\n[timeout period]\nCHECKSEQUENCEVERIFY\nENDIF\n\nThis is a little ugly as the less likely checksig (the revocable one)\nhappens first. Saves space in the script though and we don't pay any more\nfor a checksig than any other 1 byte opcode.\n\nAs an if statement, it ends up being:\nif (revocable sig) || (timeout sig \u0026\u0026 CSV \u003e timeout)\n\nTo build the revocable pubkey, Alice takes their elkrem sender hash from\nstate n, which we'll call EHn. Alice multiples EHn * G, getting a point\nEPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment\npubkey (BP, which is never seen raw) to EPn. The result, (RPub n = BP +\nEPn), is the revocable pubkey for state n. At state n+1, Alice sends Bob\nEHn. Bob can then compute the private key for Rpub n, as it's just their\ncommitment private key plus EHn, modulo the order of the curve.\n\nA similar procedure is used for the timeout key; Alice adds a point to\ntheir own timeout key, which seems kindof pointless because they know both\nscalars. It obscures the commitment script by making both pubkeys\ndifferent each state, as they're all generated from the hash tree. Bob\nonly needs to keep track of the most recent \"elkrem points\" and the hash\ntree itself.\n\nHope this is clear and sorry if I'm describing something completely\ndifferent than what you're asking about!\n\n-Tadge\nā\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/54c17813/attachment.html\u003e",
"sig": "a24e6ebd72e3bbcfe2296cc499c184296f4c061d236be5322e1a40c9f39b2798588951f033b49ca823ea1c5122e406fd36e03f4993f6604eb3cf6848b594c955"
}