Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-10 📝 Original message: Tadge Dryja <tadge at ...

📅 Original date posted:2016-08-10
📝 Original message:
Tadge Dryja <tadge at lightning.network> writes:
> 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.

Oh, I blamed Laolu because he told me about it; sorry for misattribution.

> The script is:
>
> DUP
> [Revocable Pubkey]
> CHECKSIG
> NOTIF
> [Timeout Pubkey]
> CHECKSIGVERIFY
> [timeout period]
> CHECKSEQUENCEVERIFY
> ENDIF

OK, so far so good.

> 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.

"never seen raw on-chain" I assume, since Bob will send it to Alice in
setup?

> 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.

So, AFACIT this scheme gives us a slightly smaller script and makes
previous commit transactions underivable.

The property I was *hoping* for was the ability for Alice (and Bob) to
independently predict each others' future revocation hashes/pubkeys.
That would neatly allow an arbitrary number of commitment transactions
in flight each way at once. Naively, seems like that should be
possible.

> 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.

I think changing the timeout key is harmless, but gratuitous; changing
the revocation key is sufficient for each commitment script unguessably
different from the last one, no?

> Hope this is clear and sorry if I'm describing something completely
> different than what you're asking about!

It's all good; this is a big space and sometimes I don't even know what
I don't know...

Thanks!
Rusty.