--- Log opened Tue May 05 00:00:11 2020
00:09 -!- Netsplit *.net <-> *.split quits: wraithm, justinmoon, neonknight64, Blackwolfsa4
00:12 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
00:14 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
00:15 -!- justinmoon [~quassel@157.245.122.126] has joined #rust-bitcoin
00:15 -!- Blackwolfsa4 [~Blackwolf@195.159.29.126] has joined #rust-bitcoin
00:15 -!- neonknight64 [~neonknigh@195.159.29.126] has joined #rust-bitcoin
00:15 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #rust-bitcoin
00:53 -!- titanbiscuit [~tbisk@45.87.213.246] has quit [Ping timeout: 246 seconds]
00:53 -!- titanbiscuit [~tbisk@103.25.59.84] has joined #rust-bitcoin
03:22 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #rust-bitcoin
03:55 -!- jonatack_ [~jon@37.164.35.89] has joined #rust-bitcoin
03:58 -!- jonatack [~jon@37.167.8.190] has quit [Ping timeout: 260 seconds]
04:17 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
04:19 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
06:35 -!- jonatack_ [~jon@37.164.35.89] has quit [Quit: jonatack_]
06:35 -!- jonatack [~jon@134.19.179.147] has joined #rust-bitcoin
07:18 -!- Selina29Gerhold [~Selina29G@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin
07:56 -!- Selina29Gerhold [~Selina29G@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]
08:02 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:24ba:114a:98c2:e556] has joined #rust-bitcoin
08:52 -!- Arlie54Harber [~Arlie54Ha@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
08:53 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:24ba:114a:98c2:e556] has quit [Ping timeout: 272 seconds]
09:02 -!- Arlie54Harber [~Arlie54Ha@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]
09:06 -!- Jena77Hamill [~Jena77Ham@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
09:09 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:61cf:f8b9:99ca:98fa] has joined #rust-bitcoin
10:01 < elichai2> BlueMatt: I see you tagged me, about the async the fact that Rust's functions don't have side effect is both awesome(zero cost, safe etc) but sometimes suck (see all libstd try_* functions which are the same as non try but that return result and of course async functions)
10:02 < BlueMatt> mm?
10:05 < elichai2> Did you not talk about a feature that makes rust-bitcoin async? I tried to understand the tag without reading the whole convo lol
11:31 < BlueMatt> heh, nah, this was in relation to another cratej
11:31 < BlueMatt> but, i mean, that would be great....if rust had an option for it
11:31 < BlueMatt> sadly I dont think thats really practical
13:01 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:61cf:f8b9:99ca:98fa] has quit [Ping timeout: 240 seconds]
16:17 < ariard> BlueMatt: hmmmm https://github.com/rust-bitcoin/rust-lightning/pull/610#discussion_r419573822 what about a helper mimicing get_channel_keys without incrementing child_index
16:18 < ariard> and a test-only method to return channel_master_key from KeysManager
16:19 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:20 < BlueMatt> why? just expose it from InMemoryChannelKeys? the user should be able to get at the key from our implementation anyway.
16:20 < BlueMatt> sholdnt be test-only
16:20 -!- Jena77Hamill [~Jena77Ham@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 264 seconds]
16:21 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
16:26 < ariard> BlueMatt: but wait how do you get access to InMemoryChannelKeys from test-framework, it's generated at Channel creation?
16:26 -!- surja795_ [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #rust-bitcoin
16:28 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Ping timeout: 256 seconds]
16:41 < BlueMatt> ariard: ah, well we could store it at channel creation, I suppose, cause the channel calls into our code to get it
16:43 < ariard> BlueMatt: seems a bit gross unless we buffer it for test-only? like KeysInterface::get_channel_keys(id: [u8; 32]) -> InMemoryChannelKeys
16:44 < BlueMatt> right, sure, would only be in test
16:46 -!- surja795_ [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
16:46 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #rust-bitcoin
16:53 -!- jonatack [~jon@134.19.179.147] has quit [Ping timeout: 264 seconds]
16:55 -!- jonatack [~jon@37.164.75.174] has joined #rust-bitcoin
17:00 < BlueMatt> ariard: i believe in previous tests we'd just re-derived the keys
17:03 < ariard> BlueMatt: yeah but iwas before we encapsulate everything?
17:03 < ariard> almost done anyway
17:04 < BlueMatt> hmm, dunno
17:08 < BlueMatt> ariard: right. i guess I'm not sure what the right api is - maybe tweaking the channel keys generation to be more predictable and then be able to get them out of the keys manager.
17:13 < ariard> BlueMatt: yeah even for your hw, how do you communicate the keys is an issue
17:13 < BlueMatt> hmm? if its your own channel keys thats up to you
17:13 < BlueMatt> if its InMemoryChannelKeys we do need to figure it out
17:13 < ariard> let's say you have HW_1 for channel ops signing and HW_2 for cold storage signing of non-time-sensitive channel outputs
17:13 < ariard> like delayed_payment_pubkeys
17:14 < ariard> or how they communicate it's not our concern?
17:23 < BlueMatt> hmm? If they're returning a custom ChannelKeys, we should tell them which key they should use to derive from
17:23 < BlueMatt> but thats def not our problem
17:24 < BlueMatt> there's nothing we can do to help them sign the transaction aside from telling them how to do it....which we'll do.
17:25 < ariard> Gotcha, we should document well they don't have to store every keys on the same device, but how they communicate derived keys between devices is their problem
17:25 < BlueMatt> well i mean if they have a hardware wallet they should be deriving it on the device
17:25 < BlueMatt> obviously
17:26 < BlueMatt> and signing the transaction
17:26 < BlueMatt> and we should tell them how to derive the private key
17:28 < ariard> once derived you don't have to store a delayed_payment_key on the same device that your htlc_key, that what I meaned
18:45 < ariard> BlueMatt: you can go ahead with 539
18:45 < ariard> just pushed 610 without irrelevant signing methods
18:46 < BlueMatt> alright, I'll merge it once github actions passes. mind rebasing 610 on it, then?
18:47 < ariard> yeah, I will remove stuff I just add but anyway... :p
18:47 < BlueMatt> lol sorry
18:48 < BlueMatt> ariard: re: https://github.com/rust-bitcoin/rust-lightning/pull/577#discussion_r420470980 I dont get your comment
18:49 < BlueMatt> the problem is once they violate the reserve value we *must* close the channel and *must not* accept their commitment_signed
18:49 < BlueMatt> wrt the fee spike buffer we should just fail the htlc, but the reserve is different
18:50 < ariard> yeah but for fee spike buffer, you need anyway to commit the htlc right ?
18:50 < ariard> I agree on the reserve we have to fail the channel
18:50 < BlueMatt> right, but we dont need a new buffer
18:50 < BlueMatt> we already have logic for "fail this htlc once its committed"
18:50 < BlueMatt> in fact thats the only way to fail an htlc - once its committed
18:51 < ariard> I remember, everytime I just find this weird, like causing weird issues
18:51 < BlueMatt> i mean how else you gonna do it? When we receive an htlc for relay to a peer we dont have, we have to wait until its confirmed and then fail it back
18:51 < ariard> where is logic for "fail this htlc once its committed" already?
18:52 < BlueMatt> the pending_forward_state in the HTLC in the Channel
18:54 < ariard> "i mean how else you gonna do it?" assuming state machine change you could fail on-the-fly before commitment and ask party to-resign without ?
18:56 < BlueMatt> right, well we could update the spec for that
18:56 < BlueMatt> but thats really complicated - like you send a reject, but they send a commitment signed
18:56 < BlueMatt> did the commitment signed contain the reject or not?
18:56 < BlueMatt> you have no idea if it got there before they sent it or if its still in-flight
18:57 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
18:58 < ariard> no, your counterparty shouldn't send you another commitment_signed until your raa
18:59 < ariard> so Alice -> update_add_htlc, commitment_signed -> Bob, Bob -> update_policy_fail_htlc -> Alice
18:59 < BlueMatt> right, you can have them always be stuck waiting on an raa lol
18:59 < ariard> anyway I don't expect this to be change at all
18:59 < BlueMatt> oh lol like hold off on the raa and send a new cs and hope they're not *also* holding off on the raa?
18:59 < ariard> but I'm pretty sure you can leverage differences of policies implementation to provoke weird closure
19:00 < BlueMatt> i mean maybe, but boy that sounds hard to make robust
19:00 < BlueMatt> i hope not.......
19:01 < ariard> oh right you may need to cancel the whole ongoing update on both side synchronously..
19:01 < ariard> well if someone someone wants to burn his brain on this part of the spec I can tell him where to start from lol
19:04 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has joined #rust-bitcoin
19:06 < BlueMatt> lol
19:07 < ariard> ->bbl, will rebase on master once merged
19:09 < BlueMatt> k
19:45 -!- surja795 [~surja795@c-24-61-194-104.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
20:58 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
20:58 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
21:19 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 256 seconds]
21:24 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #rust-bitcoin
21:49 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
23:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
--- Log closed Wed May 06 00:00:14 2020