--- Log opened Thu Nov 11 00:00:29 2021
00:20 -!- notmandatory_ [~notmandat@shindig.notmandatory.org] has joined #bitcoin-rust
00:21 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Read error: Connection reset by peer]
01:23 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
01:23 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has joined #bitcoin-rust
01:28 -!- yakshaver123 [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-rust
01:28 -!- yakshaver [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Read error: Connection reset by peer]
05:40 -!- elichai2 [sid212594@hampstead.irccloud.com] has quit [Ping timeout: 250 seconds]
05:40 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
05:41 -!- moneyball_ [sid299869@helmsley.irccloud.com] has quit [Ping timeout: 256 seconds]
05:41 -!- sebx2a [sid356034@uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds]
05:41 -!- arik [sid402902@lymington.irccloud.com] has quit [Ping timeout: 256 seconds]
05:42 -!- fjahr [sid374480@uxbridge.irccloud.com] has quit [Ping timeout: 264 seconds]
05:42 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 268 seconds]
05:42 -!- stick [sid403625@user/prusnak] has quit [Ping timeout: 240 seconds]
05:42 -!- elichai2 [sid212594@hampstead.irccloud.com] has joined #bitcoin-rust
05:42 -!- moneyball_ [sid299869@helmsley.irccloud.com] has joined #bitcoin-rust
05:42 -!- jkczyz [sid419941@lymington.irccloud.com] has quit [Ping timeout: 264 seconds]
05:42 -!- FelixWeis [sid154231@hampstead.irccloud.com] has quit [Ping timeout: 264 seconds]
05:43 -!- RubenSomsen [sid301948@2a03:5180:f:1::4:9b7c] has joined #bitcoin-rust
05:43 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined #bitcoin-rust
05:43 -!- RubenSomsen [sid301948@2a03:5180:f:1::4:9b7c] has quit [Changing host]
05:43 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #bitcoin-rust
05:43 -!- stick [sid403625@lymington.irccloud.com] has joined #bitcoin-rust
05:43 -!- blkncd [sid505676@5.254.36.58] has joined #bitcoin-rust
05:43 -!- sebx2a [sid356034@id-356034.uxbridge.irccloud.com] has joined #bitcoin-rust
05:43 -!- stick [sid403625@lymington.irccloud.com] has quit [Changing host]
05:43 -!- stick [sid403625@user/prusnak] has joined #bitcoin-rust
05:43 -!- arik [sid402902@id-402902.lymington.irccloud.com] has joined #bitcoin-rust
05:43 -!- jkczyz [sid419941@id-419941.lymington.irccloud.com] has joined #bitcoin-rust
05:44 -!- FelixWeis [sid154231@id-154231.hampstead.irccloud.com] has joined #bitcoin-rust
06:16 -!- stick [sid403625@user/prusnak] has quit [Ping timeout: 260 seconds]
06:17 -!- elichai2 [sid212594@hampstead.irccloud.com] has quit [Ping timeout: 260 seconds]
06:17 -!- arik [sid402902@id-402902.lymington.irccloud.com] has quit [Ping timeout: 264 seconds]
06:17 -!- moneyball_ [sid299869@helmsley.irccloud.com] has quit [Ping timeout: 256 seconds]
06:18 -!- jkczyz [sid419941@id-419941.lymington.irccloud.com] has quit [Ping timeout: 268 seconds]
06:18 -!- blkncd [sid505676@5.254.36.58] has quit [Ping timeout: 264 seconds]
06:18 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 264 seconds]
06:18 -!- sebx2a [sid356034@id-356034.uxbridge.irccloud.com] has quit [Ping timeout: 250 seconds]
06:18 -!- FelixWeis [sid154231@id-154231.hampstead.irccloud.com] has quit [Ping timeout: 264 seconds]
06:19 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Ping timeout: 250 seconds]
06:22 -!- moneyball_ [sid299869@helmsley.irccloud.com] has joined #bitcoin-rust
06:23 -!- elichai2 [sid212594@hampstead.irccloud.com] has joined #bitcoin-rust
06:23 -!- sebx2a [sid356034@uxbridge.irccloud.com] has joined #bitcoin-rust
06:24 -!- arik [sid402902@lymington.irccloud.com] has joined #bitcoin-rust
06:24 -!- blkncd [sid505676@helmsley.irccloud.com] has joined #bitcoin-rust
06:31 -!- stick [sid403625@user/prusnak] has joined #bitcoin-rust
06:34 -!- fjahr [sid374480@uxbridge.irccloud.com] has joined #bitcoin-rust
06:34 -!- FelixWeis [sid154231@hampstead.irccloud.com] has joined #bitcoin-rust
06:44 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #bitcoin-rust
06:44 -!- jkczyz [sid419941@lymington.irccloud.com] has joined #bitcoin-rust
12:30 -!- cwlittle [~cwlittle@2600:1700:1c0:8140:1d6c:70f4:85a8:aedd] has joined #bitcoin-rust
12:31 < cwlittle> Anyone have any idea why BlockHeader::block_hash() would return something other than the actual block hash when the BlockHeader type was created manually?
12:34 -!- cwlittle [~cwlittle@2600:1700:1c0:8140:1d6c:70f4:85a8:aedd] has quit [Client Quit]
13:21 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has quit [Ping timeout: 260 seconds]
13:26 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #bitcoin-rust
13:33 < ariard> BlueMatt: backtracing the fuzz failure, it sounds to me our counterparty should close the channel because we detected it's an overflowing outbound update_fee
13:33 < ariard> but it doesn't...adding more logs to see why
13:37 < BlueMatt> ah! okay.
13:37 < BlueMatt> that makes sense. it failed to close, and then the channel was stuck cause it should have closed
15:47 < ariard> BlueMatt: okayyyy so i clearly found bugs on 1054, namely the outbound update fee affordance is computed on dust fee *included*
15:47 < ariard> and it shouldn't!
15:48 < ariard> BlueMatt: but the fuzz failure is also failing on master from what I can observe?
15:48 < BlueMatt> heh, yay fuzzer?
15:48 < BlueMatt> yes, I believe so
15:48 < BlueMatt> the fuzzer has a few cases of "uhmmm, you shouldn't have sent that update fee" on master, IIRC
15:49 < ariard> so the current update_fee mechanism on master is broken?
15:49 < BlueMatt> its possible it found some channel hangs that are unrelated to the update_fee
15:49 < BlueMatt> i mean obviously - it doesn't check if we can afford it! :p
15:49 < ariard> right, but i think we have a further issue with checks against channel reserve
15:49 < BlueMatt> that's entirely possible, yea.
15:49 < ariard> it doesn't seem the remote balance is computed correctly
15:50 < ariard> BlueMatt: here, i think we should sub inbound HTLCs, https://github.com/rust-bitcoin/rust-lightning/blob/7c4dfad4fe97c9d8bc37c38e15b9dab95f27e37a/lightning/src/ln/channel.rs#L2485 ?
15:51 < ariard> because value_to_self_msat it only based on last RAA dance
15:53 < BlueMatt> hmmmmmmm, you mean removed htlcs, right?
15:53 < BlueMatt> I'd buy that
15:53 < BlueMatt> nono, its  using the fee of the num_htlcs
15:53 < BlueMatt> no, that code looks right?
15:53 < BlueMatt> ohhhh
15:53 < BlueMatt> i see your point
15:53 < BlueMatt> like, you're saying value_to_self there != paid_to_self_in_commitment_tx?
15:54 < BlueMatt> cause we need to include htlcs that dont appear
15:54 < ariard> correct, because to_self_in_commitment_tx is the next round
15:54 < BlueMatt> yea, I buy that, I think the easiest and most correct way there would be to extract the value_paid_to_self from the commitment tx being generated
15:55 < ariard> well, not only the dust htlcs, but also the above-dust inbounds ones ?
15:55 < ariard> value_to_self is only updated in RAA and this check happens at remote CS recepton
15:57 < BlueMatt> right, I'm saying 20 lines up we construct a local commitment transaction. we want *that* transaction to have the right
15:57 < BlueMatt> balances to meet reserve
15:58 < BlueMatt> oh, wait, no, we also care about the counterparty commitment at this point, right?
15:58 < BlueMatt> or, the next one.
15:59 < BlueMatt> or is that always going to meet the criteria as well cause we'll flow the same htlc updates into it?
15:59 < BlueMatt> i guess except for pending outbound ones, but we can't do anything about that at receive-time?
15:59 < BlueMatt> ugh.
16:00 < BlueMatt> independently, why are we getting stuck channels in the fuzzer?
16:00 < ariard> but the balance should be independent on either counterparty commitment or holder, even if the effective fees are different because of dust ?
16:01 < ariard> but pending outbound ones stay part of the holder balance, somehow, or at least it doesn't play to evaluate counterparty affordance w.r.t reserve ?
16:02 < ariard> that i don't know why we get stuck channels :p
16:02 < ariard> like even applying the fixes locally it still failing
16:06 < BlueMatt> right, so I figured the reason the stuck channel failures came about was cause we over-paid on fees and then couldn't send any more cause the fees went up too close to the edge
16:06 < BlueMatt> (these failures were introduced when we added fee updates to that fuzzer)
16:07 < BlueMatt> <ariard> but the balance should be independent on either counterparty commitment or holder, even if the effective fees are different because of dust ? <-- I'm not sure what you mean here?
16:09 < ariard> at the same state, a `to_remote`` output should amount to the same total of satoshis on both counterparty and holder txn ?
16:09 < ariard> and this is the one we care to not go under channel reserve
16:10 < BlueMatt> I mean we can have *outbound* pending updates too, new htlcs to send.
16:10 < BlueMatt> of course our counterparty can't predict that
16:12 < ariard> right, though i'm thinking about the affordance check L2485 at CS reception, if the outbound from other side have not been announced in this sequence we don't care ? 
16:13 < ariard> ah so it's okay to have a stuck channel case, like we don't have enough balance remaining to move the chan forward because fee too high?
16:13 < BlueMatt> right, I mean they may have been announced and not committed yet, but I think in general we never do that cause its not practical, we always announce+commit at once.
16:14 < BlueMatt> <ariard> ah so it's okay to have a stuck channel case, like we don't have enough balance remaining to move the chan forward because fee too high? <-- hmm, I think we can always avoid it, right? like, if fee is too high we shouldn't have sent the feee update?
16:14 < BlueMatt> the "stuck channel" test here first clears out all pending htlcs
16:14 < ariard> right, right but this announced-but-not-committed-yet should be sub from the funder balance for affordance check ?
16:14 < BlueMatt> <ariard> right, though i'm thinking about the affordance check L2485 at CS reception, if the outbound from other side have not been announced in this sequence we don't care ?  <-- so, yea, I think I agree with you - if the commitment tx we created 20 lines up meets the counterparty reserve, the next outbound commitment tx will too
16:15 < BlueMatt> <ariard> right, right but this announced-but-not-committed-yet should be sub from the funder balance for affordance check ? <-- you mean L2485? yes, that's wrong.
16:15 < ariard> hmm, I think we can always avoid it, right? like, if fee is too high we shouldn't have sent the feee update?
16:16 < ariard> > isn't that a case when we hit the bottom of the fee spikes buffer ?
16:16 < BlueMatt> right, but we have an htlc or two in the fee spike buffer too?
16:16 < BlueMatt> so once the htlcs clear out we should always still have an htlc free?
16:16 < BlueMatt> or do you mean we hit fee-spike-buffer and *then* send an htlc further moving the balance?
16:16 < ariard> doesn't mean they can't be swallowed in practice by a sudden fee spikes ?
16:16 < BlueMatt> maybe there's a case there
16:17 < BlueMatt> the fuzzer limits its fee increases to the fee spike buffer increase multiple
16:17 < BlueMatt> so it never violates it through fee
16:17 < BlueMatt> like the fees in the fuzzer only shift around by 2x or whatever
16:17 < ariard> the second case, we hit fee-spike-buffer moving the balance on the other case
16:17 < ariard> *side
16:17 < BlueMatt> hmm?
16:18 < BlueMatt> https://github.com/rust-bitcoin/rust-lightning/blob/main/fuzz/src/chanmon_consistency.rs#L1050-L1054
16:18 < BlueMatt> so we let the fee increase 2x after the last time we cleared all htlcs
16:18 < ariard> if we've moved our balance on the other side, we just can't send HTLCs anymore without violating the reserve check (operated by the counterparty) ?
16:19 < BlueMatt> right, that's what the fee spike buffer is fore
16:19 < BlueMatt> for
16:19 < BlueMatt> the test is making sure that the counterparty can always send 1 htlc
16:20 < ariard> "you mean L2485? yes, that's wrong." i've pushed a fix for that on 1054, there is anoter place in `send_htlc` i think
16:21 < BlueMatt> wonder if thats the bug the fuzzer is hitting?
16:22 < BlueMatt> fwiw your pr uses 2* in a few places, should be the FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE constant
16:22 < ariard> maybe, though i'm still failing the fuzzer locally, though my fix might be wrong
16:22 < BlueMatt> you mean even after fixing send_htlc?
16:23 < ariard> ah i think we had this discussion before, here or on the PR, it's a BUFFER_FEE_FOR_CONCURRENT_INBOUND_HTLC, no ?
16:23 < BlueMatt> your fix isn't complete, it doesn't consider that some HTLCs may be in the RemoteRemoved state
16:23 < ariard> like it's a +2 not a *2 ?
16:23 < BlueMatt> which means as soon as we're done processing the commitment_signed we'll remove them
16:23 < BlueMatt> we need to not count those as well
16:23 < ariard> and there is one on the fuzz input you gave me :p
16:24 < ariard> so i need to count them like they were dust ? not included
16:24 < BlueMatt> <ariard> like it's a +2 not a *2 ? <-- oh lol i cant read
16:24 < BlueMatt> <ariard> so i need to count them like they were dust ? not included <-- yes, basically. I think its gonna be easier to just extract the amounts from the commitment tx
16:24 < BlueMatt> they should be stored there.
16:26 < ariard> right, i was just quickly testing a fix
16:26 < ariard> but yeah we should have one code extracted from build_commitment
16:27 < ariard> so FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE keeps twice the current fee as a buffer
16:27 < ariard> my "+2" extend the fee scope to include two more concurrent inbound HTLCs
16:27 < BlueMatt> right
16:27 < ariard> i would say both of them are fee buffer, though not on the same exac reasoning :p
16:28 < BlueMatt> sure, of course
16:28 < BlueMatt> yes, sorry, i just cant read
16:28 < BlueMatt> your damn /* */ comments make it look like there's a multiplication :p
16:28 < ariard> okay let me see if RemoteRemoved fix the fuzzer
16:28 < ariard> right, i should and will constify them :p
20:25 -!- achow101 [~achow101@user/achow101] has quit [Quit: Bye]
20:25 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-rust
20:43 -!- Netsplit *.net <-> *.split quits: MatrixBot1234510, kcalvinalvin
20:48 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-rust
20:48 -!- MatrixBot1234510 [~matrixbot@51.15.54.153] has joined #bitcoin-rust
--- Log closed Fri Nov 12 00:00:30 2021