From joseph at lightning.network  Fri Aug 12 21:28:53 2016
From: joseph at lightning.network (Joseph Poon)
Date: Fri, 12 Aug 2016 14:28:53 -0700
Subject: [Lightning-dev] Blinded channel observation
In-Reply-To: <87eg5uoeij.fsf@rustcorp.com.au>
References: <87a8gmpkde.fsf@rustcorp.com.au>
	<20160809192814.GA22477@lightning.network>
	<877fbpps8s.fsf@rustcorp.com.au>
	<20160809222938.GA25606@lightning.network>
	<CAGt-spocB259Z4PdzD3=LVTC3VpxbFWDk1PL3cWmU71hTqYLWQ@mail.gmail.com>
	<87oa50oqkp.fsf@rustcorp.com.au>
	<CAGt-spqu3=_TaEWrigrbKVY3vHsXw7ZDxA2UCaO1X4xChPUsbw@mail.gmail.com>
	<87inv8nk6f.fsf@rustcorp.com.au>
	<20160811074926.GA9007@lightning.network>
	<87eg5uoeij.fsf@rustcorp.com.au>
Message-ID: <20160812212853.GB29612@lightning.network>

On Fri, Aug 12, 2016 at 12:54:52PM +0930, Rusty Russell wrote:
> Yeah, I do that already.  We give the N+1th hash when we send the
> revocation for N:
> 
>         // Complete the update.
>         message update_revocation {
>           // Hash preimage which revokes old commitment tx.
>           required sha256_hash revocation_preimage = 1;
>           // Revocation hash for my next commit transaction
>           required sha256_hash next_revocation_hash = 2;
>         }

Yeah, the way I described would (optimally over-the-wire) be a tree of
chained preimages *AND* hashes as a part of the tree itself (so the
chain looks like preimage->hash->preimage->hash instead of
preimage->preimage). That way if you're willing to forgo the ability to
have multiple "next revocation hashes" in-flight (by instead having
multiple trees to achieve multiple in-flight), it's possible to only
send the "next revocation hash", which will automatically reveal the
prior "revocation preimage". In other words, the wire message could only
be sending next_revocation_hash. If one were to use pubkey revocations,
then that construction *requires* using privkeys+pubkeys instead of
preimages+hashes, which ups the cost/complexity -- which is why I said
it probably wasn't worth it. 

> Yeah, agreed.  Hash trees are nice and simple, so unless we get a
> signficiant win, let's stick with that?

For sure.

-- 
Joseph Poon