--- Log opened Sat Apr 18 00:00:55 2020 01:33 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:48c6:58e7:fb60:7f0a] has joined #rust-bitcoin 03:06 -!- Jess63Thompson [~Jess63Tho@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 03:45 -!- Kiminuo [~mix@141.98.103.76] has joined #rust-bitcoin 07:37 -!- Jess63Thompson [~Jess63Tho@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 264 seconds] 11:00 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 11:07 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 11:46 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 11:53 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #rust-bitcoin 12:16 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 12:28 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 12:48 < BlueMatt> ariard: I think it makes most sense to move the LocalCommitmentTransaction storage back to ChannelMonitor 12:49 < BlueMatt> ariard: ChannelMonitor's job is to monitor the chain, and then once it learns of something worth spending, provide the data for how to spend it to OnchainTxHandler - it is not OnchainTxHandler's job to track the data required to spend on chain transactions until it comes time to spend them 12:49 < BlueMatt> this resolves a bunch of complexity that exists on the boundry today - namely a bunch of duplciated storage between LocalSignedTx and LocalCommitmentTransaction 13:44 < BlueMatt> ariard: so what I've got is a) make it so that the local_commitment_txn stuff in channelmonitor is initialized at construction, then b) when we go to broadcast the local commitment tx, .take() them and hand them over to onchain.rs - that way once we are trying to spend the funding output, onchaintx.rs "owns" the local commitment tx that is being broadcast, and prior to that channelmonitor.rs "owns" knowledge of how to spend the funding 13:44 < BlueMatt> transaction output 13:44 < BlueMatt> i think thats appropriate. 13:51 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:48c6:58e7:fb60:7f0a] has quit [Remote host closed the connection] 13:53 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:48c6:58e7:fb60:7f0a] has joined #rust-bitcoin 14:06 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 256 seconds] 14:07 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin 15:56 -!- rjected [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has quit [Ping timeout: 260 seconds] 15:58 -!- rjected [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has joined #rust-bitcoin 16:27 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 16:27 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 17:39 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:48c6:58e7:fb60:7f0a] has quit [Remote host closed the connection] 18:00 -!- rjected [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 18:00 -!- rjected_ [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has joined #rust-bitcoin 21:19 -!- fiatjaf [~fiatjaf@2804:7f2:2a81:4a17:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 246 seconds] 21:20 -!- fiatjaf [~fiatjaf@2804:7f2:2981:d3e0:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 23:13 -!- Netsplit *.net <-> *.split quits: stevenroose 23:15 -!- Netsplit over, joins: stevenroose 23:50 < ariard> BlueMatt: hmmm and so how do you communicate LocalCommitmentTransaction between onchain - channelmonitor, I feel a bit gross to enlarge InputDescriptor again 23:51 < ariard> what's your branch? I can try to melt it inside #56{0-2} 23:52 < ariard> I agree that current boundary isn't clear today, there is a lot of stuff we don't need to store in ChannelMonitor, like pubkeys 23:53 < ariard> And I would rather not keep remote sigs in ChannelMonitor.. 23:54 < ariard> I think we globally agree, it's more taking every piece of LocalSignedTx apart, and decide where we place it and why 23:55 < ariard> everything which is static should be OnchainTxHanddler, including keys because we can derive them from a static point if provided? 23:55 < ariard> everything which is dynamic at every commitment update should be in OnchainTxHandler 23:56 < ariard> *dynamic inside ChannelMonitor 23:58 < ariard> okay remote sigs are dynamic but maybe unsafe if someone can extract our key, maybe we should handle them to external signer for storage.. --- Log closed Sun Apr 19 00:00:57 2020