Re: [Lightning-dev] Wumbological local AND global features
I realized the other day that the wumbo bit should also likely encompass wumbo payments. What good is a wumbo channel that doesn't also allow wumbo payments? Naturally if the bit is signalled globally, then this should also signal the willingness of the node to forward larger payments up to their max_htlc limit within the channel_update for that link. On a similar note, I was reviewing the newer-ish section of the spec concerning the optional max_htlc value. I noticed an inconsistency: it states the value should be below the max capacity of the channel, but makes no reference to the current (pre wumbo) _max HTLC limit_. As a result, as it reads now, one may interpret signalling of the optional field as eligibility to route wumbo payments in a pre-wumbo channel world. -- Laolu On Tue, Nov 13, 2018 at 3:34 PM Rusty Russell wrote: > ZmnSCPxj via Lightning-dev > writes: > > Thus, I propose: > > > > * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that > the node is willing to wumbo with its counterparty in the connection. > > * The global feature bit `option_anyone_can_wumbo`, which indicates that > the node is willing to wumbo with any node. > > I think we need to name `option_anyone_can_wumbo` to `option_wumborama`? > > Otherwise, this looks excellent. > > Thanks, > Rusty. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Packet switching via intermediary rendezvous node
> If I'm not mistaken it'll not be possible for us to have spontaneous > ephemeral key switches while forwarding a payment If this _was_ possible, then it seems that it would allow nodes to create unbounded path lengths (looks to other nodes as a normal packet), possibly by controlling multiple nodes in a route, thereby sidestepping the 20 hop limit all together. This would be undesirable many reasons, the most dire of which being the ability to further amplify null-routing attacks. -- Laolu On Mon, Nov 12, 2018 at 8:06 PM Christian Decker wrote: > Hi ZmnSCPxj, > > like I mentioned in the other mailing thread we have a minor > complication in order get rendez-vous working. > > If I'm not mistaken it'll not be possible for us to have spontaneous > ephemeral key switches while forwarding a payment. Specifically either > the sender or the recipient have to know the switchover points in their > respective parts of the onion. Otherwise it'll not be possible to cover > the padding in the HMAC, for the same reason that we couldn't meet up > with the same ephemeral key at the rendez-vous point. > > Sorry about not noticing this before. > > Cheers, > Christian > > ZmnSCPxj via Lightning-dev > writes: > > Good morning list, > > > > Although, packet switching was part of the agenda, we decided, that we > would defer this to some later version of BOLT spec. > > > > Interestingly, some sort of packet switching becomes possible, due to > the below features we did not defer: > > > > 1. Multi-hop onion packets (i.e. s/realm/packettype/) > > 2. Identify "next" by node-id instead of short-channel-id (actually, we > solved this by "short-channel-id is not binding" and next hop is identified > by short-channel-id still). > > 3. Onion ephemeral key switching (required by rendez-vous routing). > > > > --- > > > > Suppose we define the below packettype (notice below type number is > even, but I am uncertain how "is OK to be odd", is appropriate for this): > > > > packettype 0: same as current realm 0 > > packettype 2: ephemeral key switch (use ephemeral key in succeeding > 65-byte packet) > > packettype 4: identify next node by node-id on succeeding 65-byte packet > > > > Suppose I were to receive a packettype 0 in an onion. It identifies a > short-channel-id. Now suppose this particular channel has no capacity. As > I showed in thread " Link-level payment splitting via intermediary > rendezvous nodes" > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001547.html, > it is possible, that I can route it via some other route *composed of > multiple channels*, by using packettype 4 at the end of this route to > connect it to the rest of the onion I receive. > > > > However, in this case, in effect, the short-channel-id simply identifies > the "next" node along this route. > > > > Suppose we also identify a new packettype (packettype 4)) where he > "next" node is identified by its node-id. > > > > Let us make the below scenarios. > > > > 1. Suppose the node-id so identified, I have a channel with this node. > And suppose this channel has capacity. I can send the payment directly to > that node. This is no different from today. > > 2. Suppose the node-id so identified, I have a channel with this node. > But this channel has not capacity. However, I can look for alternate > route. And by using rendez-vous feature "switch ephemeral key" I can > generate a route that is multiple hops, in order to reach the identified > node-id, and connect the rest of the onion to this. This case is same as > if the node is identified by short-channel-id. > > 3. Suppose the node-id so identified, I have not a channel with this > node. However, I can again look for alternate route. Again, by using > "switch ephemeral key" feature, I can generate a route that is multiple > hops, in order to reach the identified node-id, and again connect the rest > of the onion to this. > > > > Now, the case 3 above, can build up packet switching. I might have a > routemap that contains the destination node-id and have an accurate route > through the network, and identify the path directly to the next node. If > not, I could guess/use statistics that one of my peers is likely to know > how to route to that node, and also forward a packettype 4 to the same > node-id to my peer. > > > > This particular packet switching, also allows some uncertainty about the > destination. For instance, even if I wish to pay CJP, actually I make an > onion with packettype 4 Rene, packettype 4 CJP. packettype 0 HMAC=0. Then > I send the above onion (appropriately layered-encrypted) to my direct peer > cdecker, who attempts to make an effort to route to Rene. When Rene > receives it, it sees packettype 4 CJP, and then makes an effort to route to > CJP, who sees packettype 0 HMAC=0 meaning CJP is the recipient. > > > > Further, this is yet another use of the siwtch-ephemeral-key packettype. > > > > Thus: > > > > 1. It allows packet
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
Good morning Rusty, > > > I apologize that this wasn't fleshed out before the summit, but I > > > overestimated the power of Scriptless Scripts so had mentally deferred > > > this. > > > > My understanding is that SS is as powerful as we thought, at least for some > > of the applications we were hoping to use it for. > > However, implementing SS is hard without Schnorr, because script magic with > > `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe > > wait for Schnorr instead". > > No, we don't get static invoices. That was my hope; that we could do > static invoicing without an extra interaction. At first I thought it was possible, but on reflection, you are correct. We need some way for the payee to dynamically provide a new payment hash (or payment point under SS). This is because our proof-of-payment essentially means the payer learns a secret. So we cannot commit to a fixed secret if we want the static invoice to be shareable among multiple payers. So the payee does need to generate new secrets each time it wants to be paid, and give a unique secret to the payer as separate unique proofs-of-payment. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
I'm not sure this is an improvement at all over just allowing a single merge-point, i.e., the destination. You see as long as we don't attempt intermediate merges the routes are independent and failures of one HTLC do not impact any other parts. Take for example the network below: /\ AB-C-D \ / ---E--- For simplicity let's assume unit capacities on all channels except C-D and a total payment of 2 from A to D. If we use C as a merge point for the two partial payments A-C-D and A-B-C-D, then C can only forward if both partial payment succeed, i.e., if for example A-C fails then we'll need to tear down the HTLCs for both paths because it'll no longer be possible to find an alternative route to fulfill the forwarding of 2 over C-D. If however we have two independent routes A-B-C-D and A-C-D, then A-C-D can fail independently and we can recover by attempting A-E-D, no need to touch A-B-C-D at all. Overall it seems we get very little benefit (we save some HTLC setups and teardown) for a lot of added complexity. In the above case we would have saved on a single C-D HTLC, and the cost of doing so is many times larger (2 HTLCs needed to be torn down because we could no longer pass enough capacity to C in order for it to reach the forward threshold). Let's please stick with the simple mechanism of having the recipient be the only merge point. Cheers, Christian ZmnSCPxj via Lightning-dev writes: > Good morning list, > > I propose the below to support Base AMP. > > The below would allow arbitrary merges of paths, but not arbitrary splits. I > am uncertain about the safety of arbitrary splits. > > ### The `multipath_merge_per_hop` type (`option_base_amp`) > > This indicates that payment has been split by the sender using Base AMP, and > that the receiver should wait for the total intended payment before > forwarding or claiming the payment. > In case the receiving node is not the last node in the path, then succeeding > hops MUST be the same across all splits. > > 1. type: 1 (`termination_per_hop`) > 2. data: > * [`8` : `short_channel_id`] > * [`8` : `amt_to_forward`] > * [`4` : `outgoing_cltv_value`] > * [`8` : `intended_total_payment`] > * [`4` : `zeros`] > > The contents of this hop will be the same across all paths of the Base AMP. > The `payment_hash` of the incoming HTLCs will also be the same across all > paths of the Base AMP. > > `intended_total_payment` is the total amount of money that this node should > expect to receive in all incoming paths to the same `payment_hash`. > > This may be the last hop of a payment onion, in which case the `HMAC` for > this hop will be `0` (the same rule as for `per_hop_type` 0). > > The receiver: > > * MUST impose a reasonable timeout for waiting to receive all component > paths, and fail all incoming HTLC offers for the `payment_hash` if they have > not totalled equal to `intended_total_payment`. > * MUST NOT forward (if an intermediate node) or claim (if the final node) > unless it has received a total greater or equal to `intended_total_payment` > in all incoming HTLCs for the same `payment_hash`. > > The sender: > > * MUST use the same `payment_hash` for all paths of a single multipath > payment. > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] type,len,value standard
Conner Fromknecht writes: > Hi ZmnSCPxj, > > Thanks for writing this up! I had started an email, but you beat me to it :) > >> 1. For a sequence of `type,len,value`, each `type` must be unique. -- >> accepted. > > To add to this, it seemed that there was some agreement that repeated fields > should be serialized under a single root key, since a receiver can't know if a > field is allowed to have duplicates if they don't understand the field. If a receiver doesn't understand it, it doesn't have to enforce any rules on it *at all*. So it depends on individual cases. >> For a sequence of `type,len,value`, the `type`s must be in ascending order >> -- not explicitly accepted or rejected. It would be easier to check >> uniqueness > (the previous rule we accepted) here for a naive parser (keep >> track of some "minimum allowed type" that initializes at zero, check current >> type >= this, update to current type + 1) if `type`s are in ascending order. > > Yep ascending makes sense to me, for the reasons you stated. Again, writer MUST, with no constraint on reader. >> 1, `type` - one byte or two? > > I'd lean towards one, if a message has 256 optional fields, it might be time > to > consider a new message type altogether. Exactly. >> 3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is >> not known is found, crash and burn. But intent of this system is for future >> expansion for optional fields, so...? > > Perhaps this depends on context: > - for gossip messages, I think the primary concern is not breaking signature > validation, and that these would need to remain optional for backwards > compatibility. Yes, "not OK" is message dependent. It doesn't break parsing (if you want that, use a new message type), but it does break *usage*; "you can't use this information". TLV makes sense when there are many many options, at cost of a couple of bytes per option. We agreed to consider it for new additions, but sometimes a simple option bitmap will be a win. > - for link-level messages, we have a little more control. I imagined the > fields >would be gated by feature bit negotiation, and deviating from >unsupported/required would result in being disconnected. It's nice if you can simplify your code by always sending it, even if the remote doesn't understand it. >> 5. `len` - one byte or two? I believe we tend to use two bytes for various >> lengths. > > Maybe varint? One byte is not enough for all lengths, but two seems excessive > for uint8 or even uint32. Yes, it's a nice compromise IMHO. >> 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other >> messages and so on simply refer to. > > Indeed, are you thinking we'd use this to add new fields proposed in 1.1? Well, it's a very individual message thing. We would specify it in general, then each place where it's used (eg. gossip) would have their own types. > In addition to the above, do we also want to flesh out what sub-TLV structures > would look like? Or perhaps that isn't necessary, if we can continue adding > more > root-level keys. I think that the general TLV definition just belongs in BOLT #1, since it's so short. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.
ZmnSCPxj writes: >> I apologize that this wasn't fleshed out before the summit, but I >> overestimated the power of Scriptless Scripts so had mentally deferred >> this. > > My understanding is that SS *is* as powerful as we thought, at least for some > of the applications we were hoping to use it for. > However, implementing SS is hard without Schnorr, because script magic with > `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe > wait for Schnorr instead". No, we don't get static invoices. That was my hope; that we could do static invoicing without an extra interaction. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] type,len,value standard
Hi ZmnSCPxj, Precisely, something like that is what I had in mind. Since the max message size is 65KB, one option could be to only allow the varint to be max 2 bytes where: - if the 8th bit is not set, the lowest 7 bits of the first bytes translate to 0 - 127 - if the 8th bit is set, this implies that the second byte is also treated as part of the length, and the total value is 0x7f & first byte + second byte << 7 This would be fairly straightforward to implement, at the cost of limiting a particular field to 2^15 bytes. I wonder, is this too restrictive? At the same time, we could offer a varint that could extend up to the three bytes. The third byte would only come in to play if the length of the field is greater than 2^14 - 1. The argument could be made that for values of this size, one extra byte is irrelevant compared to the size of these larger fields. Cheers, Conner On Thu, Nov 15, 2018 at 1:45 AM ZmnSCPxj wrote: > > Good morning Conner et al, > > > > > 5. `len` - one byte or two? I believe we tend to use two bytes for > > > > various > > > > lengths. > > > > > > > > > > Maybe varint? One byte is not enough for all lengths, but two seems > > > excessive > > > for uint8 or even uint32. > > > > Given that messages are currently only up to 65536 bytes total, is that not > > a bit much? > > Sorry, I misunderstood. > > This is varint, correct? http://learnmeabitcoin.com/glossary/varint > > If so, I think this is good idea. > It seems we do not have varint currently in Lightning (at least the parts I > am familiar with). > I suppose the t-l-v being in a different BOLT would let us make some section > or part for describing `varint`. > > Regards, > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
Good morning Christian, The improvement is in a reduction in `fee_base_msat` in the C->D path. If C is the merge point, then the C->D `fee_base_msat` is only paid once, not twice. In effect, A is rationally choosing between a lower fee and better payment reliability. Granted, current `fee_base_msat` across the network is very low currently. So I do not object to restricting merge points to ultimate payees. If fees rise later, we can revisit this. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, November 16, 2018 3:46 AM, Christian Decker wrote: > I'm not sure this is an improvement at all over just allowing a single > merge-point, i.e., the destination. You see as long as we don't attempt > intermediate merges the routes are independent and failures of one HTLC > do not impact any other parts. Take for example the network below: > > -- > > / \ > AB-C-D > \ / > ---E--- > > For simplicity let's assume unit capacities on all channels except C-D > and a total payment of 2 from A to D. > > If we use C as a merge point for the two partial payments A-C-D and > A-B-C-D, then C can only forward if both partial payment succeed, i.e., > if for example A-C fails then we'll need to tear down the HTLCs for both > paths because it'll no longer be possible to find an alternative route > to fulfill the forwarding of 2 over C-D. > > If however we have two independent routes A-B-C-D and A-C-D, then A-C-D > can fail independently and we can recover by attempting A-E-D, no need > to touch A-B-C-D at all. > > Overall it seems we get very little benefit (we save some HTLC setups > and teardown) for a lot of added complexity. In the above case we would > have saved on a single C-D HTLC, and the cost of doing so is many times > larger (2 HTLCs needed to be torn down because we could no longer pass > enough capacity to C in order for it to reach the forward threshold). > > Let's please stick with the simple mechanism of having the recipient be > the only merge point. > > Cheers, > Christian > > ZmnSCPxj via Lightning-dev lightning-dev@lists.linuxfoundation.org > writes: > > > Good morning list, > > I propose the below to support Base AMP. > > The below would allow arbitrary merges of paths, but not arbitrary splits. > > I am uncertain about the safety of arbitrary splits. > > > > ### The `multipath_merge_per_hop` type (`option_base_amp`) > > > > This indicates that payment has been split by the sender using Base AMP, > > and that the receiver should wait for the total intended payment before > > forwarding or claiming the payment. > > In case the receiving node is not the last node in the path, then > > succeeding hops MUST be the same across all splits. > > > > 1. type: 1 (`termination_per_hop`) > > 2. data: > > > > - [`8` : `short_channel_id`] > > - [`8` : `amt_to_forward`] > > - [`4` : `outgoing_cltv_value`] > > - [`8` : `intended_total_payment`] > > - [`4` : `zeros`] > > > > The contents of this hop will be the same across all paths of the Base AMP. > > The `payment_hash` of the incoming HTLCs will also be the same across all > > paths of the Base AMP. > > `intended_total_payment` is the total amount of money that this node should > > expect to receive in all incoming paths to the same `payment_hash`. > > This may be the last hop of a payment onion, in which case the `HMAC` for > > this hop will be `0` (the same rule as for `per_hop_type` 0). > > The receiver: > > > > - MUST impose a reasonable timeout for waiting to receive all component > > paths, and fail all incoming HTLC offers for the `payment_hash` if they > > have not totalled equal to `intended_total_payment`. > > - MUST NOT forward (if an intermediate node) or claim (if the final node) > > unless it has received a total greater or equal to `intended_total_payment` > > in all incoming HTLCs for the same `payment_hash`. > > > > The sender: > > > > - MUST use the same `payment_hash` for all paths of a single multipath > > payment. > > > > Regards, > > ZmnSCPxj > > > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Forwarding hints in channel update messages
On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell wrote: > The decision was made to allow additional channel_update in the error > reply: > > DECISION: document that scid is not binding, allow extra > channel_updates in errors for “upselling”. > Yes, I read this. What exactly is "upselling" in this context and how were extra channel_updates in errors intended to be used for this? Is it useful for non-strict forwarding nodes? > AFAICT this is a deeply weird case. If another channel had capacity you > would have just used it. If another channel doesn't, sending a > channel_update doesn't help. And if there's a channel available at a > higher feerate or longer timeout, it raises the question of why you're > doing that rather than just taking the offer in front of you; that value > clearly used to be acceptable, and now you risk them routing around you. > Good point. If the value is acceptable, but that particular channel happens to have not enough balance, it is hard to explain why you wouldn't just accept. Maybe if you have a large capacity channel that you want to reserve for large amounts at a higher fee and you don't want this channel's balance to be used up by multiple non-strict forwarded small htlcs? This could also be realized by setting min_htlc, but then it can never be used for small htlcs. This admittedly is pretty specific. Maybe the forwarding hint that could make more of a difference is just the information that non-strict forwarding was actually applied. Communicate this as a node property via a global feature bit. If the sender receives a TemporaryChannelFailure from a non-strict forwarding node, it doesn't need to bother with trying all other (equal policy) channels from that node to the next. Regards, Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] type,len,value standard
Good morning Conner et al, > > > 5. `len` - one byte or two? I believe we tend to use two bytes for > > > various > > > lengths. > > > > > > > Maybe varint? One byte is not enough for all lengths, but two seems > > excessive > > for uint8 or even uint32. > > Given that messages are currently only up to 65536 bytes total, is that not a > bit much? Sorry, I misunderstood. This is varint, correct? http://learnmeabitcoin.com/glossary/varint If so, I think this is good idea. It seems we do not have varint currently in Lightning (at least the parts I am familiar with). I suppose the t-l-v being in a different BOLT would let us make some section or part for describing `varint`. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Trustless Watchtowers
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: > > -> 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
