--- Log opened Mon Mar 23 00:00:30 2020
01:56 -!- vindard [~vindard@190.83.165.233] has quit [Quit: No Ping reply in 180 seconds.]
01:57 -!- vindard [~vindard@190.83.165.233] has joined #rust-bitcoin
02:13 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #rust-bitcoin
02:40 -!- Kiminuo [~mix@141.98.103.134] has quit [Ping timeout: 240 seconds]
02:47 -!- Kiminuo [~mix@141.98.103.108] has joined #rust-bitcoin
03:23 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:04 -!- Clovis39Schuster [~Clovis39S@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin
06:26 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:7000:3186:dca0:4db5] has joined #rust-bitcoin
07:06 -!- Clovis39Schuster [~Clovis39S@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds]
08:19 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #rust-bitcoin
08:48 -!- Kiminuo [~mix@141.98.103.108] has quit [Ping timeout: 265 seconds]
09:00 < stevenroose> Request for review: https://github.com/rust-bitcoin/rust-bitcoin/pull/413
09:44 < andytoshi> yeah, i think i concept ack your use of the dependency. let me review the code
09:47 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin
10:06 < andytoshi> ok ack
10:15 -!- Kiminuo [~mix@141.98.103.76] has joined #rust-bitcoin
10:50 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:58 < BlueMatt> ariard: awesome! thanks for keeping up the push on this stuff :) hopefully I can find time to get a bunch of progress on anchor stuff out soon
11:55 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has joined #rust-bitcoin
14:31 < ariard> BlueMatt: while refactoring it occurs to me than in fact it makes no sense to initiate broadcast of a prev valid commitment transaction ?
14:31 < BlueMatt> hmm?
14:31 < ariard> because if we have to broadcast a commitment due to HTLC-timeout will always going to pickup latest valid one
14:31 < BlueMatt> yes, I think? we should absolutely only ever broadcast the current latest local commitment transaction
14:31 < BlueMatt> but I'm not sure what you're saying?
14:32 < ariard> hmmm well in fact we have code maybe which shouldn't be there, like generating htlc-txn for prev valid local commitment
14:32 < ariard> in fact that's code only exerce in our testing framework but never should be triggered in deployment ?
14:33 < BlueMatt> ariard: no, its for secondary monitors. it def can be
14:33 < BlueMatt> eg if a channel is currently being updated, but we havent yet revoked the previous state
14:33 < BlueMatt> and then we hit an HTLC timeout
14:33 < BlueMatt> then the remote copy of the monitor may broadcast what, to us, is the previous state
14:33 < BlueMatt> and we need all monitors to know how to spend those
14:35 < ariard> yeah but in that case for remote monitor it's current_local_signed_commitment_tx, even it's the prev one from ChannelManager one
14:36 < BlueMatt> sure, but both need to know how to generage HTLC txn on top, especially if we can rbf/cpfp-bump them
14:36 < BlueMatt> eg after anchor those htlc txn may be csv'd
14:36 < BlueMatt> so if the remote copy goes offline, local one needs to be able to broadcast those
14:36 < ariard> right, even if in theory at least one them should suffice to generate HTLC
14:37 < ariard> but then you may race conditon between seeing onchain transactions and receiving an update and pruning out HTLC datas
14:37 < BlueMatt> no, cause it may generate, go offline before one block csv is up, and never be able to broadcast htlc txn
14:38 < ariard> yeah and you also have the case where htlc timeout, local commitment is broadcast, you receive update from local ChannelMonitor, if you prune out HTLC for prev
14:38 < ariard> you won't be able to generate HTLC-transactions for a bump
14:38 < ariard> okay I agree, will try to document this somewhere, that's good to know
14:39 < BlueMatt> yep
14:39 < BlueMatt> cool, yea, the whole channelmonitor setup is kinda hard to conceptualize
14:39 < ariard> I know, will do a big doc PR when all refacto done
14:39 < BlueMatt> cool
15:36 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-161-135.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:46 -!- yancy [~root@2400:8902::f03c:92ff:fe70:a5ac] has quit [K-Lined]
15:47 -!- yancy [~root@2400:8902::f03c:92ff:fe70:a5ac] has joined #rust-bitcoin
17:31 < ariard> BlueMatt: https://github.com/rust-bitcoin/rust-lightning/pull/559, I can split pr in two, one for local, one for HTLC, but that would means
17:31 < ariard> introducing twice anti-duplicata temporary logic, which doesn't make it easier to review
17:31 < ariard> but let me know if you have suggestion for easing review
17:33 < BlueMatt> ariard: thanks. will take a look
17:44 < BlueMatt> ariard: the very first commit still passes the raw transaction from LocalCommitmentTransaction to ChannelKeys?
17:44 < BlueMatt> ariard: I thought we'd agreed to not do that
17:53 < ariard> BlueMatt: yeah we agreed and then when doing it seems to me gross to pass the whole LocalCommitmentTransaction, you still to access raw transaction inside ChannelKeys
18:05 -!- mauz555 [~mauz555@2a01:e0a:56d:9090:7000:3186:dca0:4db5] has quit []
18:48 < BlueMatt> ariard: the transaction itself is even uglier
18:48 < BlueMatt> by a lot
18:51 < BlueMatt> if it were passed in pieces with a transaction and the remote signature, maybe that would be better, but the current version passes the transaction with a witness partially filled in with a rust-lightning undocumented, kinda-hacky format
18:51 < BlueMatt> that is wayyyyyyyyyyyyyyy worse
18:53 < BlueMatt> and even if we did pass the transaction we'd still want to pass a LocalCommitmentTransaction-like thing cause we'd want to provide an easy API to generate the signed transaction
18:54 < BlueMatt> also, LocalCommitmentTransaction is a relatively simple API/struct thats not unreasonable to make pub imo?
20:50 < ariard> BlueMatt: okay okay what you have in mind is passing LocalCommitmentTransaction to sign_local_commitment
20:50 < ariard> and it's up to implementation to extract transaction, but that means know they have to care about LocalCommitmentTransaction?
20:51 < ariard> I do understand about LocalCommitmentTransaction and having a secure API to probe for witness-and-like but integrating with ChanSigner cleanly is the bottleneck IMO
20:52 < ariard> nevermind will try to rework #559 toward this sense
21:32 -!- fiatjaf [~fiatjaf@2804:7f2:2a82:7a59:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds]
21:37 -!- fiatjaf [~fiatjaf@2804:7f2:2a82:7a59:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin
21:46 < ariard> BlueMatt: see #560, not everything, but on top of #559 it's likely ~10 commits to move private keys from ChannelMonitor to ChanSigner
21:47 -!- fiatjaf [~fiatjaf@2804:7f2:2a82:7a59:ea40:f2ff:fe85:d2dc] has quit [Remote host closed the connection]
21:47 < ariard> biggest hurdle it's to update SpendableOutput descriptor to only hand what needed to derive private keys but not keys in themsevles
21:48 < ariard> now they're all in one place shouldn't be hard, also have to update test framework to access signer
21:53 -!- fiatjaf1 [~fiatjaf@2804:7f2:2a82:7a59:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin
23:10 -!- Kiminuo [~mix@141.98.103.76] has quit [Ping timeout: 256 seconds]
23:22 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
23:23 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
--- Log closed Tue Mar 24 00:00:31 2020