--- Log opened Mon Feb 14 00:00:59 2022 00:04 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection] 00:04 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined #bitcoin-rust 02:55 -!- willcl_ark [~willcl-ar@2001:470:69fc:105::1:620a] has quit [Changing host] 02:55 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has joined #bitcoin-rust 06:06 -!- trev [~trev@user/trev] has quit [Quit: trev] 12:15 < ariard> BlueMatt[m]: if you have few mins, updated #1056 with a hard-value threshold to decide when it's worhty to force-close chans with pending inbound fulfilled HTLCs at fee spikes 12:16 < ariard> could be a configurable knob, lmk if you think it's still worthy to land #1056 12:17 < BlueMatt[m]> yea, sorry, haven't had a chance, will try to take a look in the next few days, but probably not for 105, unless you feel super strongly. 12:18 < ariard> well not really though i've time to land on my side, chill until london 12:21 < ariard> valwal, BlueMatt[m]: also if you wanna follow-up on #989 and anchor output api design, lmk (though more likely a topic for after 0.1 ?) 12:28 < BlueMatt[m]> ariard I think v1 we should just do a "blind try-all-the-things" approach. ie ask the user for any number of utxos to spend, pick one at random and spend it to bump. if you conflict with other channels, who cares, at some point one will get confirmed then you'll have a different utxo to spend. 12:28 < BlueMatt[m]> I do not buy that doing something more complicated is in any way worth the effort 12:29 < BlueMatt[m]> we could also do a full "spend all the anchors in one package" approach, but even that feels like more complexity than its worth 13:49 < valwal> ariard: fyi i think jeff and/or arik are largely taking over anchor work for 2022! 14:47 < ariard> BlueMatt[m]: yep for v1 sounds good enough, you have M utxos and N in-flight channel closures, you pick up one of M and assign to M with conflict-tracking but not resolution, when a conflict confirms, you reassign the CPFP output to the conflicted 14:47 < ariard> a slightly smarter v2 would RBF the CPFP to ensure you have always M=N after _one_ confirmation 14:48 < ariard> i'm still skeptical about "spend all the anchors in one package", like a pinnning/jamming on one channel output compromises all the siblings package components 14:51 < ariard> valwal: ah nice to know someone is taking over, well arik/jkczyz i'm available if you wannat chat anchor 14:51 < ariard> there is still one more meta-question, about inbound channel when 0 fee-bumping output is ready, like should we make mandatory to operate a mobile wallet to have at least one output 14:54 < jkczyz> ariard: sg, we'll be in touch once things settle down on our end and we figure out how we're going to prioritize 15:03 < BlueMatt[m]> "Matt Corallo: yep for v1..." <- no conflict tracking at all, I think! just double-spend like crazy and figure it out later. 15:03 < BlueMatt[m]> the nice thing there is it avoids all of the mess of any communication across `ChannelMonitor`s 15:03 < BlueMatt[m]> which would be really nice to avoid 16:51 < ariard> well if you double-spend the same utxo, you're likely going to provoke a conflict to solve by replacement in the mempools :p 16:51 < ariard> agree communication inside ChannelMonitor is far from ideal 16:52 < BlueMatt[m]> Right, a conflict is totally fine imo! 16:53 < BlueMatt[m]> One will confirm, probably the one we care more about cause it’ll have a higher fee 17:24 < sanket1729> elichai2: Can you please look at https://github.com/rust-bitcoin/rust-secp256k1/pull/390 when you have time? The rust-bitcoin release cycle is blocked on this. 21:09 -!- trev [~trev@user/trev] has joined #bitcoin-rust 21:14 -!- trev [~trev@user/trev] has quit [Remote host closed the connection] 21:14 -!- trev [~trev@user/trev] has joined #bitcoin-rust 21:15 -!- trev [~trev@user/trev] has quit [Remote host closed the connection] 21:42 -!- trev [~trev@user/trev] has joined #bitcoin-rust --- Log closed Tue Feb 15 00:00:59 2022