--- Log opened Mon Nov 29 00:00:46 2021
00:59 -!- trev [~trev@user/trev] has joined #bitcoin-rust
04:48 -!- tibo [~tibo@240d:1a:afa:1d00:6c5f:6ba8:7af2:92b0] has quit []
04:56 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has joined #bitcoin-rust
05:55 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
06:14 -!- belcher [~belcher@user/belcher] has joined #bitcoin-rust
06:48 -!- trev [~trev@user/trev] has quit [Ping timeout: 265 seconds]
06:48 -!- trev [~trev@user/trev] has joined #bitcoin-rust
07:59 < ariard> BlueMatt: done
08:00 < ariard> BlueMatt: see https://github.com/rust-bitcoin/rust-lightning/pull/1056#discussion_r758457150, if you have a straightforward way to setup the config know i'll take it, though i think we'll better off sweating on anchor output :p
09:33 < BlueMatt> ariard: I'm not sure you understood my comment
09:33 < BlueMatt> ariard: I mean literally change this line to use a knob instead of a constant - https://github.com/rust-bitcoin/rust-lightning/pull/1056/files#diff-8d28e96b6f27edb9a9739b2dce334f8906ec906155d421a7b5b02aa8e6c96057R2865
09:38 < BlueMatt> oh, you were asking for a better way to explain to users how to set it
09:38 < BlueMatt> yes, okay, responded on gh
10:51 < BlueMatt> ok, rust-lightning has moved to /lightningdevkit/ https://github.com/lightningdevkit/rust-lightning
11:02 < ariard> BlueMatt: reading, btw meeting!
11:20 -!- trev [~trev@user/trev] has quit [Quit: trev]
11:52 < ariard> BlueMatt: re-1056 a) if inbound only, check preimages and b) configurable feerate-based know expressing the level of trust toward the counterparty ?
11:53 < ariard> yeah i still think we're confusing feerate threshold at which we're not going to be included in the block and odds of the peer being unresponsive/dishonest
11:53 < ariard> but i don't really care and i expect 99% of the users to not touch it
12:00 -!- real_or_random [~real_or_r@user/real-or-random/x-4440763] has quit [Quit: ZNC 1.8.2 - https://znc.in]
12:00 -!- real_or_random [~real_or_r@user/real-or-random/x-4440763] has joined #bitcoin-rust
12:01 -!- jetpack [~jetpack@2605:2700:1:100e:ddb4:196e:c17a:3b92] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
12:01 -!- jetpack [~jetpack@2605:2700:1:100e:ddb4:196e:c17a:3b92] has joined #bitcoin-rust
12:02 < BlueMatt> ariard: I do wonder if we should maybe make the knob the time, then?
12:02 < BlueMatt> or have two knobs?
12:02 < BlueMatt> sucks to have two knobs but as a user I kinda want it
12:02 < BlueMatt> like, personally, I want the time to be, like, a day? fees go up and down on day timescales
12:02 < BlueMatt> but at the same time the timescale is probably a function of the htlc
12:03 < BlueMatt> so maybe we make the % the knob and make the timescale for auto-close be based on the htlc timeout?
13:40 -!- Netsplit *.net <-> *.split quits: RCasatta[m], jeremyrubin, RubenSomsen, dpc[m], stevenroose, greypw254, fjahr, achow101, elsirion, b42,  (+18 more, use /NETSPLIT to show all of them)
13:44 -!- Netsplit over, joins: real_or_random, RubenSomsen, michaelfolkson, ariard, jeremyrubin, otoburb, _0x0ff, greypw254, willcl_ark, h4sh3d (+18 more)
14:54 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
16:11 -!- tibo [~tibo@203x114x24x115.ap203.ftth.arteria-hikari.net] has joined #bitcoin-rust
17:47 < ariard> BlueMatt: yes making the knob scaling the time, if you have high confidence in your peer reliability increase AUTOCLOSE_TIMER to something longuer ?
17:47 < BlueMatt> ariard: hmmm, i think the right answer is just a function of fee?
17:47 < BlueMatt> ariard: a knob based on time isn't so useful - if a peer sent us an htlc that expires soon we'll force-close either way, whether they come online or not
17:47 < ariard> BlueMatt: though i think the feerate % should be the worst-case block feerate inclusion, but if you have higher cnfidence in your peer should be able to downgrade it
17:47 < BlueMatt> if the htlc doesnt expire for a long time...
17:48 < BlueMatt> ariard: right, but (a) we dont have an api for that and (b) no feerate estimator I'm aware of does either
17:48 < ariard> well if they'r more reliable we assume they're always online and we should be able to correct faster the feerate
17:48 < BlueMatt> reliable != trusted
17:49 < ariard> issssh, i dunno there is trusted in the sense of not broadcasting previous state and trusted in the sense of being online to update the commitment timely
17:50 < ariard> in my mind, though you could abuse your reliability to try to steal in-flight HTLC
17:50 < BlueMatt> sure, but i think the point of the knob is "I trust this peer, it may not be reliable, but they're not playing games"
17:50 < BlueMatt> yea, I guess that's kinda true
17:50 < BlueMatt> like, the specific attack here is going offline and then coming back and broadcasting
17:50 < BlueMatt> which even a "trusted" peer would do - its software defaults
17:50 < ariard> BlueMatt: yes we don't have an api and no feerate estimator and ultimately update fee is legacy fee-bmping
17:50 < BlueMatt> so maybe the only knob should be feerate %
17:50 < BlueMatt> not time-based?
17:51 < BlueMatt> like, basically the knob is "how much I think the fee estimator will overshoot"
17:51 < ariard> right and not making into the mempool, really genunnely
17:51 < ariard> i'm thinking how fast i can come to consensus to update feerate assuming a given velocity to wworst-case
17:52 < ariard> though yeah we don't have api for velocity-to-worst-case so we're reduced to coming to an agreement with our peer
17:52 < BlueMatt> right
17:53 < ariard> yeah, i'm good with a knob "hhow much the fee estimator will overshoot" though honestly
17:53 < ariard> i wouldn't be able to fine-tune it for my own node 
17:53 < BlueMatt> yea, I guess docs can focus more on feerate variability within HTLC timeouts
17:54 < BlueMatt> like, if you plan on having peers that forward HTLCs that take a day to time out, then you should set the knob to the amount you think feerate will increase only to decrease later during a day.
17:54 < ariard> we're like what? 18 blocks for HTLC timeouts, feerate can x2 or x3 if you study some worst historical fee spikes
17:55 < ariard> right it's not the HTLC_CLAIM_BUFFER  we care but cltv_expiry_delta
17:55 < ariard> so the knob as the maximum feerate variation for a given cltv_expiry_delta, and we remove from the reasoning assumptions on peer reliability
17:56 < ariard> we assume the counterparty is always online and trusthworthy, which is a completely flawed assumption but well update_fee is broken...
17:56 < BlueMatt> right, but there's like nothing we can do there?
17:56 < BlueMatt> like, if the feerate spikes its within one block?
17:56 < ariard> no, i can think of somthing btter rn
17:57 < ariard> can't
17:57 < BlueMatt> i mean force-closing doesn't feel like the right answer there, then?
17:57 < BlueMatt> like, you're better off just hoping your counterparty comes back online to resolve the htlc off-chain even post-timeout
17:57 < ariard> you assume fee spikes are going to become worst with time
17:57 < BlueMatt> rather than going to chain and watching your transaction never confirm
17:58 < ariard> that's a bet, first altnerative you hope your counterparty is online to come back in-time, updpat the feerate and close it on-chain
17:58 < ariard> well as it's a trade-off, i think best we can do is a mking auto-close an option to disable
17:59 < ariard> BlueMatt: okay if you're good i'll make the knob a feerate to tweak with that reasoning, 've to go birds start to sing here :p
17:59 < BlueMatt> I feel like we should dig into block production unluckiness more
18:00 < BlueMatt> like, if feerate estimates spike because there's been no block in 60 minutes how is closing now gonna help?
18:00 < ariard> BlueMatt: have a look on that https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html, block production unluckiness and mempool congestion that's real work
18:01 < ariard> BlueMatt: thinking for tmrw, i've to go to sleep!
18:01 < BlueMatt> okay, get some sleep
18:01 < BlueMatt> one alternate design to ponder - increase the timeout buffer in ChannelMonitor based on feerate
18:01 < BlueMatt> difference
18:01 < BlueMatt> like, if the feerate on commitment tx is 0.75x the current feerate, close the channel 1/0.75x blocks earlier than the constant implies
18:01 < BlueMatt> its a bit simpler to understand
18:02 < BlueMatt> and it doesn't suffer from the "we closed out because of a 10-block feerate spike for an htlc that times out in a day"
18:02 < BlueMatt> which does worry me here
18:08 < BlueMatt> https://github.com/lightningdevkit/rust-lightning/pull/1056#issuecomment-982212387
21:46 -!- trev [~trev@user/trev] has joined #bitcoin-rust
--- Log closed Tue Nov 30 00:00:47 2021