20:09:17 <niftynei> #startmeeting
20:09:17 <lightningbot> Meeting started Mon Aug 31 20:09:17 2020 UTC.  The chair is niftynei. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:09:17 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:09:33 <rusty> Looking through the list there's nothing urgent.  Might be nice to discuss what people are working on, e.g. dual funding, offers, random routing?
20:10:25 <roasbeef> oy
20:10:44 <niftynei> That sounds like a plan. Open floor then. Does anyone have a topic, PR or issue they'd like to discuss?
20:11:15 <roasbeef> thanks for the latest comments on the ML rusty  re dynamic commitments
20:11:23 <ariard> right, what's the state of dual-funding?
20:11:50 <rusty> Oh, yeah, dynamic commitments FTW too!
20:12:12 <niftynei> sure, i can give a brief dual-funding update.
20:12:13 <roasbeef> i'm working on a stand alone docuemnt describing a protocol extension, trying to get away from editing the spec in-line, as it can be hard to review and also jsut see at a glance what's the "base" version of things
20:12:14 * bitconner pulls up a seat
20:12:37 <roasbeef> so it would be a more BIP-like stand alone doc, and ppl can say oh I implement "bolt exttension 0002" or w/e it's called
20:12:53 <roasbeef> hopefully should have the initila draft up, then we can go from there to iterate
20:13:04 <niftynei> the implementation is in progress, i'm looking to have a draft for the spec out as soon as the impl is done
20:13:05 <roasbeef> if no other q's on that, can give niftynei the floor to talk about dual funding
20:13:39 <rusty> roasbeef: yeah, cool.  I think it'll be fairy easy to implement, TBH.
20:14:45 <roasbeef> def, hoping also it can serve as a possible new template for spec extensions that're more de-sync'd and standalone, as we basically have a buncha if statements in the spec rn that can be hard (imo) for a new implementer to parse
20:15:03 <ariard> niftynei: does the spec is ready for another round of review?
20:15:23 <niftynei> does anyone have a link to the mailing list post on dynamic commitments handy?
20:15:47 <ariard> roasbeef: does this would scope the recent proposal for skipping channel confirmation
20:15:57 <ariard> this kind of stuff doesn't have to be part of the "hard" spec IMO
20:16:24 <roasbeef> ariard: i think yes and no, imo it should be in the spec given it may have considerations on the invoice, or what's sent in the payload
20:16:25 <ariard> niftynei: this https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html ?
20:16:38 <niftynei> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
20:16:42 <niftynei> ty!
20:17:00 <roasbeef> as rn it may not be explciit in the spec, but nodes out of the box don't allow zero conf channels from the get go
20:17:08 <niftynei> #topic dynamic commitments
20:17:39 <roasbeef> it may also be a chance to just start to using a pubkey rather than a chan id, since hte pubkey is set in stone, and using tlv we can provide that only to the final hop, then the final and true dest can use w/e protcol to decide which chan to dispatch on
20:17:46 <ariard> I read again the spec, it's really fuzzy on this, like doesn't explicitly forbid minimum_depth=0
20:17:53 <lnd-bot> [13lightning-rfc] 15rustyrussell opened pull request #798: DRAFT: Offers (06master...06guilt/offers) 02https://github.com/lightningnetwork/lightning-rfc/pull/798
20:17:59 <roasbeef> yeh it doesn't, but in practice I don't think anyone allows it
20:18:08 <ariard> but also onion payload should be flexible enough to let anyone play with them with all network supporting parsing
20:18:23 <roasbeef> but there're nodes out there that use it now for their services like phoenix and breez
20:18:41 <roasbeef> ariard: yeh, may just need some new invoice tag
20:18:56 <ariard> right, and they would like to standardize their services ?
20:18:56 <rusty> roasbeef: yeah, for onion messages I allow either scid or pubkey.  Though I've gone for 32-byte pubkeys...
20:19:05 <rusty> roasbeef: yeah, a new invoice feature bit?
20:19:08 <ariard> it's mostly a namespace issue post-tlv ?
20:19:14 <roasbeef> ariard: yeah, just so ppl know what's supported and expected
20:19:29 <roasbeef> ariard: i think so yeh, but has some spec implications as ppl need to know what the standard way of doing it
20:19:32 <roasbeef> and also the risks, etc
20:19:41 <roasbeef> rusty: yeh i think minimally that'd be enough
20:19:55 <roasbeef> simpler, as then there's no need to negotiate a special sid
20:19:57 <ariard> roasbeef: does the keysend/spontaneous payment thing should go in this proposed  spec extensible subspace
20:20:01 <roasbeef> sci? short channel id lol
20:20:14 <roasbeef> ariard: so i think that's better as a standlone doc, and extension like thing
20:20:23 <roasbeef> since it's just about how to interpret data which you can already transmit on the network now w/ tlv
20:21:00 <roasbeef> but there's also a meta topic here, w.r.t how the best way to evolve the spec in a "scalable" manner is, while also having the opportunity for ppl to document higher level application protocols
20:21:05 <ariard> and that's what you've in mind for the BIP-like stand alone doc, a repository of canonical onion payload or looser/stricter policies
20:22:05 <ariard> we have what 3 level ? core spec, custom payloads/policies and clearly experimentation?
20:22:31 <roasbeef> ariard: yeh, which are maybe linked from the main spec depending on the section and what's the "default", etc
20:22:38 <rusty> roasbeef: cdecker has thoughts on that.  He wants the separate rationale doc for each one, which I kind of agree with.  Though some stuff still has to be core, esp. if it's planned to obsolete existing stuff.
20:22:47 <roasbeef> rn we have of this in the wiki (which versions are used, etc), but it isn't very structured
20:23:34 <roasbeef> rusty: mhmm, like rn when someone goes to implement channel state machine for the first time, they'd presented w/ basically 3 diff ways to do it which can be confusing, not sure but just trying to put myself in the shoes of someone getting into this stuff for the first time
20:24:11 <roasbeef> also in this path there wouldn't just be some like mega doc for stuff like routing/forwarding which is a rather large space
20:24:51 <roasbeef> but i'll kinda loosely propose a format w/ the dynamic commitments spec draft, then we can take feedback from there to arrive on kinda a teplate
20:24:54 <roasbeef> template*
20:25:21 <rusty> roasbeef: yeah, go for it.  At worst, we end up merging it afterwards, but that's easier than mangling in place anyway.
20:27:04 <niftynei> sounds like we're really talking about a meta topic here, how to update the RFC structure to accommodate documentation for spec 'extensions'
20:27:54 <rusty> niftynei: even better, roasbeef just volunteered to do a trial balloon!
20:29:04 <ariard> niftynei: wrt to dual-funding, there is a slight issue where a counterparty propagate both a double-spend a dual-funded tx, effectively blocking you to CPFP it
20:29:44 <roasbeef> ok let's go to dual funding now?
20:30:20 <niftynei> #action roasbeef to trial balloon new 'bip-like' format for spec extensions with dynamic commitments
20:30:26 <niftynei> sure sgtm
20:30:32 <niftynei> #topic dual funding :tada:
20:31:12 <niftynei> im working on the implementation, ive got a few lnprototests done for one half of the protocol stuff, hoping to get the other half done by the next meeting
20:32:05 <niftynei> ariard, i'm not sure waht you mean by "where a counterparty propagate both a double-spend a dual-funded tx"
20:32:07 <rusty> Two Weeks(TM)
20:32:10 <roasbeef> oooooOOOo, lnprototests
20:33:05 <niftynei> yeah, there's an accepter + opener "side", the accepter side has two working prototests stuff -- honestly it's much nicer than the first draft of lnprototests that rusty had going
20:33:54 <rusty> The protocol is important because we can reuse it for shutdown / splice.  It's a generic tx negotiation protocol.
20:34:09 <ariard> niftynei: Alice commits 1 BTC, Bob commits 0.1 BTC in their dual-funding tx, they exchange signature, Bob propagate a RBF-disabled low-feerate double-spend of his 0.1 BTC
20:34:28 <niftynei> ok so the dual-funded tx won't get confirmed
20:34:41 <ariard> niftynie: Alice will broadcast the dual-funding, which would perevent her to double-spend back until it expires from her mempool
20:35:00 <ariard> niftynei: yes you block dual-funded tx propagation across network mempools
20:36:10 <roasbeef> ariard: why's that an issue? w/e gets confirmed first gets confirmed
20:36:13 <rusty> ariard: but Alice can also spend her way out when she gets sick of waiting?
20:36:13 <niftynei> that dual-funded tx is dead-on-arrival then
20:36:15 <roasbeef> which is why confs are nice
20:36:32 <niftynei> alice just spends her 1btc elsewhere ??
20:37:19 <ariard> rusty: assuming broadcast the funding tx in her mempool, her honest double-spend back will be rejected by her own mempool if it's not superior to funding_tx feerate/absolute fee
20:37:22 <roasbeef> the core thing here seems to be the "back out" shenanigans, so ppl doing set up then just bailing after they get w/e info they're after
20:37:30 <ariard> assumig she broadcasts
20:37:44 <rusty> ariard: sure.
20:37:48 <roasbeef> but re the pinning or double spend thing, doesn't seem like an issue assuming the channel isn't used til stuff confirms
20:37:59 <ariard> roasbeef: it's not a fund-loss risk, more I stuck your funds in mempool for nothing
20:38:09 <roasbeef> yeh it's a nuisance thing kinda
20:38:21 <roasbeef> but what does the perpetrator gain?
20:38:29 <roasbeef> they also end up wasting their time and chain fees
20:38:35 <niftynei> by stuck you mean subject to RBF, i'd assume
20:38:42 <ariard> yes a nuisance, better would be to have redundant tx broadcast, to avoid being obstrucated by your own mempool
20:39:01 <roasbeef> redundant tx being what?
20:39:10 <ariard> roasbeef: they may force you to loose more timevalues on your funds than him, as inputs might not be worth the same
20:39:10 <roasbeef> like some intermediate mult-sig output?
20:39:20 <niftynei> as long as alice set her sequence to be RBF'albe she'll always be able to spend that utxo input elsewhere
20:39:23 <roasbeef> ariard: sure a whale doesn't care I guess lol
20:39:56 <roasbeef> the real solution is to just burn all the mempool policy stuff to the ground
20:39:58 <ariard> roasbeef: sure, but few hours of funds pinned in the mempool is less liquidity in channels :)
20:40:00 <roasbeef> and use rbf everywhere
20:40:04 <roasbeef> kek
20:40:10 <roasbeef> full rbf*
20:40:11 <rusty> ariard: you can't simultaneously exchange sigs, so there's always a case where only one side can broadcast if malicious, right?
20:41:05 <ariard> rusty: sure simultaneously exchange sigs doesn't exist, but in fact exchange delta is inferior to tx-relay propagation on base layer
20:41:23 <ariard> so in practice even if malicious is second, you can beat the honest one by connecting to a lot of nodes
20:42:20 <ariard> I think that's a slight issue, and not much we can do, just to be aware of
20:42:28 <niftynei> im not seeing the harm here other than 'a few hours of theoretical liquidity not existing' which seems about the same as a channel peer falling offline, no?
20:42:37 <roasbeef> idk how much I'd be worried about something like this myself if I had a dual funded node, I think most implemetnations also have the ability now to preferenttially accept/reject inbound funding requests
20:42:54 <rusty> ariard: I don't think we want to require an extra tx for opening everywhere though.
20:42:57 <roasbeef> it also isn't costless, tho ofc "cost" is relative
20:43:03 <roasbeef> yeh mo txns mo bad
20:43:17 <ariard> a real question is the fee model of dual-funded, IIRC it's only RBF for now, there is no anchor outputs to let non-interactive fee-bumping?
20:43:37 <niftynei> no there are no anchor outputs on dual-funded open tx, it's all RBF
20:43:51 <roasbeef> that could be added, or the protocol sends out diff sig versinos fo bump, but that requires no_input for the commitments
20:44:01 <ariard> rusty: sure I agree not worth fees/blockchain space, loosing few hours of liquidity is okay for now, but in the future it might an important channel opening and just break your whole liquidity strategy for the day
20:44:10 <roasbeef> so you pre-sign like incrementing fee rate versions (this may already be in the draft, I'm out of date)
20:44:20 <roasbeef> we also def talked about this in adelaide too iirc
20:44:29 <roasbeef> years later....we're still talking about fees lol
20:44:30 <rusty> ariard: yes, which is why we need mempool to be more adversarial-safe.  In general this statement is true :)
20:44:43 <ariard> roasbeef: the ability to accept/reject inbounb assumes a key management policy ?
20:45:06 <roasbeef> ariard: idk if needs key management, but some sort of heuristics to gate off of
20:45:07 <ariard> rusty: I know, for now I'm just trying to inform core devs they should have a stable mempool policy: https://github.com/bitcoin/bitcoin/issues/19820
20:45:07 <niftynei> multiple feerate bands are not in draft, it's assumed you'd just go back and re-negotiate if the feerate changes (i.e. rbf)
20:45:18 <roasbeef> like: only accept from nodes that hav ebeen around for T period of time w/ N btc in chasn or somethign like that
20:45:21 <ariard> which is a philosophical change wrt to how they think p2p issues until now
20:45:50 <roasbeef> it's p2p, but at the end of the day, these are voluntary actions, and not all nodes are super well managed, tho that's getting better imo w/ better tooling, etc
20:45:58 <ariard> well they should have something like a policy, not policies-undocumented-across-versions-which-may-silently-break-LN-nodes
20:46:04 <niftynei> the 'preprint' (lol) dual funding draft is over here https://github.com/niftynei/lightning-rfc/pull/1, no guarantees it'll be the same in two weeks though lol
20:46:08 <niftynei> #link zv
20:46:10 <niftynei> #link https://github.com/niftynei/lightning-rfc/pull/1
20:46:20 <roasbeef> guard rails like that, also mitigate certain classes of attacks by making it harder to make wide spread connectiosn to exiting nodes
20:46:27 <roasbeef> you gotta work your way up basically
20:46:40 <ariard> roasbeed: I was just pointing we should adresss mempool/p2p issues at their level if we can, while minding if we can address at upper layers that might good too
20:46:44 <roasbeef> ariard: idk if it breaks nodes, but the error message can be used to explain some of the policy
20:46:54 <roasbeef> ah yeh, hard to keep track of all the convos rn kek
20:47:05 <niftynei> we'll probably be talking about fees in 2040 still lol
20:47:15 <ariard> roasbeef: for now we don't have any API stability of something like carve out
20:47:34 <roasbeef> yeh....one thing I've learned is never underestimate the complexity of fees w.r.t any sort of off-chain multi-party protocol
20:47:53 <roasbeef> member when we could just ignore it all together?
20:48:01 <roasbeef> those were the days....
20:48:09 <rusty> roasbeef: yeah, hide "and we ignore fees" in the preamble of your paper, and publish!
20:48:12 <ariard> niftynei: negotiating back assume interactivity which is not great
20:48:36 <niftynei> having a channel open assumes interactivity
20:48:38 <ariard> like your funds might be in a cold wallet, your fee model is wrapping on your key management setup
20:48:50 <roasbeef> rusty: lol yeah, "for simplicity of our model..."
20:49:17 <ariard> niftynei: yes, and that's maybe okay to do back-and-forth with your cold wallet but once it broadcasts, during the wallet round-trip feerate may change again
20:49:19 <roasbeef> niftynei: ariard if this is about rbf for fee bumping, why not just pre-sign N versions w/ increasing fee rates? that can be done in a single shot, but needs no_input as mentioned
20:49:38 <roasbeef> also, how are we even talking about rbf dual funding bumping w/o no_input? otherwise you need to sign commitment sigs again
20:50:06 <rusty> roasbeef: yeah, you basically start renegotiating to double-spend the first one.
20:50:20 <rusty> It's simple, and handles fee spikes.
20:50:22 <niftynei> the v1 of dual funding "rbf" is identical to "let's restart this discussion"
20:50:24 <ariard> roasbeef: so far, any off-chain multi-party protocols I've looked on has weird fee isssues, LN just opened the way
20:50:31 <roasbeef> niftynei: gotcha
20:50:50 <roasbeef> ariard: yeh seems to be a given now, something protocol designers need to always keep in mind from here on out
20:50:54 <ariard> roasbeef: hmmmm multiple RBF versions you blindly give your counterparty to overshoot in fees
20:51:07 <ariard> like taking the higher bound when feerare is low, and thus burning
20:51:10 <rusty> ariard: "Good news, everyone, we're pioneers!  Also, that's the bad news"
20:51:19 <roasbeef> ariard: heh there's that too, you'd basicaly need to decide what the upper bopund is, and if you're splitting, then everyone either pays more or less
20:51:33 <ariard> but that's okay if everyone is throwing in the pot the same prorata
20:52:20 <rusty> Current fees are paid by input and output weights, via simple formula.
20:52:23 <ariard> roasbeef: you right you need to sign for every commitment, so it's leaking further down in protocol pipeline
20:52:40 <roasbeef> leaking what?
20:52:48 <roasbeef> rusty: fsho makes sense
20:53:01 <ariard> roasbeef: funding_signed is only one commiment signature?
20:53:15 <niftynei> we've got about 10 minutes left before the meeting time ends, are there any other topics we should spend time on?
20:53:39 * rusty changes networks, BRB
20:54:56 <niftynei> i know rusty's been working on random routing + offers stuff, not sure if any of that is ready for discussion.
20:54:57 <ariard> in fact we don't need to agree on a anchor output for dual-funding? you can at wish output so just ensure you have one as a local node policy?
20:55:01 <roasbeef> other thing to mention on our end is that our 0.11.1 version will include the spec compliant anchors version
20:55:17 <roasbeef> which just means a slight change to the co-op close fee structure, and also using the "official" feature bit
20:55:32 <roasbeef> ariard: the anchor is essentially just your change addr right?
20:55:47 <ariard> roasbeef: exact
20:55:48 <roasbeef> niftynei: random routing meaning at the client path finding level/
20:55:52 <roasbeef> ?
20:56:04 <niftynei> oh. you can add whatever outputs you want to a interactive tx ... if you wanted an anchor output you could just add it
20:56:14 <ariard> roasbeef: btw, you should propose anchor as a BIP, I mean other protocols are going to re-use it :)
20:56:23 <ariard> like CoinSwap
20:56:44 <roasbeef> ah cool, yeh I can see it being a pattern used depending on the context for most off-chain stuff going forward
20:57:19 <ariard> it works for any dual-party protocols ? and I don't see anyone working on N-party protocol before no_input
20:57:25 <niftynei> roasbeef, yah rusty can say more but the high level is choosing random routes to reach a destination
20:57:53 <rusty> BTW our next release we decided not to activate anchors (outside --enable-experimental-features), as we don't have any code to CPFP yet, so it's just overhead.  Anyone want to change my mind?
20:58:00 <roasbeef> niftynei: gotcha, we _kinda_ do this rn, as we have an internal weighted graph where the weights now are a scaler score dervied from a proability of "success"
20:58:15 <roasbeef> gotcha yeh for us it's still behind a flag rusty
20:58:27 <roasbeef> we want to enabel by default w/ 0.12 hopefully after we add watch tower support and deadline aware fee bumping
20:58:35 <niftynei> ariard, the protocol is dual but it's written such that you'd be able to dual-fund multiple opens in the same tx
20:58:37 <rusty> roasbeef: nice!
20:58:48 <roasbeef> rn we also don't yet modify our fee estimate for the comitment trnasaction, but can start to low ball that more once we have the fee bumping in
20:58:58 <roasbeef> oh someoone did some cool analysis on our issue tracker re fee bumping
20:58:58 <roasbeef> sec
20:59:13 <roasbeef> realted to like what "fee function" to use for bumping and other hueritics
20:59:14 <niftynei> you'd still be opening 2-party channels tho, so that doesn't really change much
20:59:17 <rusty> roasbeef: yeah, I figure that mroe than balances the fee increase if done right.
20:59:34 <roasbeef> here it is: https://github.com/lightningnetwork/lnd/issues/4215#issuecomment-678177590
20:59:51 <ariard> niftynei: right, dual-funding is 2-party even if you can run it in parallel with multiple-parties, you only have 2 roles
20:59:56 <roasbeef> and a fancy jupyter note book: https://colab.research.google.com/drive/10O0pi_7YR9ZaZB6yUAdcsocFGPpKADER?usp=sharing
21:00:04 <roasbeef> w/ 3d graphs n stuff
21:00:16 <niftynei> #link  https://github.com/lightningnetwork/lnd/issues/4215#issuecomment-678177590
21:00:23 <niftynei> #link https://colab.research.google.com/drive/10O0pi_7YR9ZaZB6yUAdcsocFGPpKADER?usp=sharing
21:00:28 <niftynei> faaancy
21:00:42 <roasbeef> this is related to the problem of: "when do we bump, how do we target the size of the next bump, how late in the deadline should we bump"
21:00:51 <rusty> roasbeef: pretty!!
21:01:05 <roasbeef> the initial model is still missing some params, but it is based on looking at historical data of what got into the chain, and then what the fee rate was where "n %" got in, etc
21:01:32 <roasbeef> the top level comment summarizes the initial findings, feel free to dig into the notebook for more info, and you can also fork/edit it I think to poke around more
21:01:49 <BlueMatt> roasbeef: it looks like that model doesn't consider any kind of feerate estimator which may change over time?
21:02:05 <roasbeef> yeh the limitations are stated at the end
21:02:08 <BlueMatt> just a pure "well, we guess a fee at the beginning, how should we bump" model? (just checking my understanding)
21:02:18 <roasbeef> yeh hard to factor that in right? since ppls fees will impact the estimator right?
21:02:36 <roasbeef> imo i want to live in a future where we almost never look at fee estiamtors, and just low ball then bump up, taking into account past info of attempts
21:02:43 <BlueMatt> depends on the estimator....some of them look at the mempool, some less so.
21:02:46 <roasbeef> as they're so prone to manipulation
21:02:56 <roasbeef> at least the default type used in bitcoind and elsewhere
21:03:05 <BlueMatt> heh, well thats why core's doesnt really look at the mempool :)
21:03:21 <roasbeef> orly? has it chagned recently ?
21:03:31 <BlueMatt> it never (really) did
21:03:35 <roasbeef> i thought it looked at the percentile that confirmed at a given fee rate taking into account "wait time"
21:03:38 <ariard> darosior is trying to write decent documentation around
21:03:46 <roasbeef> which means looking at the mempool w.r.t when it "arrived"
21:03:51 <BlueMatt> it does, but only marginally at the edge, i believe its about the only fee estimator that tries hard to not look at the mempool
21:04:02 <BlueMatt> sure, it looks at "things which were in my mempool which got into blocks"
21:04:10 <BlueMatt> note that last part is what makes it relatively hard to manipulate
21:04:21 <roasbeef> BlueMatt: yeh there's an assumption of some starting point (fee guess the fee), fee estimation and historical data coul dbe used as an achor, it assumes we no longer try to thread the needle w.r.t exact conf delays
21:04:26 <BlueMatt> (the first is required also to prevent manipulation in a different way)
21:04:51 <BlueMatt> ok, just checking my understanding, cool work.
21:05:01 <ariard> core fee estimator is sorting txn across feerate bucket and when a block confirm, kinda score feerates
21:05:12 <ariard> something something like this
21:05:27 <ariard> and reorg-safe/mempool-resizing safe
21:05:29 <roasbeef> gotcha, seems it's changed a bit since I looked at it last a while ago, will refresh my mental model of it
21:05:32 <BlueMatt> (other approaches, eg, whatthefee.io are much more accurate, but of course easier to manipulate)
21:05:50 <BlueMatt> roasbeef: nah, it *always* avoided looking too hard at the mempool. since first merge iirc.
21:06:10 <roasbeef> but my manipulation I mean like the effect we see where someone using really high fes to make some arb play affects everyone else's estimation that blindly targets a short term conf target
21:06:19 <roasbeef> imo it looks at the mempool in sofar as it wathces "delay"
21:06:30 <roasbeef> as it's based on its view of "what got in"
21:06:37 <BlueMatt> ah, well everything is manipulable if you want to get into the next block, but is it really manipulation if its true :p
21:06:38 <roasbeef> but ofc if it never saw something, then it can't use that as a data point
21:06:43 <roasbeef> kek
21:07:01 <ariard> roasbeef: do you mean network-wise or targeted node manipulation?
21:07:27 <roasbeef> I mean like "the observer effect"
21:07:53 <ariard> we could model the cost of such fee inflation attack and default mempool size (300MB) to know how much it would cost
21:08:43 <ariard> I see, heisenbug applies to fee-estimation
21:08:46 <rusty> AFAICT, you can use OOB feepays to drive apparent fees to great heights while not taking a loss (i.e. not having to stuff blocks yourself) and let feerate estimators run wild then profit.   Only real miner decentralization helps against this AFAICT?
21:09:10 <roasbeef> cool chat y'all, will follow the rest in logs, off to lunch!
21:09:30 <rusty> roasbeef: thanks, later!
21:09:32 <BlueMatt> rusty: I believe in terms of OOB fee attacks, the best you can do is drive *down* estimators (as it appears to outside observers that the prevailing fees are lower)
21:10:06 <BlueMatt> rusty: *however*, if you allow txn which were not in your mempool when they confirmed to effect your estimator, then, indeed, you could, but this is why core requires both "was in my mempool" and "got confirmed" :)
21:10:18 <ariard> BlueMatt: but driving them down means relying on what you effectevely see in your local mempool ?
21:10:34 <rusty> BlueMatt: indeed.
21:11:05 <BlueMatt> (I do not know what other estimators do, my understanding is that they roughly just look at the current mempool, so, are way more manipulable than this)
21:12:00 <ariard> rusty: I'm not even sure miner decentralization prevents one power-miner to add huge fees to himself?
21:12:17 <rusty> BlueMatt: No, wait.  You fill your blocks with OOB txs, plus top 10% from mempool.  This drives core's estimate up.  Keep repeating (assuming demand enough to cause a fee spike)
21:12:58 <rusty> This is the trivial "reduce blockspace to drive fees" but you don't have to pay as much for it, since you are getting some fees.  Assuming txs with OOB are *not* in mempool.
21:13:00 <ariard> so it sounds if you want to be secure against manipulation of your local mempool you need background-check against blocks, while minding block feerate can't be trusted
21:13:08 <BlueMatt> rusty: if the txn were in the mempool, then the attacker runs the risk of paying other miners the fees for said txn (which, my point above stands, you're not manipulating so much as just increasing the fees by paying)
21:14:10 <BlueMatt> if the oob txn have lower fees, and you're taking oob payments to "virtually increase" the fees, then you're driving the estimator down, but probably not actually working
21:14:38 <BlueMatt> the current estimator says "at what feerate did transactions take longer than X blocks to get confirmed"
21:14:39 <ariard> your local fee estimator should discard blockspace not previously seen in local memmpool, that's all?
21:14:39 <rusty> BlueMatt: not if the txs are not in the mempool. Core ignores them, only sees the expensive ones.
21:14:43 <BlueMatt> where X is the target you set.
21:15:20 <BlueMatt> rusty: ah, right, so core isnt looking at what the common/median/whatever feerate is, its looking at what the lowest is.
21:15:44 <BlueMatt> so even if every block is 95% billion-bitcoin fees, it'll happily pay less as long as lower fee is getting confirmed reliably
21:15:52 <niftynei> we're 15min over time, i'm going to go ahead and endmeeting
21:15:57 <rusty> Anyway, we're kinda off-topic.  Anyone have something lightning stuff? :)
21:15:57 <niftynei> #endmeeting