--- Log opened Thu Aug 27 00:00:00 2020
00:16 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
00:19 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection]
00:22 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
00:47 -!- jonatack [~jon@37.167.12.232] has joined #rust-bitcoin
00:49 -!- jonatack [~jon@37.167.12.232] has quit [Remote host closed the connection]
00:53 -!- jonatack [~jon@37.167.12.232] has joined #rust-bitcoin
02:01 -!- thunderbiscuit[m [thunderbis@gateway/shell/matrix.org/x-hamfixdaukjsctbi] has quit [Quit: Idle for 30+ days]
02:43 -!- jonatack [~jon@37.167.12.232] has quit [Read error: Connection reset by peer]
03:18 -!- Esta14MacGyver [~Esta14Mac@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
03:41 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
05:05 < andytoshi> BlueMatt: https://github.com/rust-bitcoin/bitcoin_hashes/pull/85
05:21 < elichai2> andytoshi: did we settle on 1.29 or 1.31?
05:26 < elichai2> BlueMatt: FYI, not that it matters but apparently rust doesn't use `noalias` for a while now because of miscompilations https://github.com/rust-lang/rust/issues/54878
06:03 < andytoshi> elichai2: i think we'll do 1.29 for now. 1.31 is a bit extreme
06:04 < andytoshi> i think whenever we move to 2018 we should try to jump right to 1.36 or so, IIRC things were a bit unstable for the first few versions after 1.31
06:14 < andytoshi> rust-secp MSRV bump https://github.com/rust-bitcoin/rust-secp256k1/pull/231
06:57 < andytoshi> sigh, it works on 1.22 but not on 1.29
06:59 < andytoshi> oh, no, i'm an idiot, i didn't update the travis.yml file
07:03 < elichai2> you don't mean to publish it yet, right?
07:04 < elichai2> I mean there's no point in publishing *just* a MSRV bump without any code changes
07:06 < andytoshi> yes, i mean to publish it
07:07 < andytoshi> if we wait until there are code changes that's a bit mean to users isn't it
07:07 < andytoshi> it also makes coordinating the MSRV bump across all the packages harder
07:07 < elichai2> yeah ok, I can understand that
07:07 < andytoshi> what i'd like is for people to be able to update to 0.18 or whatever, upgrade their toolchain, and upgrade to 0.19 with no further changes
07:08 < andytoshi> if we require they upgrade their toolchain **and** change their code at the same time, and something goes wrong
07:08 < andytoshi> how will they tell what went wrong
07:10 < andytoshi> lol we might've already messed this up though because i forgot thet bitcoin_hashes was a dependency of rust-secp now
07:12 < elichai2> oh, yeah we need to reorder the dependencies in rust-secp, it's hard to see when some are under `[dependencies]` and some are lower after the `[dev-dependencies]` in their own `[dependencies.*]` section
07:13 < andytoshi> i'm not totally opposed to that
07:13 < andytoshi> but it's not a huge deal cuz the dep list is so small
07:16 < andytoshi> lol in rust-secp we legitimately have a case (doctest code) where 1.22 works but 1.29 doesn't
07:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
07:17 < andytoshi> ok now i have a push that should work
07:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
08:00 < elichai2> it's weird that `VersionMessage` requires `ServiceFlags` and also a `Address` of sender+receiver when that Address also contains `ServiceFlags`
08:12 < elichai2> I see that's also how bitcoin core works
08:15 < BlueMatt> elichai2: re: noalias: yea, I recall, though they want to go back to it eventually, I think, assuming llvm gets their shit together
08:54 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
09:01 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin
09:36 < elichai2> andytoshi: https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html#const-fn-improvements I think this is enough to get compile time Tagged Hashes :)
09:36 < elichai2> (well with some modifications, because &mut isn't supported)
09:42 < andytoshi> elichai2: nice!
09:42 < andytoshi> lol we'll just have to wait a year or two
09:42 < elichai2> lol
10:30 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
10:33 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
11:03 < ariard> BlueMatt: damn, we still have awful helpers like get_remote_channel_reserve_satoshis, which are actually confusing who issue this value and on whom its applied
11:04 < ariard> what do you think about get_node_selected_channel_reserve_satoshis ? does it sounds clear enough?
11:06 < ariard> it's like to_self_delay, a security parameter picked up by other channel participants applying on your local state
11:08 -!- Esta14MacGyver [~Esta14Mac@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
11:37 < ariard> BlueMatt: pushed with a node_ prefix on channel field belonging to us, and very_verbose_key_name_for_tx_creation_keys
11:39 < ariard> I think in the future we should wrap channel field in structures and type further to rule out this kind of bug programming
11:44 < BlueMatt> ariard: hmm, node_ doesn't imply us to me. node could be us, a node, or our counterparty, a node, or some other random node.
12:00 < ariard> that would be a peer or a counterparty
12:00 < ariard> node in opposition to counterparty, do you have a better suggestion, than locally_ ?
12:04 < BlueMatt> self?
12:04 < BlueMatt> locally is def better than node, though
12:04 < ariard> yes but with local or self we have conflict with message fields where they are already and may mean the counterparty
12:05 < ariard> like open_channel.to_self_delay is the counterparty contest delay
12:06 < ariard> and local is just blurring with bolt 3 specs
12:07 < ariard> BlueMatt: better to move on and add structure on channel fields
12:09 < ariard> ->bbl
12:15 < BlueMatt> ariard: so our_
12:15 < BlueMatt> ?
12:32 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
13:08 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection]
13:09 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
13:48 -!- Lexus9Wunsch [~Lexus9Wun@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
14:34 -!- reallll is now known as belcher
16:51 < ariard> BlueMatt: what about client_ ?
16:52 < ariard> I would rather avoid pronoun, it's also confusing as we may have a contribution of us in counterparty commitment transaction
16:53 < ariard> BlueMatt: here the test case for #667 https://github.com/ariard/rust-lightning/pull/new/2020-08-concurrent-watchtowers
16:54 < ariard> so the conclusion is you were right #667 doesn't break this property, we never supported it, but I want to modify it, that's the right model
16:55 < ariard> we can prune out safely old prev_commitment_tx as if offchain coordinator sent us another update, it means prev_commitment_tx has been revoked
16:55 -!- Lexus9Wunsch [~Lexus9Wun@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 264 seconds]
16:56 < ariard> new update is +2 compare to the prev_commitment_tx
18:19 < ariard> BlueMatt: https://github.com/rust-bitcoin/rust-lightning/pull/670#discussion_r475283014 how I'm supposed to implement zero-conf channel from relay node to leaf one ?
18:20 < ariard> if forwarding_id doesn't exist at acceptance, we will currently fail
18:21 < ariard> and yes the chain can advance, and doing checks twice is kind of useless
18:22 < ariard> with regards to is_live, a relay node may enable the channel at package reception, or any kind of specialized policy
18:23 < ariard> and I think that's a performance hit in case of every successful relay, we need to take channel_state_lock anyway in process_pending_htlc_forwards?
18:26 < ariard> wrt to privacy, that sounds like a leak the previous node gets error based on configuration of forwarding channel it's not supposed to be aware of
18:26 < ariard> okay that would be a privacy leak anyway, but that's just a faster one
18:27 < ariard> really what's the advantage to blur both acceptance/relay checks, apart of fail-faster-but-maybe-incorrectly ?
18:29 < ariard> and if we fail, original sender will have to eat latency hit of a new propagation path, and failure scheduling delay of our internal node won't worsen that much
22:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
23:36 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
23:59 -!- jonatack [~jon@37.164.15.34] has joined #rust-bitcoin
--- Log closed Fri Aug 28 00:00:01 2020