20:14:58 <t-bast> #startmeeting
20:14:58 <lightningbot> Meeting started Mon Jul  6 20:14:58 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:14:58 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:15:11 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/789
20:15:32 <t-bast> Let's do some PRs first and we'll get back to anchors afterwards, allright?
20:15:53 <t-bast> #topic Bump our recommendations for cltv_expiry_delta
20:15:56 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/785
20:16:10 <t-bast> We discussed that PR last time and agreed to raise the recommended values
20:16:31 <t-bast> I updated it to hopefully make the trade-offs a bit clearer without cluttering the spec too much, and raised default recommendations
20:17:08 <rusty> Acked on issue.
20:17:37 <roasbeef> yeah there've been some papers related to this recently
20:17:41 * rusty quickly opens a c-lightning issue to increase defaults...
20:18:02 <roasbeef> a follow up to that "flood and loot" paper analyezes the current defaults, and compares to a model of malicious hash power % for bribery attacaks
20:18:17 <roasbeef> they also look at values for csv delay as well
20:18:33 <t-bast> yes we're starting to see interesting analysis
20:18:48 <t-bast> so I really don't want to see more channels with a cltv_expiry_delta of 6 on mainnet
20:18:54 <roasbeef> this one I just referred to: https://eprint.iacr.org/2020/774
20:19:03 <roasbeef> heh yeh that's pretty low, thankfully fees are low rn, but we shouldn't get complacent
20:19:38 <roasbeef> I even see some values of like 1-4....
20:19:43 <t-bast> daaaamn
20:19:44 <cdecker> Oh nice, my former research group
20:19:48 <roasbeef> I think part of it is education on the front of the node operator
20:20:16 <roasbeef> cdecker: yeh they've really been cranking out a ton of LN stuff this year, cool to see they continue to explore the research area
20:20:18 <t-bast> cdecker: nice!
20:20:29 <t-bast> do I have another ACK on this PR?
20:20:38 <roasbeef> pedro's group as usual also stays steady cranking out papers
20:20:42 <cdecker> Should give them a visit some time soon, would love to brainstorm in person for a change ^^
20:20:54 <roasbeef> t-bast: down with teh idea in general, will check out the PR, +1 for being more conservative
20:21:03 <t-bast> what does "in person" mean? Long time I haven't heard that
20:21:13 <ariard> what are the new hightlights of this one compared to miner censorship described in original LN paper?
20:21:15 <roasbeef> it's like a hologram, but you can touch it
20:21:17 <t-bast> roasbeef: cool sgtm, let's defer to github then
20:21:26 <t-bast> touch it? that's digusting
20:21:34 <roasbeef> ariard: this one focuses in the game theory of bribing, with various hash rate distributions
20:22:07 <roasbeef> seciton 3.2 is what analyzes current values of csv delay and chan reserve based on their model
20:22:27 <ariard> okay do they give you an equilibrium point between HTLCC value and miner topology ?
20:23:18 <roasbeef> it's more about the extra fee to be paid to them than the value iteslf
20:23:23 <roasbeef> but ofc those are related
20:23:29 <t-bast> #topic Clarify duplicate TLV in stream
20:23:31 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/777
20:23:48 <t-bast> Small PR that's been hanging around, clarifying that we disallow duplicate TLV records
20:24:04 <cdecker> ack
20:24:24 <roasbeef> lgtm'd on PR
20:24:34 <roasbeef> speaking of the OP of that PR, has anyone tried out their RGB demo stuff?
20:24:54 <t-bast> there's a working demo?
20:25:05 <roasbeef> saw some tweet
20:25:13 <roasbeef> I think it might just be on-chain stuff, and not actually channel updates yet tho
20:25:27 <roasbeef> I never fully grokked the protocol myself in the channel context tho fwiw....
20:25:33 <t-bast> interesting, good to know they were able to make progress
20:25:38 <rusty> I thought the lack-of-dups was obvious, but yes "strictly" is better than "monotonically".
20:25:51 <cdecker> I'm helping them (RGB) along a bit
20:26:07 <rusty> Acked on issue.
20:26:09 <cdecker> Quite some interesting tech, but still a lot of road ahead
20:27:13 <cdecker> It's colored coins with off-chain protocol support. I think dr-orlovsky is in this channel as well :-)
20:27:58 <t-bast> #action Merge PR (enough acks gathered)
20:28:07 <t-bast> #topic Clarify flip(bits)
20:28:17 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/779
20:28:47 <t-bast> Apart from the spellchecker, I think every implementation agrees with that change
20:28:53 <t-bast> Otherwise nothing would work on mainnet :)
20:29:19 <rusty> I'll fix spellchecker...
20:29:34 <t-bast> Thanks rusty!
20:30:37 <rusty> Though adding 'th' to the dictionary feels... dangerous...
20:30:47 <rusty> I can see th problems it will cause...
20:30:56 <t-bast> ^^
20:31:25 * rusty elects to remove the "'th" in both places instead.
20:31:39 <t-bast> rusty: ACK
20:33:05 <rusty> force pushed with those removed...
20:33:38 <rusty> ... and "..." added.
20:33:47 <ja> thanks
20:34:41 <t-bast> #topic Static RemoteKey test vectors
20:34:46 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/758
20:35:16 <roasbeef> doesn't look like the PR has chagned since last time
20:35:24 <roasbeef> there're some unresolved comments too
20:35:28 <t-bast> IIRC, the latest state was that joost found it a bit weird to have test vector that actually couldn't occur because tx amounts were impossible.
20:35:52 <t-bast> In my opinion this is mixing layers and these test vectors don't have to care about these requirements
20:36:08 <roasbeef> well they should be valid transactions, no?
20:36:15 <t-bast> But I don't have a strong feeling about it, if BlueMatt isn't around shall we let this follow up on github?
20:36:23 <roasbeef> ppl could even have libs that just refuse to make transactions like that
20:36:35 <t-bast> They can be valid bitcoin transaction and not meet reserve requirements (which are covered in a separate bolt)
20:36:51 <BlueMatt> oh oops. sorry have forgotten to follow up on that (and didnt have any meeting notifications set :( )
20:36:54 <t-bast> otherwise the risk is that every test vector starts depending on the whole spec which is weird
20:37:05 <t-bast> Oh hey BlueMatt!
20:37:19 <BlueMatt> anyway, yes, I dont think anything has changed since last meeting, doesn't need discussion
20:37:25 <rusty> Yeah, I worked around my problems with the previous vectors for lnprototest (in particular, it's supposed to be the 42nd commitment, but the shachain is stated (0x01020304...) not derivable.
20:38:05 <t-bast> #topic Anchor outputs
20:38:06 <rusty> t-bast: it's always nice if the results are derivable from first principles, but I'd rather have test vectors than not!
20:38:08 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/688
20:38:33 <t-bast> rusty: exactly :D
20:39:11 <t-bast> The latest on anchor outputs is that c-lightning and eclair are getting started on the implementation, rust-lightning as well if I'm not mistaken
20:39:17 <roasbeef> dope
20:39:20 <rusty> I'm just grateful for test vectors.  Even YAML ones.  (Which, it turns out, are actually JSON ones)...
20:39:42 <roasbeef> well JSON is a subset of yaml ;)
20:39:53 <rusty> roasbeef: yeah, TIL!
20:39:59 <t-bast> From what I understand, anchor outputs don't make it worse than what we have today regarding pinning attacks, so we should start with that and once we have package relay on mainnet, migrate to an anchor v2
20:40:52 <ariard> good to me, I still hope in the long term we can get rid of mempool watching
20:40:55 <t-bast> FWIW I think the state of the anchor outputs PR is ok, it's clear enough for implementers
20:41:11 <t-bast> ariard: that would be awesome
20:41:44 <ariard> should we add CPFP weight in appendix ?
20:42:02 <t-bast> I have summaries of the pinning discussions here if anyone's interested: https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
20:42:38 <rusty> I did have a question on the recent 668 weight increase to allow > 253 inputs on the commitment tx.  That seems... weird?
20:43:13 <rusty> s/668/688/
20:43:17 <joostjgr> hi, that was a mistake
20:43:23 <joostjgr> it must have been >253 outputs
20:43:24 <ariard> it's the tx_out
20:43:40 <joostjgr> corrected in the pr
20:45:04 <rusty> joostjgr: right... but in practice it's in the noise at that point?  We require 253 minfee (though I couldn't actually find that in the spec!), which means we can't hit the bitcoin minfee?
20:45:27 <rusty> (Not to mention I think everyone grinds sigs to save a byte?)
20:46:02 <joostjgr> I think it is consistent to not do such optimizations
20:46:14 <joostjgr> We have a history ofc, but also no cost to make it consistent now
20:46:21 <joostjgr> (speaking for lnd)
20:47:25 <BlueMatt> so regarding the (afair) unresolved issue around changing the htlc tx format: There are essentially two incompatible goals here:
20:47:27 <BlueMatt> 1) we can have a goal of "the broadcaster can get the tx into the mempool/confirmed, but we dont care about allowing the non-broadcasting side any access to the tx, including seeing it, without a lot of work", then the sighash_single approach is cheaper and simpler to handle,
20:47:28 <BlueMatt> note that this is essentially the best we can do for *commitment* txn, so maybe we just rely on that for now, but
20:47:30 <BlueMatt> 2) if we want to have a more robust security model for htlc transactions today, then we can have that, but we need to ditch the sighash_single approach as previously discussed and (probably in a separate change) move towards all htlc txn being pre-signed and CSV 1, with associated state machine changes.
20:47:31 <BlueMatt> ariard indicated he thought those state machine changes may be required for ptlcs or schnorr or something, so maybe it makes sense anyway, but I dont know if its worth the effort given we cant really possibly have a decent security model today either way.
20:48:13 <rusty> Yes, but because our minimum fee is not 250 but 253, I think we don't need to take into account the extra 2 bytes for giant txs.
20:48:26 <roasbeef> sighash single ftw, it actually lets you bump the fee of the HTLC transaction, which is important since that's what you want to get in
20:48:30 <BlueMatt> I *do* think we need to make a conscious decision regarding what security model makes sense to have in mind for anchor before we charge ahead implementing here, it feels super premature.
20:49:04 <roasbeef> idk if it's "charging ahead", given it's an issue today, and there're implementations that're deployed that want to help mnitigate things for their users
20:49:04 <BlueMatt> roasbeef: that doesnt add anything given the commitment transaction got in.
20:49:22 <roasbeef> BlueMatt: ofc it does, for second level transactions, only once that's in can you consider the HTLC "rsolved"
20:49:48 <BlueMatt> roasbeef: the current anchor outputs design was written up months before we found a whole series of critical issues in lightning that are highly related. it seems worth discussing those issues before committing to a path forward...
20:49:50 <t-bast> BlueMatt: I don't see how the suggestion of pre-signed changes anything, you can still pin in miners mempool one tx and have a different one for the rest of the network, so the honest participant won't be able to learn about it either
20:50:40 <ariard> Yeah I think that was making sense to pre-signed second stage before we realize pinning on the commitment_tx-level
20:51:01 <t-bast> BlueMatt: you simply have to wait for the timeout block: the attack broadcasts his (pre-signed) ClaimHtlc tx to miners mempool and the HTLC-timeout to the rest of the network
20:51:08 <ariard> since then we'll need package relay anyway to be secure, so at least let's make user safe against mempool congestion stucking their 2nd-stage
20:51:14 <BlueMatt> t-bast: it only helps for the htlc txn :/. essentially, if the htlc can only be resolved in one of 4 different txids, then its less of an issue and you can maybe do the blind-bumping approach, or, at least, you probably can presuming an ability to send transactions to a whole mess of nodes
20:51:33 <BlueMatt> but, indeed, for commitent txn, we're pretty much totally hosed without changes to various other things
20:51:42 <t-bast> BlueMatt: ok, so you still need to rely on a blind-bumping mechanism, in that case it's slightly better indeed
20:52:07 <ariard> blind-bumpinh wouldn't work with _current_ propagation, orphan rules
20:52:18 <t-bast> BlueMatt: but this blind-bumping is still something we don't know how to do properly, right?
20:52:23 <BlueMatt> *but* it would mean that we dont need the mess of monitoring global mempools for htlc preimages (again, however, if the attacker uses commitment txn to do an attack, you're pretty much screwed)
20:52:54 <BlueMatt> ariard: remind me why we decided that? I dont recall and I'm now thinking we were wrong, at least assuming there's only 4 valid txids that can be in the mempool and they're all csv 1
20:53:47 <ariard> BlueMatt: assuming the attacker know tx-relay topology, I can conflict-partition you and your neighboors with txid_1 and throw txid_2 in miner mempools
20:54:03 <ariard> and your blind-bump won't propagate at the boundary between subsets?
20:54:09 <BlueMatt> ariard: I dont think so? the htlc-timeouts are all cltv'd
20:55:16 <roasbeef> re blind bumping, we just anchor down all versions
20:55:17 <ariard> BlueMatt: hmmmm, but your bump is going to be an orphan at some point even if you know txid of all combinaisons
20:55:27 <roasbeef> we don't watch the mempoo
20:55:33 <BlueMatt> t-bast: you missed these lines:
20:55:37 <BlueMatt> <roasbeef> re blind bumping, we just anchor down all versions
20:55:38 <BlueMatt> <ariard> BlueMatt: hmmmm, but your bump is going to be an orphan at some point even if you know txid of all combinaisons
20:56:01 <BlueMatt> ariard: i mean if it is that means the htlc-success isnt in that nodes' mempool which is ok?
20:56:06 <ariard> roasbeef: you don't watch the mempool ? How do you decide to broadcast a cpfp on to_remote of remote commitment?
20:56:09 <BlueMatt> ariard: its more complicated post-timeout, I thinkk, though?
20:56:13 <roasbeef> in practice, we haven't run into any issues with that
20:56:51 <roasbeef> ariard: if we force close, we anchor them all down
20:56:56 <t-bast> Thanks
20:57:09 <BlueMatt> roasbeef: I'm confused what you're referring to, here?
20:57:25 <ariard> roasbeef: right, but you anchor local and remote commitment but only one of them will propagate
20:57:48 <joostjgr> local, remote commitment and the remote pending one if it exists. three max
20:58:31 <roasbeef> ariard: yeah, so which ever one confirms is fine
20:58:45 <BlueMatt> roasbeef: you're saying that when you receive an error message you just broadcast all possible anchors on the latest commitment tx?
20:59:01 <BlueMatt> roasbeef: have you read ariard's list of attacks in the email thread?
20:59:04 <ariard> BlueMatt: with your blind-bumping how do you jump across a conflict-partition between previous_commitment_tx+HTLC-Success/commitment_tx+HTLC-Success
20:59:04 <roasbeef> if we then decide there's a new for us to bump, we can do that
20:59:08 <roasbeef> yeh
20:59:34 <BlueMatt> ariard: I'm presuming csv-1, so the commitment tx must be on-chain before anything relays
20:59:37 <t-bast> ariard: I think that's still unknown, and probably out of the normal bitcoin p2p relay :/
21:00:09 <ariard> BlueMatt: ah yes miss this point so yes you can know which version you have to bump, but that's not a blind one anymore :p
21:00:10 <t-bast> BlueMatt: but even with that, the attacker can still sneak in right after the block confirmation, right?
21:00:18 <BlueMatt> roasbeef: sooo, this conversation isnt about commitment txn, I'm not really sure what you're referring to here? or are you suggesting something about commitment txn applies to htlc txn?
21:00:18 <ariard> assuming it's pre-signed
21:00:39 <BlueMatt> ariard: well, its not *really* blind, its only blind in that you dont really have to look at the mempool to know whats there
21:00:56 <BlueMatt> t-bast: it relies pretty heavily on rebroadcasting, I think
21:01:02 <BlueMatt> but, I think thats maybe ok?
21:01:04 <roasbeef> was talking about the way you anchor down w/e may get in
21:01:10 <ariard> BlueMatt: gotcha, was confused with your other ideas of noinput+cpfp, also called blind-bumping at some point
21:01:34 <t-bast> BlueMatt: but that's where the attacker can fill the network's mempool to create the partition and prevent p2p relay...unless I'm still missing something
21:01:34 <BlueMatt> ariard: ah, right, I think I was maybe trying to get the same mental model to apply there, but I'm not convinced it makes sense in that context.
21:01:51 <roasbeef> the #2 above there, also means state machine changes as I've mentioned before
21:01:52 <ariard> roasbeef: yes it works if you rebroadcast every X blocks in case the remote commitment win the propagation race but the anchor on remote has always been evicted
21:01:53 <BlueMatt> roasbeef: right, ok, so you're just saying that you think blind bumping makes sense in general?
21:02:12 <roasbeef> ptlc or scnhorr also doesn't really have any time frame rn, and this is a big issue today w/ more an dmore papers bringing attention to it
21:02:32 <BlueMatt> t-bast: right, I dont think there's any (current) way of addressing that except package relay, essentially
21:02:34 <roasbeef> how do we define blind bump, like bump-em-all?
21:02:47 <t-bast> BlueMatt: ok thanks, that's clear, we agree on that
21:02:55 <BlueMatt> roasbeef: essentially. yes. the idea being bump what you know could be in the mempool, but arent sure if its there
21:03:06 <roasbeef> mhmm, that's what we do rn
21:03:22 <BlueMatt> (of course that doesnt work/make sense for commitment txn cause there's millions of those, but for htlc txn we can make it work)
21:03:25 <roasbeef> our next release is going to have dynamic bumping based on cltv delay too
21:03:38 <roasbeef> and the looming deadline
21:03:41 <t-bast> roasbeef: but you can't do it anymore with the sighash_single change, you don't know the final txid of the HTLC-success / HTLC-timeout?
21:03:46 <ariard> changing state machine may take us as long as getting package relay on the base layr
21:04:01 <roasbeef> t-bast: thought we're talking about the anchor on the commitment?
21:04:12 <roasbeef> as in bump that
21:04:14 <BlueMatt> roasbeef: no, we've been talking about anchors on htlcs this entire time :)
21:04:29 <ariard> yes we already do bumping based on cltv_delay limit approaching
21:04:36 <roasbeef> i don't think that revocation thing is an issue, only what matters is what gets in the chain
21:04:43 <ariard> actually we do this for any kind of transaction, not only HTLC claiming
21:04:47 <BlueMatt> ariard: I dont see why adding one more message to the state machine should take years?
21:05:02 <roasbeef> t-bast: the single change means you can aggregate htlcs, and also include the second level htlc transaction bunlded w/ _other_ transactions that you might've already been doing as well
21:05:08 <t-bast> roasbeef: even for commitment tx, the attack ariard described ensures your bumps will never propagate...
21:05:09 <BlueMatt> roasbeef: you should go read ariard's email! I promise its quite excellent
21:05:14 <roasbeef> the devil is always in the details
21:05:19 <roasbeef> re state machine changes
21:05:23 <t-bast> I mean ariard's attack on the ML
21:05:25 <roasbeef> which already is rather underdefined int eh spec
21:05:54 <ariard> roasbeef: timelocks being committed by sighash in pratice that's pretty limited for HTLC-timeout, but still a gain for preimage ones
21:06:14 <roasbeef> ariard: nah, we already time lock transactions we do from the normal wallet
21:06:20 <roasbeef> the timelock value
21:06:25 <t-bast> roasbeef: yeah I agree that the sighash change does have a lot of good things for the honest participant, it's just sad that it also has a few drawbacks that help attackers...trade-offs, trade-offs everywhere
21:06:25 <roasbeef> but yeh nice for sweeps too
21:06:50 <roasbeef> t-bast: yeh tradeoffs, so lets satisfice and get something out to protect our users from even the non-adversarial cases where they could lose out
21:07:10 <BlueMatt> t-bast: so, I think re: flooding the mempool I'm maybe a tiny bit less worried about that attack, especially for attacking htlc txn.
21:07:16 <roasbeef> as this threat model has just been continually expanding
21:07:19 <BlueMatt> roasbeef: we've got two options here, both accomplish that.
21:07:24 <roasbeef> it's a mistake to try to solve everything in one swoop
21:07:31 <BlueMatt> no one is suggesting we do that
21:07:41 <roasbeef> when even w/o 3rd parties interacting, bad things can happen rn
21:07:44 <t-bast> but overall I think we should still move forward with anchor outputs and the sighash changes, it allows us to implement a lot of things that will be useful later when we have package relay to tackle the latest threat model updates
21:07:49 <BlueMatt> but lets also please *not* charge forward with something that we'll have to undo six months later
21:08:01 <ariard> I think we want more to agree on how we are going to solve every attach and be sure we dom't do 2 steps forward 1 backward
21:08:07 <ariard> *attack
21:08:09 <roasbeef> charge forward is relative here, given that this is also a link level change, this isn't bitcoin script
21:08:10 <BlueMatt> t-bast: well, i mean, no, once we get package relay I think we'll move towards anchor on the htlc txn
21:08:14 <BlueMatt> not sure, but I think.
21:08:20 <roasbeef> what we deployed has been ready for 6+ months already
21:08:37 <ariard> yes anchor-ouput current version is goodd against mempool-congestion unsafeties
21:08:39 <roasbeef> none of the package relay or ptlc or scnhorr stuff even has a realistic time frame
21:08:40 <joostjgr> ariard: what is the heuristic that you use for bumping when the cltv limit approaches?
21:09:11 <ariard> joostjgr: you mean to increase feerate or decide when the next bumping happens?
21:09:30 <joostjgr> the 'curve' that you walk along towards expiration
21:09:35 <t-bast> BlueMatt: maybe, but I think we can phase things to update from anchor outputs (the current one), can't we?
21:09:55 <BlueMatt> roasbeef: we've been talking about it for ~3 years, so, yea, I think the rush given we've learned more in the past month than in three years is somewhat strange. anyway, it seems worth having the conversion. given we maybe are getting some clarity on what things will look like when we get to an actually-secure lightning mempool model.
21:10:13 <t-bast> Because I think we can realistically have the current anchor outputs proposal shipped in less than 3 months, which solves many issues we have today (and simpler attacks than the pinning ones)
21:10:14 <roasbeef> BlueMatt: yeah i know, i was part of the original convos, i'm talking baout this conrete version
21:10:43 <BlueMatt> t-bast: sure, I mean we can also have current anchors-but-only-on-the-commitment-txn shipped even quicker, though :)
21:10:55 <roasbeef> also we're already deployed and have active users, I can understand if RL wants to wait longer since they haven't fully "deployed yet", but the rest of us don't need to adopt that framing
21:11:03 <ariard> joostjgr: rn it's 3 modes, if less than 3 blocks, re-schedule next block, if less than 15 blocks, re-schedule in 3 blocks, if more re-schedule in 15
21:11:03 <roasbeef> we have skin in the game as is
21:11:10 <BlueMatt> roasbeef: I dont really care about RL for this stuff, tbh.
21:11:16 <roasbeef> lol wat?
21:11:21 <t-bast> BlueMatt: true, but the simple attacks that exist today on HTLCs can't be mitigated with only the commit tx changes (AFAIK)
21:11:30 <roasbeef> but y'all are implementing it..right?
21:11:53 <BlueMatt> roasbeef: as-is, I dont think anyone should be using lightning peered with anyone who isnt fully-trusted. period. and they shouldnt until we've figured this stuff out. hence why I'm trying to figure this stuff out :)
21:12:28 <ariard> roasbeef: yeah it's more important to get Lightnign right overall than just RL not being exposed there
21:12:28 <BlueMatt> t-bast: sure, but thats what the in-flight limit is for :)
21:12:30 <roasbeef> ok you're free to share that world model lol
21:12:40 <joostjgr> ariard: and which fee rates do you use then? if you get close to expiry, potentially the full value of the htlc is at stake.
21:12:53 <roasbeef> also as usual, security isn't binary
21:13:04 <t-bast> BlueMatt: yeah you can limit how much you lose, and probabilistically protect from the attack with high enough cltv_expiry_delta, but it's not a 100% protection though...
21:13:22 <BlueMatt> t-bast: sure, but none of what we're talking about is "protection" :)
21:13:23 <ariard> joostjgr: if your fee-estimator has changed since last time use it, hence a dumb 25%
21:13:41 <BlueMatt> its only a "two honest parties who screwed up their feerate selection are cooperating to get the latest state on the chain" fix
21:13:44 <roasbeef> existence of known issues or attacks against a protocol doesn't render it unusable or "broken"
21:13:54 <roasbeef> we all still use tor after all
21:14:39 <BlueMatt> eh, this probably isnt a relevant debate.
21:14:41 <ariard> same with bitcoin base layer saying it's 100% secure wouldn't be accurate
21:14:54 <joostjgr> ariard: ok. we generally republish every block with an updated fee estimate. some of those may violate bip125 rules, but we don't care. only problem is that if the conf target is high, it may still not conf in time. because it is only an estimate. so in some cases we lower the conf target when we get closer
21:15:19 <BlueMatt> I'm curious what rusty's take is
21:15:28 <BlueMatt> given he also worked on implementing this stuff and has put time in
21:16:12 <roasbeef> iirc, he's on board w/ protecting our current users, w/ what we have already, given bad things can happen rn even w/o any malicious actors
21:16:14 <ariard> joostjgr: right because you may not account for bandwidth increase? lowering the conf target is quite equivalent to bump more aggressively as I'm trying to do I think
21:16:29 <rusty> BlueMatt: it's unfixable.  Bitcoin core needs to have an emergency RBF rule that says if the previous package was not in the top 4MW and the replacement would be in the top 3.2MW, it accepts it whether the other feebump rules are met or not.
21:16:42 <BlueMatt> to restate the question at hand - do we accept that the best we can do is help two-honest-counterparties get their txn on chain and stick with that model for htlc txn as well, or do we redo the htlc txn format for anchors so that we can get better security for them
21:16:46 <rusty> Then you can just bid it into the next block.
21:16:50 <roasbeef> and there's other pinning issues also outside of all this stuff even
21:16:53 <ariard> BlueMatt: mempool-congestion unsafety, even it's an edge-case (like 0.000001%) is worthy to fix
21:16:58 <BlueMatt> rusty: agreed (plus package relay) essentially.
21:17:02 <joostjgr> ariard: ok, i see. so you follow your fee estimator, but if the needle doesn't move anymore, you override with 25%?
21:17:43 <BlueMatt> rusty: (but thats somewhat a different question - i think it *is* fixable, essentially, today, for htlc txn)
21:18:04 <ariard> rusty: you also need p2p changes to relay as a package, and a way to actually compose them, either by relay or initial-sender
21:18:09 <BlueMatt> rusty: (as an aside, I've had a few productive chats recently about possibly utilizing a rule like that to fix this whole mess, or at least make it more sensible)
21:18:28 <rusty> ariard: why?
21:18:43 <t-bast> BlueMatt & Rusty: if Bitcoin offers that (in the future), we can fix the issue while keeping the sighash changes on htlc txs and not requiring anchors on HTLCs, which would be great because anchors on every HTLC are costly...
21:18:56 <BlueMatt> t-bast: I dont believe so, no.
21:18:57 <ariard> joostjgr: yes a dumb override with 25%, actually I think a more sophisticated version would try to re-bump even between blocks if you observe significant congestion increase
21:19:03 <roasbeef> also the p2p changes need to be super widely propagated to do anything
21:19:12 <BlueMatt> t-bast: I believe the sighash chages are fundamentally incompatible with fixing these issues.
21:19:17 <roasbeef> t-bast: +1
21:19:20 <BlueMatt> t-bast: at least, I dont see how to fix it)
21:19:50 <ariard> t-bast: I think we quite all agree there :)
21:20:21 <BlueMatt> rusty: because if the pre-signed commitment tx has a low fee, you have to be able to relay that commitment tx (with its low fee) and a bump txn based on it to make the whole group have a higher fee :(
21:20:24 <ariard> roabseef: yes you need to have a least a propagation path to miner mempools, so if you assume 8 outbounds peers, you might night 30% of network updages
21:20:30 <ariard> *need
21:20:56 <rusty> ariard: meh, if bitcoind just deferred evaluation of incoming low-fee txs for some (perhaps long) time, that would cover it.  Turns out, that would also cover the concerns about flooding the network with cheap RBF replacements.
21:21:06 <t-bast> BlueMatt: but in the case of a confirmed commit tx, the attacker and the honest participant are competing to spend the same confirmed output: so if the honest participant can attach a high fee to his HTLC-timeout to get it to replace a low-fee pinned HTLC-success (that's hidden in far-away mempool) all his good regardless of the sighash of the HTLC-success?
21:21:26 <roasbeef> ariard: mhmm, and uprades take time...unless there's a soft-fork or something in flight
21:21:27 <t-bast> BlueMatt: ok I'm assuming we got the commitment tx confirmed
21:21:28 <ariard> BlueMatt: wait if you have package relay you can bump a pinning on 2nd-stage?
21:21:48 <rusty> Though it would change the current model where the mempool is considered something you can reliably throw lowfee txs into every few days, but that's arguably broken anyway.
21:21:49 <BlueMatt> t-bast: note that you cannot enforce the "top 4MW of the mempool" rule that rusty is just talking about here in a sighash_single tx
21:22:29 <t-bast> BlueMatt: can you detail?
21:22:32 <BlueMatt> ariard: I dont think this all works out without the "top 4MW of the mempool" rule, thing
21:22:46 <ariard> roasbeef: sure, but still you can ask LN operators to upgrade nicely their full-node to increase _our_ whole security
21:23:47 <ariard> rusty: perhaps but that sounds like a censorship vector if I can tweak your mempool rules, and still you need to reverse topology-order
21:23:49 <BlueMatt> to avoid the "but you can waste infinity bandwidth" issues, I think the elegant solution, as rusty points out, is to allow txn to carry a flag which says "I only want to get into the mempool if I'm gonna be in the next block or two" - this implies that the proability of the tx getting mined is high enough that free relay for it can be allowed (at least, hopefully, this isn't a well-socialized idea, but its at least possible)
21:23:57 <ariard> announcement to your p2p peers
21:24:11 <BlueMatt> sooo, to have package-relay-rbf you probably need such a flag (and a way of *enforcing* that that flag be set - on commitments and htlc txn)
21:25:08 <BlueMatt> rusty: I believe the larger concern of suhas' is around mempool standardness changes causing honest nodes to DoS each other by downloading the same package over and over again.
21:25:09 <ariard> BlueMatt: yes the tagging we talked offline is needed, you need a way to signal "this transaction might be part of a higher-feerate package and we need to do discovery"
21:25:34 <t-bast> can't we get clever and use specific nSequence or nLockTime values as a flag to ensure it's covered by the sighash_single sig (maybe a dumb proposal)?
21:25:42 <roasbeef> ariard: we don't really know what the propagation graph looks like, but yeh we have this new class of nodes that may be more willing to upgrade sooner
21:25:46 <t-bast> actually not nSequence then
21:25:46 <BlueMatt> rusty: also, note that the actual effort of calculating a tx's fee can for some nodes be most of the DoS potential :(
21:26:00 <BlueMatt> t-bast: yes, I presume thats how we'd do it.
21:26:01 <ariard> rusty: if you tag them, you can have different tx-relay policies per class of transacion
21:26:14 <ariard> at least with RBF you already have 2 classes
21:26:16 <roasbeef> let's remember to keep ourselves grounded, we can't count on pkg relay stuff or other mempool policy changes
21:26:27 <BlueMatt> t-bast: but, note, you cannot sighash_single|sighash_anyonecanpay such txn.
21:26:32 <roasbeef> this is a real issue today that affects all LN users, where bad stuff can happen even w/o outside interference
21:26:57 <roasbeef> input level lock-time would be amazing
21:27:00 <BlueMatt> roasbeef: yes, agreed. we should be building something to deploy today keeping in mind the end-state that we want to get to to be comfortable with the whole picture
21:27:02 <roasbeef> for stuff outside of this too
21:27:20 <roasbeef> mhmmm, and some of us havve more skin in the game than others, given they're widely deployed already
21:27:44 <roasbeef> also this is a link level upgrade, not a bitocin script upgrade, just you and your peer need to agree
21:27:45 <t-bast> BlueMatt: even if it's an `nLockTime` flag? This should be covered by the sig, isn't it?
21:27:46 <BlueMatt> ie the above is describing a potential end-state...so as to inform what we may want to do today
21:28:07 <rusty> BlueMatt: yes, failing to have a simple way of representing the fee in bitcoin txs sucks hard.
21:28:19 <ariard> BlueMatt: on this package-relay-rbf you still have to manage conflit at the relay-side between the delay time
21:28:43 <ariard> BlueMatt: and wrt to mempool Dos actually you can introduce package_id
21:28:47 <BlueMatt> rusty: anyway, you should chat with suhas! I think he's interested in maybe workng on this stuff again post-wtxid-based-relay, I'm sure you'd be super useful in helping him think through ideas :)
21:29:08 <rusty> BlueMatt: ack.
21:29:09 <BlueMatt> t-bast: I think my concern is more about having a tree of unconfirmed parents, which I thinkw ould break this
21:29:15 <ariard> to avoid a parent A being ban first for being attached with a low-feerate child
21:29:22 <ariard> and then reevaluated with a higher-feerate child
21:29:59 <t-bast> BlueMatt: ok, but we could restrict this rule/flag to only be accepted in mempools if all parents are confirmed or something like that?
21:29:59 <BlueMatt> ariard: I *think* this stuff only makes sense if the flag is set on a tx with no in-mempool parents
21:30:08 <BlueMatt> (ie commitment txn, htlc txn spending a csv-1 value)
21:30:25 <ariard> BlueMatt: yes that I meaned offline by utxo-spender opt-in!
21:31:09 <rusty> ariard: good point.  You can't blacklist a tx for being too low fee, if you want it to be bumpable.
21:31:27 <BlueMatt> ariard: Hmmmm E_NO_PARSE :(
21:31:30 <rusty> OK, hard timeout for me, sorry! gtg
21:31:44 <BlueMatt> see ya rusty! can we do an audio/video call about this this/next week?
21:31:52 <roasbeef> we've spun our wheels so much on this, it's really dissapointing
21:31:57 <BlueMatt> I'm sure roasbeef will be happy if we stop chasing our tails :)
21:32:02 <ariard> BlueMatt: cf the signal conv I've answered yet!
21:32:10 <roasbeef> which is why we just deployed, as no one else had an actual urgency to deploy a solution to protect our users
21:32:20 <ariard> not answered
21:32:22 <t-bast> I'll have to drop off soon, I'd like to thank everyone for the discussion; I think it's important to acknowledge that there are issues to solve (thanks BlueMatt/ariard for pressing on those) and keep the long-term discussions going, while still making short-term progress to fix shorter term issues (thanks roasbeef/joost for the current anchor proposal)
21:32:50 <BlueMatt> roasbeef: last I heard others were way ahead of y'all on this - and actively scanning the mempools of many nodes on the network to address attacks :)
21:33:07 <roasbeef> other ppl have deployed anchors?
21:33:22 <t-bast> Trade-offs are hard, but I'm sure we'll be getting there in the long run ;)
21:33:32 <BlueMatt> t-bast: totally aggreed! tbh I mostly just want to see a conclsion on what security model we want for these things and then we should move forward as fast as possible :)
21:34:21 <t-bast> roasbeef: on it, can you lend me johan and joost for a couple of months? :D
21:34:38 <roasbeef> that's the other thing, the security model is just every growing now, it's leaked into network level node linking
21:34:42 <ariard> roasbeef: I think we agree on anchors, discussion was more on global-mempool-watching vs package-relay as security models
21:34:43 <t-bast> BlueMatt: great, I think we are making some slow progress on that, week by week ;)
21:34:53 <ariard> to fix advanced pinning
21:35:14 <BlueMatt> t-bast: yea. would be nice to schedule a more high-bandwidth chat so we can conclude this
21:35:35 <BlueMatt> I *think* we've played about enough with the issues here that we have some kind of idea whats at play and at least one or two ideas for where to go in the long-term
21:35:44 <ariard> roasbeef: yes but you can't evict the base layer model from the lightning one, and AFAIK pinning wasn't scoped in original LN paper
21:36:02 <t-bast> #action t-bast to start mail thread for video/call meeting
21:36:41 <t-bast> Allright dropping off, thanks everyone!
21:36:43 <t-bast> #endmeeting