Conner Fromknecht <conner@lightning.engineering> writes: > In light of this, and if I'm following along, it seems our hand is forced in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline.
Agreed. As Christian pointed out, at least our design space is reduced now? > I would propose sending a distinct message, which references the > `active_channel_id` and a `splice_channel_id` for the pending splice: > > 1. type: XXX (`commitment_splice_signed`) (`option_splice`) > 2. data: > * [`32`:`active_channel_id`] > * [`32`:`splice_channel_id`] > * [`64`:`signature`] > * [`2`:`num_htlcs`] > * [`num_htlcs*64`:`htlc_signature`] > > This more directly addresses handling multiple pending splices, as well as > preventing us from running into any size constraints. The purpose of > including the `active_channel_id` would be to remote node locate the > spliced channel, since it may not be populated indexes containing > active channels. If we don't want to include this, the existing message > can be used without modification. Yes, I like this! I don't think the `splice_channel_id` helps us much, since we need to wait we receive all pending commitement_splice_signed before sending revoke_and_ack, and I think we should simply insist they be in splice order which makes implementation easier (simple counter). >> We shouldn't allow more than one pending splice operation anyway, as >> stated in your proposal initially. We are already critically reliant on > our >> transaction being confirmed on-chain, so I don't see this as much of an >> added issue. > > IMO there's no reason to limit ourselves to one pending splice at the > message > level. I think it'd be an oversight to not to plan ahead with RBF in mind, > given that funding transactions have gone unconfirmed precisely because of > improperly chosen fee rates. Arguably, funding flow should be extended to > support this as well. Good reminder re: RBF and funding. I've put this on the brainstorming list with your name next to it ;) > Adding a splice-reject message/error code should be sufficient to allow > implementations to signal that their local tolerance for number of pending > splices has been reached. It's likely we'd all start with getting one splice > working, but then the messages won't need to modified if we want to > implement > additional pending splices via RBF. > > A node that wants to RBF but receives a reject can then proceed with CPFP > as a > last resort. > > Are there any downsides I'm overlooking with this approach? No, I think you've covered it. >> | Bit Position | Name | Field > | >> | ------------- | ------------------------- | > -------------------------------- | >> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat` > | >> | 1 | `option_channel_moving` | `moving_txid > | >> >> The `channel_update` gains the following field: >> * [`32`: moving_txid`] (option_channel_moving) > > Do we actually need to send the `moving_txid` via a channel update? I think > it's > enough for both parties to send `channel_update`s with the > `option_channel_moving` bit set, and continue to keep the channel in our > routing > table. It helps because they can't broadcast the new channel for 6 confirms. OTOH, that's probably not too long to wait. > If we receive later receive two `channel_update`s whose `short_channel_id`s > reference the spending transaction (and the node pubkeys are the same), we > assume the splice was successful and that this channel has been > subsumed. So rule would be: if we've seen both channel_updates with option_channel_moving set, we remember the txid which closed it, and start a 100-block countdown the "real close". If we a (valid) channel_announce for that closing tx with same node pubkeys, we simply delete the 100-block countdown. > I > think this works so long as the spending transaction doesn't contain > multiple > funding outputs, though I think the current proposal is fallible to this as > well. I think variant above works even in that case? > To me, this proposal has the benefit of not bloating gossip bandwidth with > an > extra field that would need to parsed indefinitely, and gracefully > supporting > RBF down the road. Otherwise we'd need to gossip and store each potential > txid. > > With regards to forwarding, both `short_channel_id`s would be accepted by > the > splicers for up to 100 blocks (after splice confirm?), at which point they > can > both forget the prior `short_channel_id`. Technically, the need to remember for some grace period after they announce the block. We have a similar recommendation for old fee values, though it's soft. 100 seems overkill. I think we can assume gossip will propagate widely within 6 blocks and say they should accept it at least up to 6 blocks after announcing? Or 1 hour, though I prefer using the blockchain as a clock in general. > ## Shachain > >> I thought about restarting the revocation sequence, but it seems like >> that only saves a tiny amount since we only store log(N) entries. We >> can drop old HTLC info post-splice though, and (after some delay for >> obscurity) tell watchtowers to drop old entries I think. > > I agree the additional state isn't too burdensome, and that we would still > be > able to drop watchtower state after some delay as you mentioned. > > On one hand, it does seem like the opportune time to remove such state if > desired. > > OTOH, it is _really_ nice from an atomicity perspective that the current > channel and (potentially) N pending channels can be revoked using a single > commitment secret and message. Doing so would mean we don't have to > modify the `revoke_and_ack` or `channel_reestablish` messages. The receiver > would just apply the commitment secrets/points to the current channel and > any > pending splices. Agreed; on balance, it's fine to avoid reset. > ## Misc > >> Any reason to now make the splicing_add_* messages allow one to add > several >> inputs in a single message? Given "acceptable" constraints for how large > the >> witness and pkScripts can be, we can easily enforce an upper limit on the >> number of inputs/outputs to add. > > Yes, I prefer this simplification. Just harder to write the spec that way :) I'll come up with something. >> Additionally, as the size of the channel is either expanding or > contracting, >> both sides should be allowed to modify things like the CSV param, reserve, >> max accepted htlc's, max htlc size, etc. Many of these parameters like the >> CSV value should scale with the size of the channel, not allowing these >> parameters to be re-negotiated could result in odd scenarios like still >> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k >> satoshis. > > Agreed! "CSV should scale with value" seems like voodoo, though. It make us feel better that we're being conservative with large amounts of money, but it makes no sense from a time-value-of-money perspective. Sure, bigger amounts are more important, but it's also more painful to have them locked up. I'd really like most of these parameters to go away, rather than introducing YA negotiation pain point. See other post. >> These all seem marginal to me. I think if we start hitting max values, >> we should discuss increasing them. > > Doesn't this defeat the goal of firewalling funds against individual channel > failures? That's kind of true, but you should be more concerned about node failure, and thus diversify your channels between different nodes. That's better for everyone. > Splice out, > Conner Nice touch :) Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
