Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-10 📝 Original message: Tadge Dryja <tadge at ...

📅 Original date posted:2016-08-10
📝 Original message:
Tadge Dryja <tadge at lightning.network> 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,