--- Log opened Tue Sep 15 00:00:19 2020 00:14 -!- jonatack [~jon@109.202.107.147] has joined #rust-bitcoin 01:09 -!- Blackwolfsa4 [~Blackwolf@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 01:09 -!- CjS77 [~caylemeis@195.159.29.126] has quit [Quit: Ping timeout (120 seconds)] 01:09 -!- Blackwolfsa4 [~Blackwolf@195.159.29.126] has joined #rust-bitcoin 01:10 -!- CjS77 [~caylemeis@195.159.29.126] has joined #rust-bitcoin 01:42 -!- jonatack [~jon@109.202.107.147] has quit [Ping timeout: 244 seconds] 02:01 -!- Guest88768 is now known as real_or_random 02:09 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Quit: ZNC 1.7.5 - https://znc.in] 02:09 -!- real_or_random [~real_or_r@173.249.7.254] has joined #rust-bitcoin 03:19 -!- Makenzie49Donnel [~Makenzie4@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin 04:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 06:57 -!- devcarrot_ [~devcarrot@pike.ops.ski] has joined #rust-bitcoin 06:57 -!- Galvas_ [uid459296@gateway/web/irccloud.com/x-zxegmahwkbniadtz] has joined #rust-bitcoin 06:57 -!- sgeisler_ [sid356034@gateway/web/irccloud.com/x-ozfyneliiihnjyjh] has joined #rust-bitcoin 06:57 -!- wallet42__ [sid154231@gateway/web/irccloud.com/x-kglqdbvrlpwzgiep] has joined #rust-bitcoin 06:57 -!- felixweis_ [sid154231@gateway/web/irccloud.com/x-ssguchidvcelwjsp] has joined #rust-bitcoin 07:00 -!- wallet42_ [sid154231@gateway/web/irccloud.com/x-cwrienyzrdytzlpc] has quit [Ping timeout: 272 seconds] 07:00 -!- devcarrot [~devcarrot@pike.ops.ski] has quit [Ping timeout: 272 seconds] 07:00 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has quit [Ping timeout: 272 seconds] 07:00 -!- Galvas [uid459296@gateway/web/irccloud.com/x-oradxrfemdnderpm] has quit [Ping timeout: 272 seconds] 07:00 -!- sgeisler [sid356034@gateway/web/irccloud.com/x-kmlknigqxbexhnot] has quit [Ping timeout: 272 seconds] 07:00 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds] 07:00 -!- felixweis [sid154231@gateway/web/irccloud.com/x-jlmbxhhtbxlzhkla] has quit [Ping timeout: 272 seconds] 07:00 -!- sgeisler_ is now known as sgeisler 07:00 -!- Galvas_ is now known as Galvas 07:00 -!- felixweis_ is now known as felixweis 07:03 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has joined #rust-bitcoin 07:07 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #rust-bitcoin 08:04 < ariard> BlueMatt: ah okay looking on it today 08:07 -!- Makenzie49Donnel [~Makenzie4@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 244 seconds] 10:22 -!- belcher_ is now known as belcher 10:44 < BlueMatt> ariard: if you get bored, rebase + fix https://github.com/rust-bitcoin/rust-lightning/pull/679#discussion_r485215178 and I think we can hit merge on that one. 10:44 < BlueMatt> rather trivial so good to Just Get It In(tm) 11:34 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 11:37 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 11:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 11:58 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 13:48 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:a36c:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 246 seconds] 15:19 < ariard> BlueMatt: yes corrected a bit, but the whole documentation should be clearly distinguishing a) the offchain manager b) the monitor coordinator c) per-channel monitor 15:19 < ariard> though per-channel monitor is more a data structure so we should describe how any implementation of b) is dealing with them 15:33 < ariard> BlueMatt: lol you finally confessed that functional_tests is a mess :p 15:34 < BlueMatt> ariard: confessed? I always said its a mess, but a mess that happens to work and build great test coverage :) 15:38 < ariard> BlueMatt: yes I agree though I feel guilty for the state in which it is, at least for newcomers... 15:38 < ariard> I promise to refactor and clean it soon 15:39 < BlueMatt> hah, i mean, I'm certainly in no huge rush to do it, maybe just move the "simple test" one to the top with a big fat comment saying "look at what we can do" 15:40 < BlueMatt> that would by itself be a nice win in usability of the file. 15:41 < ariard> I want also to do it with spec under the eyes to assert test coverage quality 15:42 < BlueMatt> ah. yea, you could do that. i mean you can also write new tests, since the current ones do like 4 things instead of testing "exactly this line in the spec" 15:49 < ariard> BlueMatt: on #690, I think this is still not the good behavior, we now check counterparty's htlc_minimum_msat on the forwarding channel 15:50 < ariard> BlueMatt: but not more holder's htlc_minimum_msat on the forwarding channel 15:50 < ariard> so someone can route HTLC under our minimum_msat on the forwarding channel ? assuming the forwarding one is under the incoming one otherwise it's rejected at acceptance 15:51 < BlueMatt> ariard: re: first note on 679, yea, we need good "high level" documentation about the whole mess. I think jkczyz plans on doing at least some, or at least as a side effect of his current work he has some nifty diagrams now, so that should help. I'm just looking for the comment to capture most of what someone looking at that function cares about. 15:51 < BlueMatt> ariard: hmm? we check our own htlc_minimum_msat on the inbound channel, it isnt relevant for the outbound one. 15:52 < BlueMatt> ariard: afaiu the only way in-protocol to limit the htlc value outbound is to fail things that pay you too much fee 15:52 < BlueMatt> but I dont think we'd need to? Someone giving us small htlcs to forward but the inbound part is higher value doesn't seem like a useful attack? 15:53 < ariard> but where we do check our htlc_minimum_msat on the outbound channel for relayed HTLC ? 15:53 < BlueMatt> oh, actually, i guess...hmm i guess you amy forward something that is below dust, which gets burnt to miner fee, but you cant claim the inbound leg cause you dont have anything on-chain to look at 15:54 < BlueMatt> we only check htlc_minimum_msat on the inbound leg, not the outbound one 15:54 < ariard> it's the inbound part being lower value and the outgoing htlc minimum msat being higher 15:54 < BlueMatt> which I think is all the protocol lets us check 15:54 < BlueMatt> no, inbound part being higher value (cause it includes our own fee) 15:54 < ariard> yeah exactly Iwas thinkg about some interference with dust 15:54 < jkczyz> BlueMatt: sure, feel free to add a comment somewhere on 649 if relevant 15:54 < ariard> or you sending message forward freely or discounted and thus DoS 15:55 < BlueMatt> *but* (and this is a protocol bug not our own) i could hand you an htlc which gives you a billion fee, and then you forward it on to a dust htlc....which i refuse to claim cause it gets burnt to miners anyway, and now you cant claim the htlc back on chain 15:55 < BlueMatt> but I'm not sure if it matters? you dont lose funds, just the peers' dust value 15:55 < BlueMatt> which was true anyway 15:55 < BlueMatt> jkczyz: nah, more of a high level comment about "we need docs/diagrams that describe the chain monitoring at a high level" 15:58 < ariard> BlueMatt: the protocol bug is you should be able to join your htlc_minimum_msat in the channel update 15:59 < ariard> because otherwise the sender picking you as relay won't be able to know about it 15:59 < BlueMatt> well thats another field in it - protocol currently doesnt let us specify it anywhere (and there is no way to limit your htlc minimum on *outbound*) 15:59 < BlueMatt> there's just no field for it 15:59 < BlueMatt> i mean we can reject any htlc we want, of course 15:59 < BlueMatt> and just refuse to relay such things. 15:59 < ariard> we should just refuse to relay such things for noww and amend the spec 16:00 < BlueMatt> hmm, why do you think? 16:00 < BlueMatt> cause htlc_minimum_msat is our "defense" against relaying un-onchain-enforcable things that are below dust limit and in theory this lets our counterparty? 16:01 < ariard> don't we reject below dust_limit in send_htlc 16:01 < ariard> like already ? 16:01 < BlueMatt> no? 16:01 < ariard> we should 16:01 < BlueMatt> you can relay below-dust? I mean you can relay 1 msat. 16:02 < BlueMatt> i dunno, some users are going to expect it...we should *definitely* have an option, but suddenly refusing to relay anything under 1k sat is gonna piss some people off (who may perfectly reasonably trust their counterparty to not do anything cray to burn dust) 16:02 < ariard> I completely agree on not refusing anything under 1k, but how you should pick up this value really depend of your deployment and counterparty 16:03 < BlueMatt> but i think that option needs to be, basically "dont let me get screwed even for 1000sat", which is going to be a rather large project 16:03 < BlueMatt> of tuning a ton of parameters 16:03 < ariard> we should expose it clearly, and IIRC that was the purpose of #575 16:03 < BlueMatt> and almost certainly isnt possible without a pre-forwarding fee :( 16:03 < ariard> you mean an upfront payment ? 16:03 < BlueMatt> yea 16:04 < ariard> like for witholding htlc 16:04 < BlueMatt> huh, do we not enforce dust limit on our peers today? I thought we did :( 16:04 < BlueMatt> but, sure, we shouldnt allow dust inflation, but that doesnt mean we cant still get screwed for a few 1000 sats 16:04 < ariard> I think the "dont let me get screwed even for 1000sat" need a new field in open/accept 16:04 < BlueMatt> no, i mean just tuning fees and such so that it always costs as much to attack you 16:04 < BlueMatt> (but that requires upfront fee payment) 16:04 < ariard> BlueMatt: getting screwed for a few 1000 sats is okay 16:04 < BlueMatt> or some part of fee be upfront 16:05 < ariard> what paying upfront deter ? 16:05 < ariard> and who it's deterring your counterparty or a network sender ? 16:05 < BlueMatt> you have to assume they may be the same person 16:06 < ariard> I'll be back on #575 post-679 merge 16:06 < BlueMatt> but, yea, its making the sender pay for the risk we have with our counterparty 16:06 < ariard> what we should bound is the dust value on the counterparty's commitment transaction 16:06 < BlueMatt> upfront fees is partially to address the shortcoming that it costs $$$$$ to enforce an HTLC on chain 16:06 < ariard> because that's the part we *can't* claim 16:06 < ariard> you mean $$$$$$ but yeah 16:06 < BlueMatt> so if something goes wrong, we have to pay to enforce an htlc that isnt even ours 16:07 < ariard> we should implement not-going-onchain-if-htlc-is-too-low 16:07 < ariard> wrt to current mempool feerate 16:07 < BlueMatt> hmm, probably, but thats pretty low on the list of priorities :/ 16:07 < BlueMatt> given we (still) generate txn without fees! 16:07 < ariard> early optimzation I agree 16:08 < BlueMatt> which I may fix next week if I get to it and its still not done 16:08 < ariard> okay back to dust inflation we can't bound on pure dust_limit_satoshis and htlc_max_htlc_value 16:08 < ariard> because it can be decomposed between one non-dust htlc and a few dust ones 16:09 < ariard> and you need to announce this value to your counterparty to avoid closing inadvertently the channel 16:10 < BlueMatt> right, you need to bound dust_limit and htlcs_in_flight 16:11 < BlueMatt> it also implies failing htlcs on the sending side too, but that's not a protocol violation, just a local policy thing. 16:12 < ariard> but you need a spec modif for the counterparty, otherwise it can lawfully send you dust_htlc, still being udner htlc_max_htlc_value 16:12 < ariard> and you closing the channel due to a non-announced local policy violation 16:13 < BlueMatt> htlc_minimum_msat 16:13 < BlueMatt> not max 16:13 < ariard> BlueMatt: on #690, I still think we should verify *holder* htlc_minimum_msat at relay, even if we don't a direct exploitation 16:13 < ariard> because otherwise it's a duplicate check with the one in send_htlc() 16:13 < BlueMatt> you mean verify that the fee isn't too high? 16:14 < ariard> yes verify the fee isn't too high 16:14 < BlueMatt> I'm dubious that this is a material attack 16:14 < BlueMatt> the only thing the counterparty can do is make you burn their dust_limit value in fees 16:14 < BlueMatt> which they can do anyway with or without this 16:14 < BlueMatt> so I dont buy that it changes things. 16:16 < ariard> BlueMatt: I think we have 2 diffetent conversations a) how do we handle dust_limit_satoshi with your counterparty b) relay policy before commiting to an outgoing channel 16:16 < ariard> I agree that for b) it's doesn't make a) worst 16:16 < BlueMatt> right 16:16 < BlueMatt> we should fix (a), no question 16:16 < ariard> but that would be better to effectively enforce the HTLC relay policy as the user is expecting 16:16 < BlueMatt> but I don't think (b)/690 plays into it at all. 16:16 < ariard> yes we should fix (a) no question but that's more #575 16:17 < ariard> I don't think it's playing at all, at least I don't see how 16:17 < ariard> though I'll think hard about it while reworking #575 but for now I don't see how 16:22 < BlueMatt> ariard: ok, so we agree, I think? 690 doesn't need to change for this category of stuff? 16:24 < ariard> BlueMatt: no this is removing what the spec is meaning by "The HTLC amount was below the htlc_minimum_msat of the channel from the processing node." 16:24 < ariard> I think the spec is unclear and that's why we're disagreeing 16:25 < ariard> The spec should say explicitely to verify both holder/counterparty's htlc_minimum_msat values on the forwarding channel 16:26 < ariard> *explicitly 16:26 < BlueMatt> hmm, no i think the spec is very clear 16:26 < BlueMatt> that line aside lol 16:26 < ariard> How do you interpret "the channel from the processing node" It can't be the counterparty 16:26 < BlueMatt> but channel_update is very clear and the handling of htlc_minimum_msat is very clear 16:27 < BlueMatt> so there's nothing in the spec that says to reject on the basis of our own htlc_minimum_msat (except for on the incoming channel) 16:27 < ariard> IMO the channel_update should communicate the relay node htlc_minimum_msat too 16:27 < BlueMatt> the error code unclear aside 16:27 < BlueMatt> ok, but it doesnt, the spec is clear on that 16:27 < ariard> okay we agree on what the spec is saying 16:27 < BlueMatt> i think everything is right, attacks on dust inflation aside, this doesnt change that 16:28 < ariard> that's not interpretation of the spec, that how the spec should be amended to announce HTLC minimum msay 16:28 < BlueMatt> and I dont think rejecting on the basis of our own htlc_minimum_msat ever makes sense 16:28 < BlueMatt> including to prevent such things. 16:28 < ariard> okay so we agree on #690 with regards to spec correctness, but not necessarily about spec correctness itself 16:28 < BlueMatt> what does that add? you already indicate it on the inbound edge, so you do limit inbound payment htlc 16:28 < BlueMatt> i think the spec is correct? 16:28 < ariard> that's okay to move forward #690 as it is 16:29 < ariard> but you may have different value between your inbound and outbound 16:29 < ariard> we can merge #690, in the meanwhile lmk about how it may cause issues :p 16:32 < BlueMatt> ariard: right, you can have a different value, but the specific attack I don't buy is any worse than something you can do *without* it. 16:32 < BlueMatt> ie by limiting the inbound attack surface we fix this too 16:32 < BlueMatt> but I have to go eat dinner 16:32 < BlueMatt> either way its not relevant for 690 i think 16:35 < ariard> agree not relevant for 690 per se 18:07 < BlueMatt> ariard: can you ack the wording diff at https://github.com/rust-bitcoin/rust-lightning/pull/690#discussion_r489097110 and I'll merge? 18:16 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:a36c:ea40:f2ff:fe85:d2dc] has joined #rust-bitcoin 18:26 -!- shesek [~shesek@164.90.217.137] has joined #rust-bitcoin 18:26 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 18:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #rust-bitcoin 22:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 23:28 -!- jonatack [~jon@213.152.161.244] has joined #rust-bitcoin 23:29 -!- jonatack [~jon@213.152.161.244] has quit [Read error: Connection reset by peer] 23:35 -!- jonatack [~jon@37.166.247.142] has joined #rust-bitcoin 23:40 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 23:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] --- Log closed Wed Sep 16 00:00:20 2020