--- Log opened Fri Mar 19 00:00:00 2021
01:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:06 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin
01:06 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
01:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
04:21 -!- Elody66Windler [~Elody66Wi@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
04:23 < elichai2> BlueMatt: about secp and safegcd, i'd wait another month before updating as there are a few more small improvements/changes in the queue that will hopefully also get merged (which reminds me I have a lot of stuff to review)
05:26 -!- tibo [~tibo@2400:4050:2a83:7000:4d5f:d849:34c0:baa8] has quit []
06:48 -!- Elody66Windler [~Elody66Wi@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]
06:56 < BlueMatt> elichai2: ah, fair. we also have a number of prs that should probably go in rust-secp :)
07:32 -!- jonatack_ [~jon@37.166.79.41] has joined #rust-bitcoin
07:46 < BlueMatt> ariard: did you have an opinion on the cltv_expiry_delta default/min split?
07:47 < andytoshi> lol BlueMatt if the PR is logically wrong there's not much i can be mad about
07:47 < andytoshi> i did review it
07:47 < andytoshi> i was just whining that it gummed up my commit checker
07:47  * BlueMatt is vaguely impressed that four of us managed to misread the code in core when the correct function was linked in the pr :(
07:51 < BlueMatt> andytoshi: also, can we enforce whatever your commit checker's rules are in ci?
07:51 < BlueMatt> andytoshi: I dont think anyone would complain if the ci enforced that commits were based on master at least X commits ago
07:54 < BlueMatt> has anyone spent any time trying to do a Transaction replacement that doesnt allocate in common situations? I think that would make a really huge difference in things like block and transaction deserialization and user memory overhead
07:55 < BlueMatt> either a no-copy deserialization mode *or* a preallocated mode which only allocates if you have more than X inputs/outputs or scripts larger than Y
07:55 < BlueMatt> like core's prevector
07:56 < BlueMatt> no-copy block deserialization would be *awesome*
07:57 < andytoshi> BlueMatt: i can give it a shot. my commit checker runs a giant test matrix on every single commit, it's pretty time intensive even on my 64-core machine
07:58 < andytoshi> but i can at least do a small test matrix (which would'e caught this issue, which was that your commits did not have some feature flags on account of them being so old)
07:58 < BlueMatt> andytoshi: hmm, maybe at least run cargo check in ci? we do that in rust-lightning
07:58 < andytoshi> yeah that's not a bad idea
07:58 < BlueMatt> though I think we actually rebase on latest upstream and *then* run cargo check on each commit in ci
07:58 < andytoshi> i'd like to do both :P
07:58 < BlueMatt> heh, or that
07:59 < BlueMatt> cargo check is nice and quick
07:59 < andytoshi> yep this sounds very reasonable
07:59 < BlueMatt> if you're lazy, these are our two scripts https://github.com/rust-bitcoin/rust-lightning/tree/main/ci
09:23 -!- jonatack_ [~jon@37.166.79.41] has quit [Read error: Connection reset by peer]
09:59 -!- sanketcell_ [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 245 seconds]
10:00 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 276 seconds]
10:58 -!- jonatack_ [~jon@37.166.79.41] has joined #rust-bitcoin
12:06 -!- belcher_ is now known as belcher
12:25 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
12:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
12:27 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin
12:27 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
12:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
12:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
12:43 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #rust-bitcoin
12:57 -!- jonatack_ [~jon@37.166.79.41] has quit [Remote host closed the connection]
12:58 -!- jonatack_ [~jon@37.166.79.41] has joined #rust-bitcoin
13:07 -!- jonatack__ [~jon@37.165.139.59] has joined #rust-bitcoin
13:10 -!- jonatack_ [~jon@37.166.79.41] has quit [Ping timeout: 256 seconds]
13:39 -!- jonatack__ [~jon@37.165.139.59] has quit [Quit: jonatack__]
13:41 -!- jonatack [~jon@37.165.139.59] has joined #rust-bitcoin
13:47 -!- fanatid [5f343dd6@95-52-61-214.dynamic.murmansk.dslavangard.ru] has joined #rust-bitcoin
13:50 -!- fanatid [5f343dd6@95-52-61-214.dynamic.murmansk.dslavangard.ru] has quit [Client Quit]
14:18 -!- jonatack [~jon@37.165.139.59] has quit [Ping timeout: 240 seconds]
14:58 < ariard> BlueMatt: i dunno about your "must-be-back-online-every-X" reasoning around https://github.com/rust-bitcoin/rust-lightning/pull/849#discussion_r597995251]
14:59 < BlueMatt> ariard: correct, but we don't expose the cltv time of all currently-in-flight htlcs to the user
15:00 < ariard> or you might allow to be back online every X but at some point you should be back lower than X
15:00 < ariard> otherwise you won't be on time for CLTV_CLAIM_BUFFER
15:00 < BlueMatt> and even if we did, it'd be race-y - you have to (a) disable forwarding, then (b) check the cltvs, then (c) shutdown, scheduling when to go back online
15:00 -!- jonatack [~jon@37.165.139.59] has joined #rust-bitcoin
15:00 < ariard> like if it's block 100 and expiration=120, back every X=7 doesn't work
15:00 < BlueMatt> on the other hand, I think my statement is correct in that as long as you *are* online once every CLTV_DELTA blocks you're (mostly) ok
15:00 < BlueMatt> modulo desire to rbf, of course
15:01 < ariard> yeah modulo rbf
15:01 < BlueMatt> I could expland the comment and note that you should be online a ways more often to get rbf time, but I dont think trying to explain the full nuance of htlc timeouts is worth it
15:01 < ariard> hmmmm i think it depends when you start to go offline
15:01 < ariard> because if you go offline CLTV_DELTA + 10
15:02 < ariard> your model work if you assume you go offline as soon as you committed the htlc
15:02 < ariard> in practice you might be around for few blocks then disconnect
15:02 < BlueMatt> i think the solution to that is to have a forwarding_disabled flag
15:02 < BlueMatt> which we currently dont have (though you could set infinite fee, I think)
15:03 < BlueMatt> but, again, thats a lot of nuance that I dont think is worth communicating
15:03 < BlueMatt> if users really dont want to be online more often than once a week, they should set cltv_delta and csv_delay to 1 week and move on
15:03 < ariard> that's a lot of nuances for now
15:03 < BlueMatt> then they dont have to think about it
15:03 -!- jonatack [~jon@37.165.139.59] has quit [Read error: Connection reset by peer]
15:03 < ariard> they should set cltv_delta to a week for sure
15:03 < BlueMatt> if we try to explain how you have to track all your in-flight htlcs and think about when they time-out, then you have a lot of code for....nothing
15:04 < BlueMatt> when they should just turn up the delta and move on
15:04 < ariard> i think it's more about mobile-vs-routing-node
15:04 -!- jonatack [~jon@37.165.139.59] has joined #rust-bitcoin
15:05 < ariard> like won't make sense to check your in-flight HTLCs for a mobile and decide your onliness requirement dynamically
15:05 < ariard> awful ux
15:05 < BlueMatt> somewhat, but if you're mobile, you can just jack up the cltv_delta
15:05 < BlueMatt> routing, the cltv_delta docs are correct now, cause you always have htlcs in flight
15:05 < BlueMatt> mobile, you dont care what it is cause you dont want to forward
15:06 < ariard> yeah that's my point
15:07 < BlueMatt> right, but I think in *either* case, the response you have to the docs is correct
15:07 -!- jonatack [~jon@37.165.139.59] has quit [Read error: Connection reset by peer]
15:07 -!- jonatack_ [~jon@37.165.139.59] has joined #rust-bitcoin
15:07 < ariard> let's go forward with your reasoning
15:07 < BlueMatt> a mobile user reading it would increase the cltv_delta to something big (fine, they dont want to forward, fine outcome) and a routing node would read it and think about it the same as the csv_delay (which is correct)
15:07 < ariard> i'm still thinking if you're a big node, better to be always online and spot weird behaviors as soon as you can
15:07 < ariard> not exactly, depend risk of realization of each
15:08 < BlueMatt> yea, I mean I can also expand it to talk about rbf if you want
15:08 < ariard> account for timevalue
15:08 < ariard> fine for me as long as you mention the CLTV_CLAIM_BUFFER/rbf
15:12 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Write error: Connection reset by peer]
15:12 < BlueMatt> ok, I'll note rbf
15:12 < BlueMatt> does the current wording not capture CLTV_CLAIM_BUFFER correctly?
15:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 264 seconds]
15:14 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin
15:14 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
15:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
15:14 < BlueMatt> ariard: ^?
15:18 < ariard> just add a Big Comment on #845
15:18 < ariard> let me see
15:23 < ariard> BlueMatt: "plus some margin to allow us enough time to broadcast and confirm a transaction" minus some margin ?
15:24 < BlueMatt> yea
15:24 < BlueMatt> well, yes, sorry
15:26 < ariard> otherwise looks good to mw
15:45 < BlueMatt> cool, thanks
16:00 -!- jonatack_ [~jon@37.165.139.59] has quit [Read error: Connection reset by peer]
16:36 < BlueMatt> ariard: can you ack 849?
16:36 < BlueMatt> I split the default/min and tweaked the wording
16:48 < ariard> yeah doing
16:48 < BlueMatt> thanks!
17:17 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #rust-bitcoin
20:22 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:20 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
--- Log closed Sat Mar 20 00:00:01 2021