From rusty at rustcorp.com.au  Sat Aug 13 10:30:33 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sat, 13 Aug 2016 20:00:33 +0930
Subject: [Lightning-dev] Blinded channel observation
In-Reply-To: <20160812212034.GA29612@lightning.network>
References: <CAGt-sprhFi39+PbP1A8rkfQRMW78JT=r5AF-UOu+xsf64Q4Mzg@mail.gmail.com>
	<87a8gmpkde.fsf@rustcorp.com.au>
	<20160809192814.GA22477@lightning.network>
	<877fbpps8s.fsf@rustcorp.com.au>
	<20160809222938.GA25606@lightning.network>
	<87wpjpnzwd.fsf@rustcorp.com.au>
	<20160811041626.GA8114@lightning.network>
	<87d1leodg7.fsf@rustcorp.com.au>
	<20160812212034.GA29612@lightning.network>
Message-ID: <87twep3qra.fsf@rustcorp.com.au>

Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> Yeah, interesting thoughts!
>
> On Fri, Aug 12, 2016 at 01:17:52PM +0930, Rusty Russell wrote:
>> I still don't understand why use an HMAC-of-tx instead of just the txid?
>> What does it gain?
>
> I'm presuming you need to index by txid to see if there needs to be a
> penalty transaction broadcast, so you can't use that as a secret key.

But SHA256(txid) would be sufficent, no?

(Unless we're happy with 128 bit keys, then just use the upper bits for
hint and lower bits for key).

So, here's a strawman spec (written in cat > style, so includes bugs):

1) We change the protocol slightly to use shachain/elkrem with an
   additional SHA256() to get the preimage.  On-wire we reveal the leaf
   node, which you SHA256() to get the preimage.  This makes commit
   N-1 unguessable even if you know commit N.

2) Format of message-to-watcher is:
   [8-byte-txid-prefix-hint]
   [chacha20poly1305 blob, key is SHA256(txid):
    [txid-of-previous-commit-or-zero]
    [bitcoin signature]
    [revocation preimage]
    [htlc #1 H-hash ripemd160]
    [htlc #1 expiry]
    [htlc #2 H-hash ripemd160]
    [htlc #2 expiry]
    ...
    [arbitrary zero padding]
   ]

3) Implementations should pad this out to some reasonable amount to
   cover expected HTLCs and avoid revealing too much using size.
   Handwave.

4) Implementations should set the txid-of-previous-commit field
   sparingly: it saves space for HTLCs which are in multiple commits,
   but leaks information.  Handwave.

5) Initially watcher would be given commit and timeout keys for both
   sides (which I'm assuming are static).

6) Upon seeing a txid prefix match, watcher tries to decrypt.  If
   success, decrypts previous message-to-watchers as possible using
   txid-of-previous-commit-or-zero fields and walking back.  Accumulates
   all the HTLCs, calculates the wscripts for them, sees which match
   outputs.  Also look for the one the cheater paid to-self.  Generates
   transaction that spends all the outputs it can match, checks [bitcoin
   signature] is valid, sends tx.

What have I missed?
Rusty.