From rusty at rustcorp.com.au Wed Aug 10 10:39:50 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 10 Aug 2016 20:09:50 +0930 Subject: [Lightning-dev] Blinded channel observation In-Reply-To: References: <87a8gmpkde.fsf@rustcorp.com.au> <20160809192814.GA22477@lightning.network> <877fbpps8s.fsf@rustcorp.com.au> <20160809222938.GA25606@lightning.network> Message-ID: <87oa50oqkp.fsf@rustcorp.com.au> Tadge Dryja writes: >> >> 4. When the watcher receives a new block, they HMAC(txid+salt1) all >> transactions and compare against the key-value store >> >> This method does not require significant computation upon receiving a >> new block and checking against the datastore. I forgot to note, that the > > If you're only watching 1 channel, this is OK as you're just doing one HMAC > operation per incoming tx. This works when the number of states per > channel is high but the number of channels watched is low. > If you're watching 1M channels with 1K states each, this requires 1M HMAC > operations for every incoming tx. > > By giving the whole (or a truncated part) of the txid, the observing node > can put all txids being watched for into the same tree and have seek access > time independent of the number of separate channels being watched. Whether > it's 1 channel with 1 billion states, or 100M channels with 10 states each, > you have the same cpu and I/O cost per incoming tx. Yes, I think I agree. > I'm not clear on the advantages of sending encrypted state information to > the observer. Most information the observer needs to construct a punishing > transaction is available in the observed commitment tx; the only per-state > information which needs to be stored is the signature (and in the case of > HTLCs, the preimage). Yes. To be precise, watcher needs preimage, pubkeys, a signature, OP_CSV delay amounts for each side, and HTLCs. If the pubkeys and OP_CSV delay amounts are fixed, you need a signature and preimage (required to steal the to-them output as well as htlcs) every new commit tx (ie. every new watch request). And you'll add a new HTLC information on average every second commit tx. But I think you're better attaching every relevant HTLC to every watch request; otherwise, you're exposing all previous HTLCs. I recalculated: they're only 24 bytes each (ripemd hash + expiry). If we really want to optimize that,maybe we can come up with a cleverer scheme, where you optionally include the key to the previous watch request with the encrypted information, allowing the sender to control the privacy/data tradeoff? Then the watcher would gather HTLCs from those previous requests as well, and see which ones are required? {Insert bikeshed here}. {No, here}. > Reconstructing messages from hashes and / or > signatures isn't possible as long as there's sufficient unknown data in the > preimage or message. This is achievable by changing the pubkeys used in > the commit tx script and pubkey hash each state, without needing additional > data in an OP_RETURN. FWIW, I take back the idea about using the signature as a key: 1) While the crypto people tell me it's probably OK, they can't prove it. 2) If we go to Schnorr, I think it falls apart as both sigs are combined. OTOH, changing pubkeys every step isn't required if we go for Laolu's key-revocation scheme instead of shachain/elkrem. I think? (Roasbeef, this is your cue to describe it in detail!) Cheers, Rusty,