[Lightning-dev] Blinded channel observation

Rusty Russell rusty at rustcorp.com.au
Tue Aug 9 05:43:57 UTC 2016


Tadge Dryja <tadge at lightning.network> writes:
> Blinded outsourcing of channel monitoring

But if we don't steal HTLCs, the lack of channel utilization is a pain:

> States with in-flight HTLCs are another issue... if you want to keep the
> data storage down, you can just not include them, and make a policy that
> the sum of all the HTLCs should be less than either non-HTLC balance in the
> channel.  That way the attacker still loses money if they try to attack.
> They potentially might not lose all of it though.  You could make it
> variable size and include HTLCs as well but that increases the data rate
> significantly and probably hurts anonymity in various ways.

But now they must *always* keep their balance greater than all the HTLCs
they ever previously received at once, otherwise it's worth them
cheating.

I think we really do want to capture those HTLCs, but I don't think it's
as bad as you think: an HTLC can be described in ~40 bytes.  We need to
do some magic to pad it out to hide the number of HTLCs, of course.

So, my method was less ambitious.  I'll describe it here:

We send the observer the "steal" tx every update (not really: we only
need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
This gets encrypted+HMAC with the txid of the commit tx (or, if that's
too guessable, the SHA256() of our signature on the commit tx).

I had assumed we'd tell the observer our channel funding txid: when it
sees that spent, it tries to use those signatures to decrypt all the txs
we sent.  If one succeeds, it spends it.

If we want to obscure our funding tx, we can simply use a txid qualifier
the same way you did (and maybe use the sha256(txid) as the encryption
key to avoid weakening that).

Whatever we do, we might want to offer our own peers to do that watching
for them (for a fee?).

Cheers!
Rusty.


More information about the Lightning-dev mailing list