--- Log opened Wed Nov 28 00:00:36 2018
01:06 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nyoendiquaxofjgb] has joined #rust-bitcoin
08:05 -!- TamasBlummer1 [~Thunderbi@p200300DD67286B45C09D22D3048757B8.dip0.t-ipconnect.de] has joined #rust-bitcoin
08:07 -!- TamasBlummer [~Thunderbi@p200300DD67286B60C09D22D3048757B8.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
08:07 -!- TamasBlummer1 is now known as TamasBlummer
08:54 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin
08:59 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
08:59 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin
09:19 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
09:22 < stevenroose> dpc: sorry I pushed an update to bitcoincore-rpc without a PR because I forgot to update the repo URL in the Cargo.toml file before publishing. Someone sent me an e-mail about that.
09:22 < stevenroose> is fixed now
09:26 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin
09:36 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
09:46 < dpc> Fine with me. No need it to go through me with anything.
10:11 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #rust-bitcoin
10:14 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 246 seconds]
10:17 < BlueMatt> ariard: I think the approach is to not care for old states
10:17 < BlueMatt> ariard: if our counterparty broadcasts an old state with htlcs in it, we dont really care, we will claim them cause the state was revoked
10:18 < BlueMatt> since we got the money anyway, we probably just want to fail it
10:18 < BlueMatt> even if they broadcast the HTLC-Success tx and we have the preimage, failing it instead of claiming it is no big deal
10:19 < BlueMatt> soooooo...that means when we close a channel, we just need to go to the Channel object and get the current set of HTLCs and make sure we track *those*
10:19 < BlueMatt> (in other words, the Channel object can just give Channel::channel_monitor an up-to-date list of current HTLCs and then those will get updated with the ChannelMonitor as normal
10:41 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin
10:50 -!- grubles_ is now known as grubles
12:40 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-nyoendiquaxofjgb] has quit [Quit: Connection closed for inactivity]
13:11 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]
13:42 -!- grubles [~grubles@unaffiliated/grubles] has joined #rust-bitcoin
15:41 < ariard> BlueMatt: don't worry I got it we don't care about old states, I didn't yet implement pruning of old states in ChannelMonitor because was looking how to handle well duplicate hash on non-revoked channel
15:42 < ariard> BlueMatt: see https://github.com/rust-bitcoin/rust-lightning/pull/198#issuecomment-442302566
15:42 < ariard> but sorry for the review mess, lot of refactors on this one
17:01 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
17:57 < BlueMatt> ariard: I'm really confused what the disconnect is here, not that I've tried to implement but can you not just add an HTLCSource to LocalSignedTx::htlc_outputs and add a similar bit in remote_claimable_outputs (or, maybe a new map that doesn't even get pruned like remote_claimable_outputs but instead is literally just only for the latest remote commitment tx)?
17:58 < BlueMatt> shouldnt you be able to keep that up to date with the usual provide_latest_{remote,local}_commitment_tx_info calls and then just copy it over in merges without any api changes to the update_add stuff?
17:59 < BlueMatt> and if an older transaction gets included, you just go fail all the current HTLCSources available
17:59 < BlueMatt> this way you track it on a per-output basis, but only for the latest commitment transactions
18:01 < BlueMatt> and tracking by that also means you get the multiple-duplicate-hashes property for free, though obviously if they broadcast an old state we'll fail all the duplicate-hash things together, but thats ok
18:01 < BlueMatt> there's still no cross-contamination
18:17 < ariard> BlueMatt: was working on somehting similar like that, already removed the api changes of update_add, agree it was useless
18:17 < ariard> HTLCOutputIncommitment.transaction_output_index should be a reliable way to avoid duplicate-hash meddling
18:24 < BlueMatt> indeed :)
18:40 -!- Tralfaz [~none@104.248.145.220] has quit [Quit: Leaving]
18:45 < ariard> BlueMatt: hmmm but bip69 ordering blocks to build a (HTLCSource, HTLCOutputInCommitment)
18:45 < ariard> *association
18:46 < ariard> in build_commitment_transaction
18:46 < ariard> after ordering, we can't dissociate htlc outputs as it isn't exclude that they can have same script_pubkey (and amout)
18:47 < BlueMatt> so make build_commitment_transaction return them in (&HTLCSource, HTLCOutputInCommitment) pairs?
18:47 < BlueMatt> iirc the sorter sorts in (TxOut, X) pairs
18:47 < BlueMatt> so you can change X
18:47 < BlueMatt> bbl
18:56 < ariard> heeey in fact it already implemented by sort_outputs, nothing to change
19:16 < ariard> oky should work, gonna take some rest, will be back tomorrow morning to finish it
19:53 -!- _cryptosignal_me [~John@91.245.77.21] has joined #rust-bitcoin
20:27 -!- _cryptosignal_me [~John@91.245.77.21] has quit [Ping timeout: 250 seconds]
--- Log closed Thu Nov 29 00:00:37 2018