Tadge Dryja [ARCHIVE] on Nostr: š Original date posted:2016-08-10 š Original message: The method of using a ...
š
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>;
š 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>;