--- Log opened Tue Oct 03 00:00:46 2023 00:30 -!- harvhat_ [~harvey@2601:19b:8200:aa10:2c0f:5ce9:a9be:3a3a] has joined #lightning-dev 00:34 -!- harvhat__ [~harvey@2601:19b:8200:aa10:7dc5:8b16:23f4:3ff] has quit [Ping timeout: 258 seconds] 01:11 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #lightning-dev 01:48 < vincenzopalazzo> From the spec I am not able to see if it is possible reject or abort a splice operation, there are plan for it? or splice will be always an permitted operation? 01:50 < vincenzopalazzo> One case that I would like to abort a splice is due a fee spike where the RBF transaction it is not worthed anymore 01:58 < realtbast[m]> You can always send tx_abort at any time, for any reason you'd like 02:04 -!- DarrylTheFish [~DarrylThe@user/DarrylTheFish] has joined #lightning-dev 02:07 -!- DarrylTheFiish [~DarrylThe@user/DarrylTheFish] has joined #lightning-dev 02:10 -!- DarrylTheFish [~DarrylThe@user/DarrylTheFish] has quit [Ping timeout: 240 seconds] 02:17 < vincenzopalazzo> I see, ok so the interactive-tx has the power to choose to abort a splice, I was thinking that tx_abort stops the interactive-tx workflow and then we need a `splice_nak` to say "I do not want to do this anymore" 02:27 < devrandom[m]> "I see, ok so the interactive-..." <- in a sense, it's "free" to be in splice state if there are no RBF candidates in flight, because the only thing that is negotiated by a `splice` message is the funding pubkey rotation. it doesn't prevent any action or slow anything down. 02:27 < devrandom[m]> of course, once you have RBF candidates, things are a bit slower because you need to sign `N+1` commitment and HTLC txs on each state update. but if you abort any offered tx negotiations, you will stay at `N = 0`. 02:59 -!- DarrylTheFiiish [~DarrylThe@user/DarrylTheFish] has joined #lightning-dev 03:01 -!- DarrylTheFiish [~DarrylThe@user/DarrylTheFish] has quit [Ping timeout: 258 seconds] 03:13 -!- Flow [~none@gentoo/developer/flow] has quit [Ping timeout: 248 seconds] 03:19 -!- Flow [~none@gentoo/developer/flow] has joined #lightning-dev 03:35 < ksedgwic[m]> But once you've approved a splice candidate, is there anyway to retreat to the original channel to mutually close instead? 03:36 < vincenzopalazzo> devrandom[m], I see, in some sense the splice abort is a implementation details when there is no RBF candidates 03:38 < ksedgwic[m]> Are you obligated to negotiate to a successful new committed splice state to mutually close again? 03:41 < ksedgwic[m]> Is it a griefing vector to initiate a splice, insert a bunch of RBF candidates and then not complete? 03:41 < ksedgwic[m]> s/insert/create/ 04:16 < realtbast[m]> It could be if none of these transactions ever confirm 04:16 < realtbast[m]> But it's a small griefing vector: it only costs you a bit of CPU and bandwidth 04:17 < realtbast[m]> You can have arbitrary constraints on the feerate you accept depending on the number of unconfirmed candidates: for example if there are 5 unconfirmed splice candidates, you may only accept another one if its feerate is high enough for quick confirmation 04:17 < realtbast[m]> I'm not afraid of that kind of griefing attacks at all to be honest 04:53 < realtbast[m]> By the way, this is something that needs to be taken into account in the simple taproot channels PR roasbeef arik__ 04:53 < realtbast[m]> When there are ongoing splices, we'll need to send one nonce per splice, right? 04:53 < realtbast[m]> So we should engineer the TLVs accordingly right now, to make sure it's easy to use splice on top of taproot channels 04:54 -!- Ademan [~ademan@47.161.41.51] has quit [Ping timeout: 272 seconds] 04:54 -!- Ademan [~ademan@47.161.41.51] has joined #lightning-dev 04:59 < devrandom[m]> "Are you obligated to negotiate..." <- no, you can mutual-close, assuming you are not in the middle of doing the interactive-tx flow. if you are just waiting for confirmations, you send a `shutdown` message. 05:00 -!- lbia1 is now known as lbia 06:18 -!- Flow [~none@gentoo/developer/flow] has quit [Ping timeout: 272 seconds] 06:22 -!- Flow [~none@gentoo/developer/flow] has joined #lightning-dev 07:30 -!- Flow [~none@gentoo/developer/flow] has quit [Ping timeout: 248 seconds] 07:38 -!- Flow [~none@gentoo/developer/flow] has joined #lightning-dev 09:14 < ksedgwic[m]> From https://github.com/rustyrussell/lightning-rfc/blob/guilt/splice/02-peer-protocol.md#requirements-8:... (full message at ) 09:16 < ksedgwic[m]> Should this say "ongoing splice negotiation"? But allow a shutdown if there is are outstanding splice candidates? 09:16 < ksedgwic[m]> s/is// 09:21 < realtbast[m]> That's a good point, currently the spec doesn't let you initiate mutual close while there are pending splices. That's because you don't know which funding output the mutual close transaction should use: if it uses the last confirmed one, maybe the splice will confirm and double-spend your mutual close transaction. If you use one of the unconfirmed splice candidates, you have the same issue: if another candidate confirms, your mutual 09:21 < realtbast[m]> close transaction is now invalid. 09:21 < realtbast[m]> I'm not sure whether we should address this issue or just let implementations reject new splices once the node operator signaled that they want to mutual close, wait for the latest splice to confirm, and only then send shutdown 09:49 -!- Flow [~none@gentoo/developer/flow] has quit [Ping timeout: 248 seconds] 09:58 -!- jarthur [~jarthur@user/jarthur] has joined #lightning-dev 10:07 -!- Flow [~none@gentoo/developer/flow] has joined #lightning-dev 10:59 < ksedgwic[m]> QuoFranVo 11:26 -!- jarthur [~jarthur@user/jarthur] has quit [Ping timeout: 246 seconds] 11:29 -!- jarthur [~jarthur@user/jarthur] has joined #lightning-dev 13:02 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #lightning-dev 13:16 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer] 13:16 -!- jonatack [~jonatack@user/jonatack] has joined #lightning-dev 13:49 -!- DeanGuss [~dean@user/deanguss] has quit [Quit: buhbye] 13:55 -!- DeanGuss [~dean@nonplayercharacter.me] has joined #lightning-dev 13:55 -!- DeanGuss [~dean@user/deanguss] has changed host 14:21 < devrandom[m]> seems like it should be fine to mutual-close on top of any of the funding transactions, and if another one confirms, then retry the mutual close on whatever did confirm 15:20 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...] 15:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:48 -!- jetpack_ [~jetpack@2605:2700:1:100e:dc::f01d] has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in] 16:48 -!- jetpack [~jetpack@2605:2700:1:100e:dc::f01d] has joined #lightning-dev 18:47 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving] 19:42 -!- jQrg [~jq@2001:8c0:ea04:37:362c:e170:9b71:8677] has joined #lightning-dev 19:43 -!- jQrg [~jq@2001:8c0:ea04:37:362c:e170:9b71:8677] has quit [Quit: WeeChat 3.5] 21:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 21:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev 21:50 -!- Ademan [~ademan@47.161.41.51] has quit [Quit: leaving] 22:11 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur] 23:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 252 seconds] 23:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 23:57 < realtbast[m]> That needs a new mutual close protocol 23:58 < realtbast[m]> Maybe we can do that with option_simple_close though, to be investigated --- Log closed Wed Oct 04 00:00:46 2023