Good morning Conner,
> > > > > From my bare knowledge of go, it seems data structures and messages so > > > far, > > > without actual logic, but please inform me if I am incorrect. > > > > Much of the server side has been implemented, which accepts encrypted blobs > > from > > watchtower clients and stores them. The functionality related to scanning > > blocks > > and publishing justice txns has also been implemented, but has not been > > merged > > yet. The big remaining task is to integrate the client such that it properly > > backs up states after receiving revocations from the remote peer. Is the server in a different repo from lnd? I suppose I should look at non-c-lightning repos more often. > > > > > Note however that watchtowers would require to keep all encrypted blobs > > > that > > > are keyed to the same partial txid. I.e. watchtowers need to store the > > > pair > > > in a set with the set looking at the entire txid+blob as the identity of > > > the > > > object. Otherwise it would be possible, if your watchtower is identified > > > by > > > your counterparty, for the counterparty to give the commitment > > > transaction's > > > txid with a randomly-generated blob to your watchtower before it gives the > > > revocation key to you. > > > I have described the above problem before here: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html > > > with an unsatisfactory solution. > > > > Indeed, this was great observation! The tower can't be sure which client is > > uploading the "real" blob either. In light of that, the chosen design uses a > > two level bucketing structure that maps: > > <txid[:16]> -> client_pubkey1 : encrypted_blob1 > > -> client_pubkey2 : encrypted_blob2 > > ensuring that different client's can't overwrite each other. Further, the > > tower > > will only store one blob for a given txid per client. Upon decryption, the > > tower > > would learn that only one of this a valid update (and possibly delete state > > for > > the offender). > > > > > However, this remains your counterparty best avenue of attack, is to > > > simply > > > spam your watchtower until it runs out of resources and crashes. > > > > The client pubkeys described above are tied to what we've been referring to > > as a > > session. In order for a client to facilitate the attack described above, > > they > > would have to pay the tower for multiple sessions tied to different > > ephemeral > > session keys. > > A session grants the client the ability to store up to N blobs, where N > > would be > > several thousand. Thus, the cost to perform the attack would be many orders > > of > > magnitude greater than the cost to back up one channel. In the private tower > > case, there isn't necessarily payment, though it's more or less assumed > > that one > > wouldn't DOS their own tower. > > In practice, the tower should only ever accept sessions if it can be > > certain it > > has the appropriate disk-space to facilitate them, so I don't think > > there is much > > risk in the node crashing due to this. Someone could still pay to fill > > up my tower, > > but the tower would be compensated appropriately. The tower could also raise > > it's price point if it detects such behavior. I understand. It seems similar to "ticket" system I proposed in that post also. Somebody (not in summit, it was some paper whose author I forgot, and whose title I also forgot...) gave a good idea of combining paying the watchtower with checking if the watchtower is actually working. Basically, we simulate a breach, which releases some money to the watchtower. If the watchtower correctly fixes the breach, then it gets paid. If not, we retain our money and can find another watchtower. However, it seems not so compatible with session system...? You have to pay to get a session key first, and this cannot be recovered if the watchtower turns out to not actually monitor breaches. (I suppose the session keys could be low cost, since they are effectively just spam prevention, and watchtowers could charge larger for breach recovery, in which case it may be sensible to have both.) > > > > > And if the watchtower identifies the user, then this leaks the privacy of > > > the > > > user to the watchtower, and what would then be the point of encrypted > > > blob? > > > > I believe the same session-based, encrypted-blob approach would work eltoo > > towers as well, if the concern is primarily about the channel partner > > presuming > > the valid blob. The general design should be readily able to serve > > eltoo clients, > > with some slight modifications to breach detection and justice txn > > construction. > > My greater concern with the update-and-replace model is that it leaks timing > > information about a particular channel to the tower, since the tower must > > know > > which prior state needs replacing. So even though it is possible to make > > eltoo > > towers constant-space per channel, IMO we're better off storing all prior > > encrypted blobs to maintain adequate privacy. On private towers, perhaps > > this > > privacy/space tradeoff may acceptable, but not sure if the tradeoff makes > > sense > > on public towers. Indeed, replacement here implies that the watchtower can track channels. With sessions but not replacement, the watchtower knows a single session belongs to a single node, but does not know how many channels the node has. However, if so, what txid will eltoo watchtowers watch for? The trigger transaction will have fixed txid, but is constant for the entire channel lifetime (and thus leaks which channel is being watched). The update transactions will vary their txid because fees are paid by adding more inputs. An idea I had before was that the result of sighash function would be the key instead of the txid, since under `SIGHASH_NOINPUT` the same result of the sighash function will be used regardless of additional inputs/outputs/fees on update transactions. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
