--- Log opened Wed Mar 18 00:00:25 2020
01:20 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Quit: ZNC 1.7.5 - https://znc.in]
01:21 -!- real_or_random [~real_or_r@173.249.7.254] has joined #rust-bitcoin
01:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
01:27 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
03:00 -!- raj_ [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined #rust-bitcoin
03:00 -!- willcl_ark__ [~quassel@95.211.225.220] has joined #rust-bitcoin
03:02 -!- kanzure_ [~kanzure@unaffiliated/kanzure] has joined #rust-bitcoin
03:04 -!- Netsplit *.net <-> *.split quits: raj_149, willcl_ark_, kanzure
03:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
03:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
04:04 -!- Herman63Mills [~Herman63M@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin
05:22 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:e899:b041:3610:2bad] has joined #rust-bitcoin
06:12 -!- kanzure_ is now known as kanzure
06:22 < willcl_ark> does RL have any spontaneous send capability currently? (i.e. Sphinx Send, pay-to-pubkey etc.)
06:43 -!- mauz555_ [~mauz555@88.125.182.66] has joined #rust-bitcoin
06:44 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [Ping timeout: 246 seconds]
06:46 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #rust-bitcoin
06:47 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:e899:b041:3610:2bad] has quit [Ping timeout: 272 seconds]
06:48 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:3105:3e60:51ab:b6a3] has joined #rust-bitcoin
06:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
06:51 -!- mauz555_ [~mauz555@88.125.182.66] has quit [Ping timeout: 264 seconds]
07:02 -!- Herman63Mills [~Herman63M@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 250 seconds]
07:25 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:3105:3e60:51ab:b6a3] has quit []
07:51 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-ohgqiwzgrnjsekqd] has quit [Ping timeout: 245 seconds]
07:54 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-gnrcyozrihwiiogl] has joined #rust-bitcoin
08:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
09:50 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has joined #rust-bitcoin
09:52 < BlueMatt> willcl_ark: no. there is no standard for it (lnd shipped it without even bother to write up what they did, let alone standardize)
09:53 < BlueMatt> willcl_ark: I believe val was looking into implementing it anyway, tho
09:53 < BlueMatt> (its pretty trivial, so I cant imagine it would be hard to implement)
09:53 < willcl_ark> BlueMatt: Ok thanks for clarifying.
09:54 < willcl_ark> I did make a plugin for C-Lightning which achieved similar, so in the meantime might re-implement for RL...
09:54 < BlueMatt> https://github.com/rust-bitcoin/rust-lightning/issues/505 :)
09:54 < ariard> willcl_ark: maybe ping val on it and write down a standard :)
09:56 < BlueMatt> ariard: was it really substantially easier to copy the whole Storage into OnChainTxHandler? All of the data in it is provided by the ChannelKeys interface anyway
09:56 < BlueMatt> (if it was, thats fine, its just kinda ugly)
09:56 < BlueMatt> I mean I assume we're about to delete it anyway, but still
09:56 < willcl_ark> val's proposal there looks pretty similar to my previous attempt, except because I wasn't using the standard onion construction I had to do DH each side to get a shared key and a few other bits... with onion looks a lot simpler :)
09:56 < ariard> BlueMatt: it's temporary, I want to dry it up in next PRs
09:56 < BlueMatt> ok, fair enough
09:56 < ariard> I think it should be merged with KeysInterface
09:57 < ariard> and just left in ChannelMonitor stuff to detect and link outpoints to be claimed (like remote_commitment_txid)
09:58 < BlueMatt> hmm? you mean merge ChannelKeys into KeysInterface? I disagree - ChannelKeys is the thing you'd want to run on a hardware wallet, KeysInterface can be done locally.
09:58 < BlueMatt> except *maybe* node_secret, but thats super awkward to move out
10:02 < ariard> BlueMatt: I'm thinking about extending ChannelKeys with signing capabilities to cover the whole range of txn issued in OnchainTxHandler::generate_claim_tx
10:02 < ariard> and that would let dry up Storage from any SecretKey
10:02 < BlueMatt> ariard: yes, in the long term CHannelKeys should never expose SecretKey and should only sign
10:03 < BlueMatt> that was always the intent
10:03 < BlueMatt> in Channel already the SecretKeys are never accessed except via the sign functions.
10:03 < BlueMatt> (thats why I was surprised that you still accessed the in this patch, but its ok for that to come later)
10:03 < BlueMatt> 540 doesn't currently build for me, btw
10:04 < ariard> BlueMatt: I pushed an update due to some type ascription like 2min
10:04 < BlueMatt> yes, I just pulled
10:04 < ariard> tip?
10:04 < BlueMatt> 45db495e79ba5737b41c6a4fa469660275a1238b
10:04 < ariard> hmmmm, it builds for me locally
10:05 < BlueMatt> did you cargo test or only cargo check?
10:05 < ariard> let me check, need to verify with the right toolchain
10:06 < BlueMatt> also, be careful with your rebases, you keep reverting changes that were made on master when you rebase :(
10:07  * BlueMatt -> breakfast
10:08 < ariard> BlueMatt: okay I build with both 1.34.2 and 1.42.0
10:09 < ariard> BlueMatt: yeah about the clone? There is few others places where they are superflous and confuzzed myself
10:12 < BlueMatt> ariard: yea, in this case the clone, but you've done it a few times recently
10:12 < BlueMatt> ariard: the error i saw on master was lightning/src/ln/channelmonitor.rs:2722:44
10:12 < BlueMatt> you need OnchainTxHandler::<ChanSigner> not OnchainTxHandler<ChanSigner>
10:12 < BlueMatt> that shouldnt build on *any* version of rust
10:13 < BlueMatt> (note that cargo check does not check any of the tests, those can be bogus and it wont catch it)
10:30 < ariard> BlueMatt: hmmm OnchainTxHandler::<ChannelKeys> doesn't work because trait object isn't known at compilation?
10:32 < BlueMatt> right, you cant call a function without a concrete type? InMemoryChannelKeys or whatever should work
10:32 < BlueMatt> same at 2744
10:33 < BlueMatt> and 2764
10:34 < BlueMatt> note that a bunch of tests fail afer you fix build.
10:34 < BlueMatt> lightning/src/ln/channelmonitor.rs:1721:13
10:35 < BlueMatt> ariard: how did you build it? cargo build/cargo check do not build tests, I dont get how this ever could have built? ChanSigner (which is referred to on that line) isnt even defined
10:40 < ariard> BlueMatt: I've a fix for tests, it's chanmonitor deserialization consistency choking on rest of Storage serialization in OnchainTxHandler
10:42 < BlueMatt> ariard: no its not? lightning/src/ln/channelmonitor.rs:1721:13 is in broadcast_by_local_state()?
10:43 < BlueMatt> or do you mean there's more issues? feel free to push and I'll take a look.
10:46 < ariard> hmmm investigating right now, I'm hitting 1721 too
10:57 < ariard> okay 1721 I found it, but there is another one with script generation, surely inverted some derivation somewhere
11:08  * BlueMatt -> bbl. will review again a bit later once tests past and hopefully we can get it today/tomorrow.
11:29 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has quit [Quit: Sleep mode]
11:32 < ariard> BlueMatt: kool, found the bug, 2fea557 pass all tests
11:32 < ariard> it was effectively a key misuage due to key name being loosely informative in LocalCommitmentTx (there is both our/their pubkeys blurred)
11:33 < ariard> for watchtower support I'm thinking than all this provide_remote/provide_latest should be to some common interface
11:39 < BlueMatt> ariard: yea, I'm gonna clean a bunch of that stuff up anyway, there's just too many in-progress refactors in that area :/
11:43 < ariard> BlueMatt: I know, finishing spendable outputs reorg-safety rn, and then I'm fine enough to pause refactoring there and get static_key+anchor_outputs
11:43 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has joined #rust-bitcoin
11:50 < BlueMatt> cool. alright.
11:51 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has quit [Quit: Sleep mode]
11:59 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has joined #rust-bitcoin
12:00 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:9cc8:c06d:d41d:695e] has quit [Client Quit]
12:23 < BlueMatt> ariard: I think the way the local commitment tx generation was moved here makes it *harder* to move the signing of it into ChannelKeys, not easier. https://github.com/rust-bitcoin/rust-lightning/pull/540/commits/23d358b1d231f446f1b55384fa1115b5d50d8e7e#r394586181
12:24 < BlueMatt> in general, clone()ing a bunch of complicated structs in this logic should be a pretty clear indication that our data-ownership model is very confused and needs fixing.
12:47 -!- varioust [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has joined #rust-bitcoin
12:51 < ariard> BlueMatt: right, isn't going to break get_latest_local_commitment_txn? IIRC that's what the reason I keep the add_local_sig in broadcast_by_local_state
12:53 < BlueMatt> ariard: right, get_latest_local_commitment_txn needs to move out of channel/channelmanager and go into channelmonitor only. thats the last TODO for removing the channelmonitor from inside Channel.
12:54 < BlueMatt> ariard: would it help if I whip up a quick patch to remove it in 10 minutes?
12:54 < ariard> hmmm so I can't pass the cur_local_tx, if we don't want to break get_latest_local_commitment? refactor dependency :/
12:54 < BlueMatt> would be an easy rebase
12:54 < ariard> I can rebase yeah
12:55 < BlueMatt> ok, gotta help cook for 30 seconds then I'll do it
12:55 < BlueMatt> should be easy
12:55 < BlueMatt> (tm)
12:55 -!- varioust [~varioust@rrcs-76-79-47-154.west.biz.rr.com] has quit [Quit: varioust]
13:03 < ariard> BlueMatt: I'm still brooding on spendable output delay, moving logic in OnchainTxHandler, I'm half convinced
13:04 < ariard> or said differently that's a another type of task than detection (ChannelMoniitor), generating&bumping (OnchainTxHandler), it's just sending back outpoints to the wallet
13:04 < ariard> so any txn which should be catch up by our filters, we should just have some kind of basic IsMine logic
13:05 < ariard> that doesn't matter than  justice/claim tx may vary, they all pay to destination_script
13:07 < BlueMatt> you mean where to generate them?
13:08 < BlueMatt> I dont think I have a strong preference, tbh, probably channelmonitor?
13:08 < ariard> yeah right now it's spread between ChannelMonitor and OnchainTxHandler
13:08 < ariard> yeah just to avoid duplicata due to rescan
13:08 < ariard> which should be good if there is a buffer for reorg-safety
13:13 < BlueMatt> def want a buffer
13:13 < BlueMatt> i mean whever it makes more sense in the context of the datastructures that exist, imo
13:15 < ariard> another OnchainEvent, MaturingSpendableOutput
13:31 < BlueMatt> ariard: it doesnt pss tests yet and isnt complete, but this is what I was thinking - https://github.com/TheBlueMatt/rust-lightning/tree/2020-03-no-chan-mon
13:32 < BlueMatt> essentially just drop any access to the latest local commitment txn and let channelmonitor broadcast them via an event that says "channel is closed"
13:34 < BlueMatt> I'll fix it/finish it after lunch
13:42 < ariard> BlueMatt: SGTM, will tweak it a bit after rebase to send it directly to OnchainTxHandler
14:23 -!- Merle66White [~Merle66Wh@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin
14:24 < BlueMatt> thanks ariard!
16:01 < BlueMatt> ariard: are you gonna rebase 532?
16:04 < ariard> BlueMatt: hmmm I'm simplifying spendable output, will take it on top
16:04 < ariard> like finally move to something way simpler to reason on
16:04 < BlueMatt> ah, ok
16:04 < BlueMatt> I'm almost done fixing the tests on the no-chan-mon branch above
16:04 < BlueMatt> then I'll actually rip out the channel monitor from Channel
16:04 < BlueMatt> that should make 540 way simpler
16:05 < ariard> yeah will rebase after, but new spendable output branch built directly from master so can go independently
16:06 < BlueMatt> cool, right.
16:08 -!- Merle66White [~Merle66Wh@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 250 seconds]
19:07 < ariard> BlueMatt: thanks for #551, will rebase #540 on top of it tmrw
19:08 < ariard> see #552, that's a huge simplification of our spendable output detection logic, and it subsumes some weirdness like to_remote_rescue or closing_tx parsing
19:09 < BlueMatt> ariard: alright, cool, thanks. may not get to it until tomorrow
19:10 < ariard> BlueMatt: yeah sure, also plan to do a first review of static_remotekey tmrw
19:31 -!- fiatjaf1 [~fiatjaf@2804:7f2:2981:26c1:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin
19:32 -!- fiatjaf [~fiatjaf@177.206.42.162.dynamic.adsl.gvt.net.br] has quit [Ping timeout: 246 seconds]
19:52 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
19:55 < BlueMatt> ariard: note that static_remotekey is (currently) based on MPP, let me know if you think its worth trying to rebase. I dont think the MPP pr is too much, but I can delay it further.
--- Log closed Thu Mar 19 00:00:27 2020