[Lightning-dev] Blinded channel observation

[Rusty Russell]

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.