20:04:53 <t-bast> #startmeeting
20:04:53 <lightningbot> Meeting started Mon Sep 14 20:04:53 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:53 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:05:19 <t-bast> #topic Anchors, update_fee, yes we're still talking about fees
20:05:24 <t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
20:05:42 <ariard> how does CL and eclair handle update_fee ?
20:05:47 <t-bast> ariard: floor is yours to sum up the post for those we haven't yet read it (it's great, you should read it)
20:06:07 <ariard> okay shortly we add SIGHASH_SINGLE with anchors for second-stage transactions
20:06:07 <t-bast> on the eclair side, we let you configure a tolerance between your fee estimation and what the remote proposes
20:06:32 <t-bast> by default you can accept up to 8x your estimated fee, but that's configurable
20:06:34 <ariard> which is great as it's let you adjust the feerate and aggregate them independently of your counterparty behavior
20:06:52 <rusty> Yes, c-lightning too, but it's pretty broad due to historical issues with consensus.
20:06:55 <t-bast> we've seen that in practice that's what prevents channel closure, we have outliers that do estimate 5-6x our local estimation
20:06:59 <ariard> t-bast: ouuuch 8x, sounds a lot
20:07:41 <ariard> the issue is we still have update_fee and as sighash_single doesn't commit to hashOutputs it let the channel funder escape funds from potential punishment
20:07:58 <ariard> as the revokeable redeemscript only encumber the first output of the HTLC
20:07:59 <cdecker> Yeah, estimatesmartfee was causing a lot of issues back in the days, now we smooth exponentially but allow quite some slack
20:08:27 <ariard> and as a reminder we deduce the HTLC-txn fees from the commitment tx outputs
20:08:38 <BlueMatt> (not to mention different fee estimators are often way off, but both totally justified in their estimates, eg looking at mempool vs not)
20:09:11 <t-bast> Does minRelayFee really vary on the public network?
20:09:27 <BlueMatt> no.
20:09:30 <cdecker> BlueMatt: not only that but the fee will jump down as we witness a block
20:09:36 <ariard> so your counterparty inflate the feerate, obtain a bunch of counter-signature with sighash_single, decrease the feerate, spend the balance
20:09:36 <t-bast> Or could we decide that anchor channels have a fixed fee of 20 sat/byte and update_fee isn't allowed at all?
20:10:06 <ariard> attach non-encumbered outputs on revoked 2nd-stage and broadcast revoked commitment + htlc txn
20:10:32 <cdecker> Yeah, I thought the point of having anchor outputs is to remove update_fee altogether
20:10:36 <ariard> t-bast: we can keep update_fee for commitment and remove it for HTLC-txn
20:10:40 <BlueMatt> cdecker: sure, I was just noting that its totally possible that its the case that two nodes which disagree wildly on the fee are *both* perfectly justified in their estimates.
20:11:07 <t-bast> ariard: but is there a reason to even keep it for commitments?
20:11:10 <rusty> Yes, the endgame was always going to be removal of update_fee.  Getting rid of that logic is a def. win.
20:11:18 <cdecker> BlueMatt: true, a block clearing the mempool is just a very regular example of this happening I guess :-)
20:11:38 <rusty> (But of course, that means you *need* to implement CPFP)
20:11:40 <ariard> t-bast: I don't think we have a mechanism to adjust feerate of commitment in case of unilateral broadcast
20:12:08 <ariard> rusty: right but I guess everyone is doing it for anchor output so you can reuse the logic to attach an input/output pair to HTLC-txn ?
20:12:18 <t-bast> ariard: by using the anchor we can, can't we?
20:12:36 <ariard> t-bast: well your transaction may fail your mempool min feerate
20:12:54 <ariard> transactions are evaluated one by one for mempool acceptance
20:12:55 <t-bast> I've seen that bitcoin core merged the addition of psbtbumpfee, so 0.21 will be a great time to implement CPFP!
20:13:12 <t-bast> ariard: how is that min feerate calculated?
20:13:40 <t-bast> ariard: does it depend on what's currently in your mempool (if you're lower than the rest and at your mempool size limit, it's dropped?)
20:13:48 <rusty> ariard: well, it's simpler to implement the tx changes, then later get the CPFP logic working.  Baby steps.
20:13:58 <ariard> t-bast: there is a base one and it's increased everytime you're evicting transactions from your mempool due to reaching max mempool size
20:14:03 <BlueMatt> ariard: I'm pretty dubious that we can't pick a fee which will reliably meet mempool minfee and hard-code it, but, then, I figured I'd lost that battle long ago.
20:14:28 <BlueMatt> another option is yet another feature bit to indicate "no update_fee, I support CPFP"
20:14:35 <BlueMatt> and it can be negotiated, with peers eventually turning it off.
20:14:47 <ariard> t-bast: IIRC min mempool feerate is based on the lowest-feerate of the package at the bottom of your mempool
20:15:16 <ariard> BlueMatt: I think we're right but we're somehow making an assumption on the size of your mempool
20:15:22 <ariard> the configuration size
20:15:26 <BlueMatt> (basically ^, with an exponential decrease over time if we have room)
20:15:53 <ariard> like what if I run a 10MB mempool and the feerate is really high?
20:15:58 <t-bast> ariard: that would seem logical, so it seems that with a fixed fee, if txs are evaluated separately (not as a package), we'd need to decide on a fixed fee that would always work in the future...which is back to square one isn't it BlueMatt?
20:15:59 <BlueMatt> ariard: right, I guess I think that its roughly equally likely that the mempool minfee spiked when you want to broadcast and you cant.
20:16:21 <BlueMatt> so I'm dubious its something worth worrying *too* much about, but its definitely one of the primary reasons why we didnt yank update_fee for anchor outputs to begin with.
20:16:43 <ariard> t-bast: yeah and I don't want to make assumption on when we'll get package relay support
20:16:57 <ariard> so we may have to pick a feerate now and pray for it to be still valid 2y from now
20:17:04 <BlueMatt> (ie unless mempool feerates are going up slowly over time, a sudden spike, which seems to be the state of play in reality today, is going to be just as bad for you as hard-coding a low feerate)
20:17:23 <rusty> ariard: agreed. It's unclear to me that this situation is *worse* than what we have now, TBH).  But I don't know what this historical min fee has been.
20:18:00 <t-bast> rusty: ariard's attack makes anchor worse than the current commitment though, if you allow large update_fees during the lifetime of the channel
20:18:28 <BlueMatt> one interesting note is a local lightning node can always get a tx into the mempool (prioritize transaction 100 X && submitrawtx $PACKAGE && prioritize transaction 0 X), so we could go back to cdecker's overlay transaction relay network and have miners run a lightning node
20:18:28 <t-bast> rusty: I meant it's a different attack than the ones on the "legacy" commitment scheme, but it does let you steal money
20:18:34 <BlueMatt> yay package relay when core doesn't support it :)
20:18:43 <rusty> t-bast: oh, yes, I was referring to current non-anchor situation.
20:19:11 <t-bast> rusty: yes, for non-anchors we're safe
20:19:21 <ariard> *looking Core's CheckFeeRate
20:19:33 <t-bast> BlueMatt: yay l2 package relay :)
20:20:41 <rusty> t-bast: with anchors-no-updatefee we're trying to guess minfee-mempool, with current we're trying to guess minfee-block.  The former is probably more predictable, definitely lower, but we have less data about it.
20:20:44 <cdecker> The overlay is a nice suspender, but we need a belt too ;-)
20:20:52 <ariard> BlueMatt: have miners run a lightning node, lol just bundle RL with Stratum V2. Done
20:21:08 <BlueMatt> well option 3: update update_fee guidance for anchor to mean "estimated min relay fee"
20:21:15 <t-bast> rusty: yes, that's why it's hard to make any kind of spec decision :(
20:21:42 <BlueMatt> that way we can leave it dynamic but hopefully get much tighter consensus on its value and reject higher values easier
20:22:17 <BlueMatt> its definitely a big change, though, it requires a bitcoin full node to process update_fees since most of the fee web api things wont ever give you that.
20:22:45 <t-bast> How would you have tighter consensus without a global mempool?
20:23:13 <t-bast> That relies on the assumption that we'd have similar mempools right (which may remain correct for the next 2 years)?
20:23:16 <BlueMatt> I'm (guessing) thinking that that value is more consistent across nodes (kinda, there's edge cases, but we can talk about those in detail if y'all want)
20:23:27 <cdecker> Presumably the relay fee is far less flaky than the "get me into the next block" estimate
20:24:06 <BlueMatt> (technically there's an issue where many nodes will never increase min fee because their peers won't relay txn to them which bump it cause their peers have limited size....this could be fixed by, eg, taking the lowest fee tx in your mempool instead of the actual min relay fee)
20:24:07 <t-bast> Couldn't this be gamed? If you figure out someone's full node, you fill its mempool with high-value txs and it will cause it to force-close all its LN channels?
20:24:16 <ariard> BlueMatt: it doesn't matter if 20% of tx-relay topology subset doesn't have the same value than you, should be good enough to propagate
20:24:46 <BlueMatt> t-bast: probably? not sure how thats worse than today, though.
20:24:58 <rusty> The answer: 4x the current min.  So 1000 sats perkw.  (Hey, you can't prove it's wrong!)
20:24:59 <t-bast> BlueMatt: granted, you can already do that today xD
20:25:08 <ariard> t-bast: well you can just prevent someone to propagate its transaction
20:25:09 <cdecker> t-bast: you wouldn't believe how many papers I'm reviewing that look into the Bitcoin + LN node pairing xD
20:25:33 <t-bast> cdecker: Bitcoin + LN, so hot right now (#zoolander)
20:25:42 <BlueMatt> ariard: well you'd want to go up like 4-5x current or so for future-proofing, and then nodes would only accept if its 2x, so biggest risk is dos of everyone force-closing due to update_fee.
20:26:03 <ariard> cdecker: sounds great, that's the research we need finally :)
20:26:50 <ariard> BlueMatt: and that's another vulnerability, mass closing of LN channels
20:26:51 <cdecker> ariard: the bad part is they usually just handwave the "how to associate a bitcoin node with an attached LN node" part, which is what I'd find interesting
20:27:13 <t-bast> rusty: not that it will help predict the future, but it would be interesting to run some stats and see if setting this in stone would have always allowed relaying a tx before 144 blocks
20:27:21 <BlueMatt> ariard: well thats the concern with making update_fee tighter - that dos was a real issue on the network even without attacks.
20:28:14 <ariard> cdecker: hmmmm so what they're researching on if it's not about cross-layer mappings ?
20:28:46 <cdecker> ariard: the easy part on how to abuse that fact
20:29:07 <cdecker> Anyway, sorry, didn't want to sidetrack this discussion
20:29:47 <ariard> I don't think that's a whole sidetrack, if people start to look more on cross-layer stuff, update_fee is both a vulnerability and fingerprint vector
20:30:22 <BlueMatt> everyone should just use my blocks-over-cloudflare anycast service! </troll>
20:30:36 <BlueMatt> (even if that *is* an actual service I run)
20:30:45 <t-bast> Please do package-relay-over-cloudflare and tell miners to connect to it
20:31:52 <rusty> I think we might be able to model what historical mempools might have looked like, using some simple assumptions.  Then figure out what the minimum fee in the mempool was at worst.
20:32:35 <BlueMatt> chaincode has a full dump of ever block/tx message its nodes received for like...the last 6/7 years
20:32:47 <BlueMatt> so theoretically its possible to use that, but someone has to dicipher suhas' hacky code.
20:33:02 <ariard> rusty: an alternative could be to look on feefilters messages
20:34:04 <rusty> BlueMatt: I was thinking cruder: for every block, take the 300MB of highest fee-per-weight transactions for the next 2000 blocks.
20:34:24 <BlueMatt> sure, but mempool timeout and such...
20:34:36 <BlueMatt> still, point is, the data exists, so its definitely an answerable question!
20:34:59 <rusty> BlueMatt: yeah, there are many subtleties, but I can hack up something to do this today and it should give a ballpark.
20:35:06 <t-bast> Let's try to sum up. IIUC, the only way we can safely remove update_fee is if we have package relay; in that case we can depend on CPFP only to relay our txs. Otherwise, we have to choose a fixed bound that seems historically acceptable, but that can be gamed (is that an acceptable temporary risk?). Last possibility is to find a way to do package relay outside of layer 1.
20:35:29 <t-bast> rusty: great, if we have that data it's at least a good way to continue the discussion
20:35:29 <BlueMatt> (rusty, fwiw, that data exists to provide people - I can hook you up with a vm which has the data on a local disk, if you want!)
20:36:12 <BlueMatt> t-bast: there's also my attempt at a compromise approach - change what number you look at for update_fee.
20:36:20 <ariard> t-bast: you can already game it, so that's not different from today
20:37:46 <ariard> t-bast: and package relay outside from layer 1 you still have to hack mempools for them to atomically evaluate package of txn, not only a pure p2p matter
20:38:07 <rusty> BlueMatt: hmm, could run a real node and actually look at mempool, but that's much more work, since you have to probably hack bitcoind to accept things.
20:38:13 <t-bast> BlueMatt: can we compare the variance of your proposed estimation compared to estimatesmartfee? That would be useful data
20:38:46 <BlueMatt> t-bast: yes, we should, that's kinda what rusty is signing himself up for :)
20:38:57 <BlueMatt> sooo...seems like a sensible way forward, report back in 2 weeks?
20:39:10 <t-bast> ariard: I feel that the gaming vector becomes more dramatic, because if all channels in the network use the same feerate, an attacker that keeps the "global" mempool filled for long enough can attack all LN channels at once
20:39:51 <t-bast> ariard: maybe in practice it's not worse though, I need to dig further
20:40:02 <ariard> t-bast: yeah already thought about it, you can do this today and IIRC it would cost 2-3 BTC per block of delay given default mempool size
20:40:14 <t-bast> Great, let's move on to something else? What do you want to discuss next?
20:40:44 <t-bast> ariard: interesting...worth considering when you have a high-value node!
20:40:52 <ariard> just a last note, if I organize a irc meeting with core devs to talk about all these propagation issues, who is interested?
20:40:53 <BlueMatt> rusty: yes. there exists a (probably stale) patch to do so for the chaincode sim data. I agree it is a bunch more work, though, yes.
20:41:19 <ariard> because folks don't understand that much off-chain requirements and we don't coredev meetings to talk about this
20:41:21 <rusty> BlueMatt: heh, I'll do the simple one, since I can hack that with bitcoin-iterate.  I'll let you run the chaincode sim :)
20:41:41 <BlueMatt> rusty: damn it, now I have to go do work...
20:42:05 <t-bast> ariard: sign me up
20:42:10 <cdecker> ariard: I'd be interested in joining the meeting
20:43:00 <rusty> ariard: I would wake for that...
20:43:24 <ariard> coool, I'll try to scratch one in the coming weeks
20:43:39 <ariard> rusty: likely after the core p2p one, at least aj is wake up for this one
20:44:10 <ariard> t-bast: what other topics do we have ?
20:44:18 <t-bast> #action ariard to setup IRC meeting with core-devs to discuss these issues
20:44:50 <t-bast> We have: offers, lnprototest, route blinding, trampoline, and probably others :)
20:45:22 <rusty> t-bast: route blinding!  You can make promises about writing up the spec :)
20:45:47 <t-bast> #topic Route blinding
20:45:49 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/765
20:45:54 <rusty> (Oh, I'm going to write a set of posts on offers RSN, for anyone who wants a cheatsheet to catch up)
20:46:17 <t-bast> I'd love to have some crypto review on route blinding, it definitely needs more eyes on it
20:46:32 <t-bast> It really feels like a reverse-Sphinx, I may be missing an abstraction to make it better!
20:47:21 <t-bast> I've even done ASCII art, so it's somewhat easy to review :)
20:47:44 <ariard> t-bast: yeah I owe you a review on this one
20:47:49 <cdecker> Yep, thanks for the ascii art, it's really helpful t-bast
20:47:59 <t-bast> It's in the high-level design format for now, I'd like feedback on that before making it a real spec PR
20:48:21 <t-bast> Sure, reviewers time is precious, anything I can do to help the review be smoother please let me know
20:48:30 <t-bast> IIRC rusty has an implementation for c-lightning
20:48:55 <ariard> t-bast: the easy question, why not HORNET which has already been through a (hopefully) though crypto review ?
20:48:58 <t-bast> I also have a prototype in a branch somewhere, it's quite easy to implement once you already have all the sphinx primitives implemented (which we all do)
20:49:00 <rusty> t-bast: yep, it's pretty simple.  Actually *generating* the things is more work, but handling them per node is easy.
20:49:03 <cdecker> I'll definitely give it another round 👍
20:49:34 <t-bast> Good question ariard, conner has promised me some hornet goodies, he owes me a ton of beers because he's late on that xD
20:49:55 <t-bast> My main critic of Hornet is that I think it doesn't optimize for what LN needs
20:50:18 <ariard> t-bast: lol DoS you with beer, and when you're drunk merge quickly HORNET, good tactic
20:50:19 <t-bast> Hornet takes longer to setup a circuit than Sphinx; it only becomes useful if you reuse that circuit (ie onion path) a lot
20:50:20 <rusty> ariard: HORNET is great for establishing a stream.  But all our comms is 1-shot; even offers.
20:50:43 <t-bast> exactly, in our cases you want to switch paths very often, and they clearly aren't long-lived
20:50:49 <t-bast> so I'm not sure it's a good fit
20:51:01 <ariard> rusty: right, even with cancellable payments if and when we have PTLC ?
20:51:09 <t-bast> but I may be missing something, so we'll need some input from conner there
20:52:01 <rusty> ariard: it's not clear we want any kind of "cancellable payments".  But HORNET lets you avoid state, which you can't do anyway with payments.
20:52:59 <cdecker> I don't know about cancellable payments, but stuckless payments with a user provided secret being mixed in is something that I'd like
20:53:31 <t-bast> I agree with cdecker, the construction for that is quite reasonable and really helpful when a payment is stuck!
20:53:45 <ariard> AFAIK cancellable payments are stuckless payments, just the scriptless version https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md?
20:54:25 <cdecker> Thanks for the link ariard (adding it to my read-list) :-)
20:54:43 <ariard> well IIRC this protocol is courtesy of t-bast
20:55:30 <t-bast> I simply formalized what was proposed by the nayuto guys in the scriptless-scripts repo to ensure it doesn't get lost ;)
20:56:19 <ariard> t-bast: lol you escaped to the elichai's reuse sha midstate version :)
20:56:58 <t-bast> ariard: I scratched my head *a lot* about this one, but I couldn't find a way to do it without changing the commitment scripts so it was a no-go...
20:57:01 <rusty> FWIW< I don't think stuckless payments actually win anything in practice.  They narrow the window, sure, but I think it's a dead end.  You still need to handle griefing.
20:57:11 <ariard> okay so a priori route-blinding suits more our needs, but we aren't sure it's completely future-proofs for use-cases we're sure are useful
20:58:01 <ariard> *aren't sure are useful, sorry
20:58:12 <t-bast> route blinding is great for wallets today: it would allow us to have private invoices and provide better privacy/deniability for wallet users
20:58:37 <t-bast> but I'd really like more scrutiny on the crypto itself
20:58:40 <rusty> t-bast: and it forms a great basis for simple messaging, as this same technique is used for the reply path.
20:58:45 <t-bast> wouldn't want to roll my own crypto xD
20:58:58 <rusty> ... which offers requires.
20:59:19 <t-bast> yes, it's a good way to open the door for messaging and offers!
21:00:12 <t-bast> so please have a look at it when you have some time, tell your cryptographer friends, beers on me for those who find vulnerabilities
21:00:18 <ariard> and what if we implement some for of FEC thanks to cancellable payment + MPP, you send more than you need and only reveal secrets fulfilling payee requirement?
21:00:48 <rusty> ariard: you mean, DoS the network to increase payment reliability? :)
21:01:00 <ariard> t-bast: sure, I'll ping some people who might help there
21:01:26 <ariard> rusty: hmmm if you pay for upfront payments is this a lawful usage ;) ? I don't know
21:01:51 <ariard> it would be really selfish I concede
21:01:54 <rusty> ariard: yes, if we have part-up-front payment and penalties for going over time, sure.
21:02:08 <rusty> (We'll need these eventually anyway, but they're hard to get right)
21:03:08 <ariard> yeah I think it's too far anyway because PTLC/schnorr, so we can still move to HORNET in the future if needed, even it's costly in deployment?
21:03:52 <rusty> ariard: you don't need HORNET since each node has to keep state anyway?
21:06:04 <ariard> rusty: you mean we can't have HORNET semantic or we don't need? I read the paper a while ago sorry
21:06:19 <t-bast> I'm not sure we need it at all
21:06:24 <rusty> ariard: don't need.  HORNET's main trick is the lack of state in the nodes.
21:06:55 <t-bast> Looks like we've gone over 1h, shall we end now? Or is there something else you'd like to discuss?
21:07:29 <ariard> I think we're over, it's more doing the promised reviews :)
21:07:41 <cdecker> Well, we keep state at nodes if there is a payment going on (HTLCs + extra), but for non-payment related communication hornet could make sense
21:08:38 <t-bast> #endmeeting