--- Log opened Tue Nov 16 00:00:35 2021 02:51 -!- b10c [uid500648@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 02:57 < dr-orlovsky> andytoshi: some time ago we discussed idea to add Kixunil to repo maintainers and you approved it. He does really good job on reviewing each commit in rust-bitcoin these days and may help to move taproot faster. How we can execute the decision? 03:20 < andytoshi> dr-orlovsky: sure, one sec 03:20 < andytoshi> and riccardo too? 03:22 < andytoshi> added both 03:22 < andytoshi> we now have nine maintainers. we'll see how manageable things are but i think maybe we'll need to move to 3 acks soon 03:23 < andytoshi> well, only matt and i have admin access, everyone else is "Write", but we have 9 people who can push 03:39 -!- b10c [uid500648@ilkley.irccloud.com] has joined #bitcoin-rust 06:18 < ariard> BlueMatt: yes re-acked 1119, fixing 1054 rn! 06:49 -!- Guest3 [~Guest3@46-138-89-118.dynamic.spd-mgts.ru] has joined #bitcoin-rust 06:53 -!- Guest3 [~Guest3@46-138-89-118.dynamic.spd-mgts.ru] has quit [Client Quit] 07:44 < sanket1729_> +1 for Martin and Riccardo, I thought it was already done :) 07:44 < sanket1729_> Is Kixunil on IRC here? 10:59 < ariard> BlueMatt: btw updated with using amounts from build_commitment_transaction, though still failing the fuzz input on the channel stuck condition 10:59 < ariard> which let me wonder if chanmon_consistency account correctly for one-more-htlc fee buffer? otherwise it will always find channel stuck 11:01 < BlueMatt> grrrrr uhmmmmm 11:01 < BlueMatt> it doesn't account for the extra htlc at all? but isn't that the point? it caps the fee increase 11:01 < BlueMatt> and then ensures it can send an htlc 11:02 < ariard> it caps for the fee increase, yes but not in the same branch ? 11:02 < ariard> like the "ensure you can send an htlc" is the 0xff branch 11:02 < BlueMatt> hmm? 11:02 < BlueMatt> sure but my point is more that if we *only* cap the fee increase that should suffice to ensure channel is never stuck? 11:02 < BlueMatt> precisely *because* of the extra htlc buffer 11:05 < ariard> hey i dunno about that, because whatever your feerate, you might have send all your liquidity on the other side 11:05 < ariard> and then you're infringing on the extra htlc buffer 11:05 < BlueMatt> hmm? if you sent all your liqudiity to the other side, the other side should have enough to send, and you just enough to pay that one htlc, which is exactly the htlc buffer 11:05 < BlueMatt> maybe i didnt quite get your comment there? 11:06 < BlueMatt> it is possible that its limit on the feerate increases isn't quite capped tightly enough? 11:06 < BlueMatt> ariard: try removing the three lines here: https://github.com/rust-bitcoin/rust-lightning/blob/main/fuzz/src/chanmon_consistency.rs#L1136 11:06 < ariard> my understanding is that of course letting the feerate increase unbounded means as the fee-payer we're going to reach faster the extra htlc buffer 11:08 < BlueMatt> right, but we dont let the feerate increase unbounded? 11:08 < ariard> BlueMatt: wait i think we're clearly talking past each other, the fuzz failure reported is "Cannot send value that would put counterparty balance under holder-announced channel reserve value" 11:09 < BlueMatt> where do you see the failure? 11:09 < BlueMatt> like, what line? 11:09 < ariard> which is a different thing than the extra htlc buffer 11:09 < BlueMatt> one of these two assertions, right - https://github.com/rust-bitcoin/rust-lightning/blob/main/fuzz/src/chanmon_consistency.rs#L1128 11:09 < ariard> L4579 channel.rs 11:09 < ariard> on running the fuzz input locally 11:10 < ariard> BlueMatt: and that the error i get on the other side "Cannot send value that would overdraw remaining funds. Amount: 10000000, pending value to self 1659868" 11:11 < BlueMatt> right, so its just the standard feerate issue 11:11 < BlueMatt> yea, so i think we're on the same page 11:11 < BlueMatt> I'm still confused why you think it should possible to hit in the fuzzer 11:13 < BlueMatt> bbiab 11:17 < ariard> yeah, i think the error cannot-send-value-that-would-overdraw sounds wrong to me, as this side should have a balance wide enough to cover the HTLC sending 11:31 -!- b10c [uid500648@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 11:42 < ariard> BlueMatt: okay i think i got the root cause, value_to_self_msat != value_to_self from build_commitment_transaction so that check wrongly fails: https://github.com/rust-bitcoin/rust-lightning/blob/main/lightning/src/ln/channel.rs#L4644 11:43 < ariard> using the latter, build_commitment_transaction value, succeeds the fuzz 11:48 < BlueMatt> ariard: I think amybe you linked to the wrong line? 11:48 < BlueMatt> but, yay! 12:33 -!- jkczyz [sid419941@lymington.irccloud.com] has quit [Ping timeout: 256 seconds] 12:36 -!- jkczyz [sid419941@lymington.irccloud.com] has joined #bitcoin-rust 13:15 < ariard> BlueMatt: back from gym, well i think i really meant this line "let pending_value_to_self_msat = self.value_to_self_msat - outbound_stats.pending_htlcs_value_msat;" 13:16 < BlueMatt> seems to say all msat? 13:16 < ariard> though now i still don't get why value_to_self_msat doesn't reflect the right value 13:16 < ariard> it's not an issue with msat/sat (i think) 13:16 < ariard> it's just value_to_self_msat is different from value_to_self as computed by build_commitment_transaction 13:17 < BlueMatt> ohhhh, huh 13:17 < BlueMatt> you mean even when we have no htlcs? 13:17 < BlueMatt> that sounds wrong? 13:17 < ariard> yes even when we have no htlcs! 13:17 < ariard> agree it's wrong 13:18 < BlueMatt> huh..... 13:18 < BlueMatt> ok, give me a few minutes and I'll take a look 13:18 < ariard> yeah adding more printers to see when it got wrong 13:19 < BlueMatt> thanks 13:26 < ariard> 1 14:03 -!- b10c [uid500648@ilkley.irccloud.com] has joined #bitcoin-rust 17:40 -!- b10c [uid500648@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 18:15 < ariard> BlueMatt: see latest push 5c986fa, everything should be green 18:15 < ariard> though my first fuzz fix was incorrect, after digging more the reason sounds to be that https://github.com/rust-bitcoin/rust-lightning/blob/77948dbcd7b167ff4386f1b9de13bd2d2aa97032/lightning/src/ln/channel.rs#L2730 18:16 < ariard> or namely that in case of holding_update_fee, when we free it, we didn't enforce any fee-affordance check! 18:17 < ariard> without 1054 is quite dysfunctional, i'm quite dumb to have miss it so far :p 18:17 < ariard> BlueMatt: happy if you can look on it to confirm and hopefully being done with 1054 tomorrow --- Log closed Wed Nov 17 00:00:35 2021