--- 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