19:11:20 <bitconner> #startmeeting
19:11:20 <lightningbot> Meeting started Mon Nov 11 19:11:20 2019 UTC.  The chair is bitconner. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:11:20 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:12:58 <bitconner> okay first up
19:13:03 <bitconner> #topic flat features https://github.com/lightningnetwork/lightning-rfc/pull/666
19:13:14 <bitconner> i think this is pretty much gtg
19:13:40 <rusty> Ack!
19:13:49 <bitconner> mostly touch ups, are there any concerns about overall design?
19:14:18 <bitconner> i implemented this last week and it was quite nice to have only one namespace
19:14:56 <rusty> Just acked t-bast's minor touch-ups, too.
19:15:02 <rusty> bitconner: yeah, it's nice to remove code!
19:15:04 <bitconner> rusty: to clairfy, invoice features have the same namespace as everything eles, yes?
19:16:07 <rusty> bitconner: yep, though the actual implementation of that is in the MPP PR IIRC.
19:16:44 <bitconner> awesome! i'm sold
19:16:45 <bitconner> ack
19:17:43 <rusty> Yay!
19:17:57 <roasbeef> yeh in the end, just nice to have one namespaces, we could've used a more compact encoding for feature bits at the start, but kinda of too late to apply one to the existing fields
19:18:51 <bitconner> sstone: thoughts?
19:19:03 <cdecker> Pretty much, makes things just context-free and easier to interpret :-)
19:19:15 <sstone> ack from us too :)
19:19:21 <bitconner> cool :)
19:19:37 <bitconner> #action rusty to touch up lingering comments
19:20:07 <bitconner> #agreed flat feature design is solid
19:20:25 <bitconner> nice worky rusty!
19:20:45 <bitconner> #topic base amp https://github.com/lightningnetwork/lightning-rfc/pull/643
19:21:53 <bitconner> primary discussion seems to be around signaling and feature bits now?
19:22:22 <rusty> Yeah, I'm going through them.
19:22:53 <rusty> I don't think we should require basic_mpp support for secret support.
19:23:42 <rusty> Hence we need separate BOLT11 features, one to say "I support MPP" and one to say "I support/need secret".
19:24:06 <roasbeef> it's possible to have one feature bit, then clients just cancel back if they ever get a partial payment when they can't handle combination
19:24:35 <bitconner> i would prefer two distinct feature bits to overloading var_onion_optin :)
19:25:04 <roasbeef> so one bit for I can combine and the other for include the payment addr?
19:25:18 <bitconner> yep
19:25:31 <joostjgr> i prefer just one feature bit that signals it all: tlv+mpp+secret
19:26:01 <cdecker> Agreed, returning an error and then having to retry is really disruptive
19:26:09 <sstone> joostjgr: but there are use cases for secret without mpp
19:26:12 <niftynei> joostjgr, that would require supporting all 3 simultaenously, no?
19:26:15 <cdecker> We have the feature bits for something, let's make use of them
19:26:25 <rusty> The idea of feature bits is fast failure: if you don't understand one, you can tell user immediately "I don't understand feature 12!" and they can google etc.
19:26:53 <joostjgr> if we are all agreeing that we implement tlv+mpp+secret, why is that flexibility needed. perhaps we ain't gonna need it
19:27:23 <joostjgr> the test matrix is bad enough already
19:28:00 <rusty> joostjgr: there are other implementations too...  I mean, I'm happy to combine, but since we're going to make secret compulsory as fast as we can, that implies MPP will be compulsory.
19:29:04 <bitconner> compulsory mpp still seems kinda vacuous to me
19:29:37 <roasbeef> sstone: seems those cases can just make the total amount the same as their first payment, so it's single shot
19:29:37 <cdecker> joostjgr: the compulsory feature bits can help reduce the test matrix again
19:29:37 <rusty> bitconner: I mean, you'll have to support it, not that they'll have to use it (though such signalling is possible, if you don't have suff incoming capacity in a single channel)
19:30:57 <roasbeef> side point on naming: the what's called the payment secret right now isn't reaaally secret in that's it's in the invoice, ppl post invopies, etc on twitter all the time. imo a better name is payment addr
19:31:28 <rusty> roasbeef: payment nonce?  People love reusing addresses :)
19:31:33 <cdecker> Ouch, calling it an addr is worse
19:31:41 <cdecker> Agreed that `nonce` is better here
19:31:51 <rusty> "Paymenbeef"!
19:31:57 <niftynei> payment noise?
19:32:05 <bitconner> it's only a nonce for one-time invoices
19:32:22 <cdecker> reference?
19:33:01 <bitconner> the amp proposal will include the payment addr/nonce/secret on each payment attempt
19:33:28 <niftynei> that hurts decorrelation, no?
19:33:42 <bitconner> nope bc it's only in the final hop's payload
19:33:49 <niftynei> kkk
19:34:12 <bitconner> in the amp case it's more like a routing/account number
19:34:12 <roasbeef> can be used to identify stuff like subscription payments or exchange deposits
19:34:23 <cdecker> Well, let's debate naming on the PR, and continue here about the concept :-)
19:34:26 <rusty> payment_atgnwt (all the good names were taken).
19:34:30 <joostjgr> i favor payment address. it is an id that means something to the receiver
19:34:31 <bitconner> lol
19:34:45 * cdecker will veto address
19:34:50 <bitconner> #action defer naming of payment_atgnwt to the pr
19:34:55 <cdecker> :-)
19:35:10 <joostjgr> another issue is the timing, although that isn't really a protocol thing. "SHOULD wait for at least 60 seconds after the initial HTLC." we are also thinking about resetting the timer with every set htlc that comes in
19:36:05 <rusty> joostjgr: yeah, I wasn't sure about that, which is why it's specified so vaguely.  Resetting o every htlc would meet that requirement.
19:36:18 <joostjgr> ah, "at least"
19:36:31 <joostjgr> we can also leave it vague indeed and figure it out in practice
19:36:41 <rusty> joostjgr: agreed!
19:36:51 <rusty> (That makes us look smart, too :)
19:37:12 <bitconner> re: feature bits, do we agree on not overloading `var_onion_optin`?
19:37:34 <cdecker> Isn't timing an implementation detail? We'll try to pay as fast as possible, if we can't complete in whatever the recipient thinks is acceptable we can't pay
19:37:39 <rusty> Back to feature bits, we need *some* feature bit so we can make it compulsory later to force secret use, right?
19:37:54 <cdecker> If you reset the timer on each HTLC you are basically replicating the slow loris attack...
19:38:09 <bitconner> rusty: yes
19:38:30 <roasbeef> would need to have additional mitigations ofc, wouldn't consier this an exhuastive list, just as we don't enumerate all the possible things that nodes need to defend against in the spec cdecker
19:38:34 <rusty> I chose to abuse var_onion_optin, which is not exposed in BOLT11 so far, and avoided adding YA feature bit.  Happy to revisit.
19:39:05 <cdecker> roasbeef: but why specify that particular detail then?
19:39:17 <rusty> (Since eventually, secret will be compulsory on final hop, as will var_onion_optin, dammit...)
19:39:20 <joostjgr> cdecker: if the goal is to plug up the commitment tx slots, there are still ways to do that without a resetting timer
19:39:29 <roasbeef> cdecker: so you'd rather specify no timeout precautions?
19:40:12 <cdecker> Yep, at least that doesn't suggest that it's in any way covering all issues
19:40:45 <rusty> - MUST fail all HTLCs in the HTLC set after some reasonable timeout.
19:40:45 <rusty> - SHOULD wait for at least 60 seconds after the initial HTLC.
19:40:46 <rusty> ^ This pretty much covers it, without being prescriptive about stuff we don't know yet.
19:40:57 <bitconner> rusty: indeed, tho still feels like we should keep them isolated, o/w it's kinda confusing that certain features have "side-effects" if you will
19:41:31 <bitconner> unintended* side-effects
19:41:54 <cdecker> Awesome the spec already covers slow loris then, no need to add hypothetical additional things like resetting a timer and then explaining the fallout that might ensue :-)
19:42:11 <rusty> bitconner: yeah, I had to invent an otherwise-useless-who-cares mpp feature to use in BOLT11 to indicate support already, in the assumption that we wouldn't be forcing final nodes to support.
19:43:08 <rusty> We can add a specific "payment_atgnwt_required" feature instead?
19:43:16 <rusty> s/required//
19:43:25 <bitconner> +1
19:44:04 <bitconner> so then we have payment_atgnwt and multi_path bits?
19:44:22 <rusty> That is basically only important in bolt11, but hell, put it everywhere else so we can measure adoption.  And it means "mpp and secret" or just "secret" and have YA feature for mpp?
19:44:47 <joostjgr> i still think the maximum number of new feature bits per spec PR should be 1
19:44:51 <rusty> Yeah, I think we keep mpp bit.  I like the separation, since I've implemented secret and not mpp so far.
19:45:01 <rusty> joostjgr: nice rule :)
19:45:01 <bitconner> its usefull on node announcments if you want to do keysend and don't have an invoice
19:45:18 <rusty> bitconner: but then you don't have a secret either?
19:45:26 <bitconner> sender generates it
19:45:39 <bitconner> or you mean payment secret?
19:45:44 <rusty> bitconner: yeah.'
19:46:02 <bitconner> payment secret isn't really required for keysend because theree's no invoice to probe
19:46:13 <bitconner> so sender just picks a random one
19:46:27 <rusty> bitconner: yeah, so knowing it requires payment_atgnwt doesn't really help does it?
19:46:31 <bitconner> if someone tries to probe ahead of a keysend payment then they are just donating to everyone they try
19:46:46 <bitconner> rusty: i was referring to mpp
19:47:07 <rusty> bitconner: oh, mpp right!  Yeah, that makes sense.
19:47:11 <bitconner> but in general, invoice features are useful on the node ann for cases like keysend
19:48:27 <rusty> OK, so separate feature bits.  Since that PR hasn't been rebased, the feature numbers are wrong.  Shall we allocate 14/15 to payment_atgnwt and 16/17 to base_mpp?
19:48:35 <bitconner> sgtm
19:49:33 <bitconner> #action rusty to update pr and assign 14/15 for payment_thing, 16/17 to base_mpp
19:49:33 <cdecker> ack
19:49:34 <rusty> joostjgr: would you prefer me split the PR into two as well?  Back into one for payment_notaddress and one for base_mpp?
19:49:57 <roasbeef> imo there's enough momentum on the single PR to warrant just keeping it unified
19:49:58 <joostjgr> no, that will be the same outcome :)
19:50:32 <bitconner> ack for combined pr, there is already light in this tunnel :)
19:50:34 <rusty> joostjgr: phew, yeah, I agree they're kinda tangled.
19:50:46 <joostjgr> rusty: i understand that you now have secret and not yet mpp and want to release perhaps, but this temp. situation will live on for quite some time on the network
19:51:00 <joostjgr> i think there are costs associated with that
19:51:08 <rusty> joostjgr: Naah I'll never do a release with just one, that would suck,
19:51:23 <rusty> joostjgr: but it's nice for testing to do one at a time
19:51:40 <joostjgr> then i definitely wouldn't split the bits
19:51:57 <joostjgr> but i guess i am alone with my opinion
19:52:09 <bitconner> why not? payment_thing is low hanging fruit that has tangible security/privacy benefits
19:52:28 <joostjgr> test matrix. if we never release them separately anyway
19:52:36 <rusty> joostjgr: last time we didn't split the bits, we had a bug which made things nasty; we said we'd go more finegrained so we could disable one thing if necessary.
19:52:50 <joostjgr> ok
19:53:24 <bitconner> ternary features ftw
19:53:48 <joostjgr> do we have time for a quick anchor state of things?
19:53:54 <bitconner> sure
19:54:08 <bitconner> #topic anchor outputs https://github.com/lightningnetwork/lightning-rfc/pull/688
19:54:22 <joostjgr> i've summarized the delta in the pr description. anyone seeing something there that doesn't look right?
19:55:38 <joostjgr> the discussion on update_fee yes/no ended kind of open. but it seems that there is no perfect solution atm and that with update_fee we at least have a better chance at getting the commit conf'ed
19:56:49 <rusty> It covers everything.  I'm a bit reluctant to leave update_fee, but OTOH it's already existing logic (though we've seen more bug reports of bag signatures recently, so maybe it's just damn toxic).
19:56:55 <ariard> but if you use update_fee so do not use anchor outputs
19:57:19 <joostjgr> our idea is that we initially target an emergency exit
19:57:33 <joostjgr> so keep everything as is and if an important confirm is needed, you can manually anchor down the tx
19:57:35 <ariard> I mean combo update_fee + anchor outputs is only useful if you bump feerate of commitment tx enough to get in mempool
19:58:08 <ariard> but if it's enough to get in, it's really likely your fee estimator give you a feerate to get in the confirme-soon tier
19:58:11 <joostjgr> next steps are to automate that process and go to lower commit_tx fees
19:58:11 <roasbeef> not, this is about getting into the block
19:58:31 <roasbeef> ariard: your confidence in fee estimators surprises me...
19:58:42 <roasbeef> idea for this is to just low ball, then bump based on your time prefernce
19:58:48 <roasbeef> forget the crowd
19:59:00 <ariard> roasbeef: but the whole point of update_fee is to trust fee_estimator
19:59:03 <roasbeef> but ofc, you may also have incoming HTLCs as well, so that's your other main signal
19:59:18 <roasbeef> update_fee becomes relaxed from: enough to get into the next block or soon, to: enough to get into the mempool
19:59:32 <roasbeef> later on once we have full packaged relay, we can phase it out possibly (update_fee)
20:00:25 <ariard> agree it's a relaxation of update_fee requirement, but it seems a really slight coverage
20:01:06 <ariard> and going to be useless once package relay is there
20:01:10 <roasbeef> it's a big deal on practice for deployed implementations, fees on idle commitments can now be much lower, no more users complaining about how most of their channel is somehow allocated for fees
20:01:14 <BlueMatt> but the issue is that update_fee doesnt do anything *today*
20:01:22 <roasbeef> BlueMatt: how so?
20:01:26 <BlueMatt> and there's only a very narrow band of fee changes where it makes sense
20:01:37 <roasbeef> ariard: have any notion on how far along the dev of that is? seems like a long ways away, and this is an issue today
20:01:40 <BlueMatt> cause its not practically enforced by a counterparty, and fees swing wildly from the time you send a payment to a month later
20:02:04 <BlueMatt> so it only makes sense if, eg, a feerate goes up some small percentage from the time you do a commitment update to when you want to broadcast
20:02:05 <ariard> roasbeef: https://github.com/bitcoin/bitcoin/pull/16401
20:02:08 <BlueMatt> which is....a completely useless requirement
20:02:08 <roasbeef> dunno what you mean by it isn't enforced, the rbf blocking stuff?
20:02:39 <ariard> IMO can go in 0.20, need more review (on DoS vectors) but general mechanism should work
20:03:03 <BlueMatt> like, you cant properly restrict your counterparty from sending you update_fees that are too high, and cause issues or too low, and cause issues, cause you cant even possibly *pick* an update_fee that makes sense
20:03:21 <rusty> update_fee still allows you to adjust to slow changes, however, if they were to occur.  For example, slowly rising fees.  It is not completely useless.
20:03:25 <ariard> Just to avoid the burden of change commitment transaction format again in six-months, a year to drop update_fee
20:03:26 <roasbeef> ariard: so that's maybe bitcoin 21 or something? imo we should just deploy things as soon as we can in order to not have dependancies on stuff getting into bitcoin or miner block selection, this is an issue today, would rather not wait years before we can improve the situation today that users/devs/companies cite as pain points
20:03:37 <roasbeef> ariard: it wouldn't need to change, we can just drop it
20:03:45 <BlueMatt> rusty: right, but we've never seen such things, in practice
20:03:55 <roasbeef> i can send you some logs ;)
20:04:16 <BlueMatt> rusty: so...I dunno, its a) incredibly hard to implement "right" (arguably no implementations have today), b) its useful for only some scenario that we may never see (and have never seen)?
20:04:17 <ariard> logs of txn being stucked in the mempool ?
20:04:28 <roasbeef> logs of commitments being updated to slow fee rises
20:04:28 <BlueMatt> I dont think rbf is required to get rid of it
20:04:40 <cdecker> Let's just minimize the size of the changes we do in one go, otherwise we're compounding the chances to introduce errors
20:04:43 <roasbeef> y'all are proposing something completely independent to the anchor changes
20:04:58 <BlueMatt> roasbeef: maybe your fee predictor assumes slowly rising fees, but...uhhh, getting into the mempool doesnt require those?
20:04:59 <roasbeef> if you have a mechanims to handle fes better on commitments and also coop closing, then please propose that independently
20:05:11 <BlueMatt> cdecker: I wouldnt call it "canges" more like "get rid of useless shit"
20:05:37 <BlueMatt> like, if we're gonna clean it up, lets clean it up
20:05:41 <cdecker> Well, it's still a change from the currently implemented logic, so let's not rush those out all at once
20:05:51 <joostjgr> i think the anchor outputs are a good safety mechanism. you'll always have a handle to push your commit tx forward. without update_fee, we're stuck with the opening ceremony fee for the rest of the channel life
20:06:02 <BlueMatt> I dont think its practically doable, today, for an automated program to make any better fee predictions on what is gonna get into the mempool next week than I can, just sitting here.
20:06:09 <cdecker> Otherwise I'll start advocating for bundling sighash_noinput with taproot again xD
20:06:22 <BlueMatt> cdecker: ehh, they're highly related
20:06:28 <roasbeef> anchor as is makes a pretty significant step for safety in the network, let's not delay things more than we need to, a bigger fee overhaul is an independent change
20:06:38 <BlueMatt> update_fee, as horribly broken as it is today, is all that exists, with anchor outputs we have a strictly better solution
20:06:44 <BlueMatt> with rbf its *even better*, but thats kinda separate
20:06:52 <roasbeef> in any case, it's a link level change, so it can be rolled out at will, since it doesn't require a synchronized internal network update
20:07:10 <BlueMatt> roasbeef: anchor outputs *are* the "big fee overhaul"
20:07:15 <roasbeef> not really
20:07:20 <BlueMatt> I dont see why that should also include removing cruft related to the old fee model.
20:07:24 <roasbeef> it's just allowing you to bump fees, when you can't right now
20:07:40 <BlueMatt> right, and allowing you to bump fees is the thing that you need to get rid of the old cruft
20:07:58 <BlueMatt> its not like update_fee actually, well, allows you to reliably broadcast
20:08:06 <BlueMatt> anchor outputs make progress
20:08:20 <roasbeef> works pretty well in practice today, anchor makes things better, let
20:08:24 <roasbeef> let's keep making forward progress
20:08:26 <BlueMatt> it works cause fees are 0 today
20:08:30 <BlueMatt> thats a completely bogus argument
20:08:37 <roasbeef> even when they haven't been
20:08:42 <BlueMatt> yes, makes things better, so remove the useless ccruft :p
20:09:18 <joostjgr> besides this point, symmetric csv ok? and anchor script locked to funding key with csv locked cleanup path?
20:09:22 <lndbot> <johanth> I think we all agree update_fee is not ideal, but we can't just remove it today
20:09:30 <BlueMatt> lndbot: why not?
20:09:32 <rusty> joostjgr: yes, I like symmetry.
20:09:40 <roasbeef> ok, if y'all have a complete proposal for how to remove update_fee and also revamp the coop close logic, then please propose it on the mailing list, I havent' seen any such proposal, and see no reason why it should block improving the current state of the network
20:09:49 <ariard> roasbfee: works pretty well, but is there any adversarial peer stopping to sign bumped commitment txn in case of fees spikes?
20:10:09 <BlueMatt> "works pretty well" == a broken turst model :(
20:10:11 <roasbeef> ariard: if they don't sign, we have the past commitment so can anchor things down
20:10:12 <BlueMatt> come on...
20:10:18 <roasbeef> if they won't sign state updates, then it's a useless channel
20:10:27 <BlueMatt> errr, trust.
20:10:27 <lndbot> <johanth> How do you determine the commit tx fee without?
20:10:30 <ariard> roasbeef: assuming the past commitment can get in the mempool
20:10:50 <BlueMatt> lndbot: fix it? you dont actually have to go very high to get into the mempool even at its absolute peak.
20:11:01 <BlueMatt> you can be orders of magnitude below the next block fee to get into the mempool
20:11:04 <roasbeef> ariard: yes that's a base assumption, packged relay can relax that assumption eventualy, packaged relay doesn't exist
20:11:06 <BlueMatt> which approxamates rbf
20:11:20 <BlueMatt> so you seriously dont need to assume rbf for it to be useful to kill update_fee
20:12:08 <BlueMatt> lndbot: you could realistically use like 5sat/vbyte or something....nice round number, dont have to worry about it.
20:12:15 <cdecker> Sorry, notebook froze
20:12:23 <cdecker> joostjgr: +1 for symmetric fees
20:12:42 <joostjgr> i am not sure how we're doing time wise, but we'd welcome some review/comments from the eclair and cl teams on the pr as well
20:12:46 <roasbeef> symmetric fees?
20:12:54 <roasbeef> main meeting is prety much over at this point
20:12:57 <joostjgr> symmetric csv
20:13:01 <cdecker> Ah sorry, symmetric delays
20:13:02 <ariard> joostjgr: what's about the delay for csv, 10 blocks?
20:13:14 <joostjgr> yes, i think it can be a lot longer too
20:13:28 <joostjgr> give the channel parties some time to do their thing with the anchor
20:13:34 <ariard> agree on this, would let you aggregate sweeping
20:13:37 <BlueMatt> yea, I'm kinda curious what other folks think the utility of update_fee is? rusty or cdecker?
20:13:37 <joostjgr> the sweepers are patient i think?
20:14:07 <ariard> joostjgr: sweepers can scan blockchain once a month, for utxo pollution IMO that's ok
20:14:40 <BlueMatt> maybe I'm missing something....why 10 blocks? the anchor only matters for next-block (ie csv 1)
20:15:01 <joostjgr> ok, change to 4096 blocks?
20:15:10 <joostjgr> this is for anyone can spend
20:15:21 <roasbeef> this is the trap door for the rest of the world
20:15:23 <BlueMatt> right, once you have 1 conf, the anchor output has done its job
20:15:23 <joostjgr> if it is economical for a sweeper, it may also be for the channel party
20:15:27 <niftynei> my understanding of anchors is that if they're unused (to anchor a tx) then they're anyone can spend?
20:15:36 <BlueMatt> (unless we're assuming they have enough value that the actual owners want the funds)
20:15:38 <cdecker> BlueMatt: like I mentioned above, I don't like bundling changes, and removing update_fee is more than necessary
20:15:48 <ariard> yes anyone can spend if channel party doesn't act
20:16:01 <rusty> BlueMatt: I hate update_fee, and long to see the day when it's banished forever.  But if other implementers feel they still want it, I can wait.
20:16:04 <BlueMatt> cdecker: so....add a separate feature bit for it and merge it in 2 weeks? :p
20:16:16 <ariard> joostjgr: yes seems good to me, would be a magic number anyways
20:16:35 <joostjgr> wondering if that sweeper business will make me rich
20:16:39 <niftynei> the question seems to be are they 'anyone can spend immediately' or 'anyone can spend after a timedelay allowing the originating parties to claim it'
20:17:05 <joostjgr> niftynei: yes, the proposal is now anyone can spend after x blocks. and discussing x
20:17:10 <lndbot> <johanth> sgtm adding a longer delay
20:17:19 <niftynei> i don't grok the rationale for a delay
20:17:34 <joostjgr> if it is economical for a sweeper, it may also be for the channel party
20:17:38 <ariard> joostjgr: nop but youo would act for the sake of the blockchain :p
20:17:49 <BlueMatt> I guess I dont really care. If you think the value is enough that you want the original owners to claim the funds, ok, but hopefully its low enough that we dont care so its not worth discussing :)
20:17:51 <joostjgr> so channel party gets the first exclusive option to sweep
20:18:01 <niftynei> but .. .why?
20:18:45 * niftynei is clearly not someone you want managing your petty cash drawer
20:18:48 <joostjgr> is it always a noop? channel parties proposed their dust limit, which is the anchor value
20:19:29 <BlueMatt> I mean the channel parties get the first exclusive option to sweet no matter what cause its > 0
20:19:45 <joostjgr> in the case that they are offline when the commit tx confirms
20:19:47 <bitconner> given that channel parties need to provide a signature while sweepers don't, i'd be interested in the exact threshold where it is profitable to claim or not
20:19:48 <lndbot> <johanth> They might be offline
20:19:51 <BlueMatt> (and, hopefully, the value is low enough that it has ~0 value)
20:19:59 <BlueMatt> at least once you consider the next tx fee
20:20:35 <bitconner> perhaps deriving that threshold can inform whether or not counterparties are even likely to claim them
20:20:40 <niftynei> my understanding of anchors is that they're intentionally non-economic; introducing additional latency assumes some economic-ness to them
20:20:49 <rusty> BlueMatt: I hope not, or it'll spam forever
20:20:57 <roasbeef> it's mostly conjecture really, the amount will be de minimis
20:21:11 <BlueMatt> rusty: ok, well only marginal value, sameish point applies
20:21:44 <rusty> I want them economic, otherwise we're spamming the blockchain because they won't be spent.  It's an important distinction, let's not foul our own nest.
20:22:07 <BlueMatt> I kinda assumed they may have value at fee of 1-5 sat/vbyte, but 0 value above that...for that purpose you'll neverish claim next-block (assuming bitcoin is functional)
20:22:18 <lndbot> <johanth> they might be economic, they might not be. You don't know, since you don't know when it Will be broadcast
20:22:21 <BlueMatt> so csv 1 == csv 1024
20:22:25 <joostjgr> in the current version of the pr, parties pick their anchor size during opening
20:22:30 <BlueMatt> wut
20:22:32 <BlueMatt> please no
20:22:37 <niftynei> adding an additional delay feels like an unnecessary complication imo, for unclear benefit
20:22:54 <rusty> BlueMatt: I've been arguing to just pick a value, too.  Since there's no good number, KISS.
20:23:27 <roasbeef> constants should really be avoided at all costs imo, which lends to parties picking their own values
20:23:29 <niftynei> CSV 1 is easy to reason about, and semi-self descriptive in that the rationale for it is built into its value
20:23:31 <BlueMatt> thats just another update_fee - you're now trying to decide what the minimum economic value is when they close the channel at the time they open the channel
20:23:39 <BlueMatt> picking it is absolutely impossible, just hardcode it
20:23:58 <BlueMatt> roasbeef: only if its actually *possible* to make an informed decision at runtime, which you cannot.
20:24:29 <niftynei> '1' has semantic meaning in this case; '1024' is meaningless
20:24:38 <roasbeef> BlueMatt: why can't you? based it off of the current widely recognized dust threshold (which can even change in node's mempools in high water scenarios)
20:24:55 <roasbeef> otherwise what value would you pick that you can be sure won't cuase any issues in the future w.r.t output redemption?
20:25:05 <BlueMatt> roasbeef: then just hardcode it?
20:25:12 <BlueMatt> cause that number ~doesn't change.
20:25:22 <roasbeef> this is about parties picking their value at the start
20:25:23 <BlueMatt> also, the dust threshold has not changed in about 5 years
20:25:33 <BlueMatt> the mempool watermark does *not* change the dust threshold
20:25:43 <BlueMatt> for this very reason
20:26:01 <roasbeef> i'd have to check again, but last I did, it created a new floor
20:26:04 <ariard> does it mean now if we update dust threshold we want to be sure to not break LN commitment txn ?
20:26:13 <BlueMatt> it creates a fee floor - not a dust value floor
20:26:17 <roasbeef> in any case, deciding on a csontant seems hard, so just let the nodes pick one, in the future we may converge in a single value
20:26:32 <BlueMatt> deciding a constant is strictly easier than writing code to dynamically pick one
20:26:38 <BlueMatt> by, like, two orders of magnitude
20:26:38 <roasbeef> ariard: parties pick their dust threshold at the start as is, but it can't be updated once the channel is open
20:26:54 <BlueMatt> that threshold has a massively different meaning
20:26:56 <ariard> roasbeef: know that, was speaking more on the core side
20:26:56 <roasbeef> BlueMatt: lol us talking about this right now shows it isn't very easy to arrive at a constant
20:27:08 <roasbeef> i mean, just look at bitcoin in 2017 or so
20:27:24 <BlueMatt> roasbeef: we aren't debating what the value is? I think any one of us can calculate a value and we'd all be within 5x of each other right now.
20:27:31 <BlueMatt> roasbeef: that *does not change* the dust value
20:27:34 <roasbeef> ariard: last change was actually it being lowered kinda, due to segwit
20:27:38 <BlueMatt> bitcoin *today* and bitcoin 2017 had the same dust value
20:27:56 <roasbeef> lol that was a ref in the difficulty of picking constants
20:28:28 <ariard> roasbeef: so it means if core increase dust_fee in the future it may render some LN commitment txn unbroadcastable ?
20:28:33 <BlueMatt> "just make it dynaic" is not a solution for issues like this, and its kinda depressing to see it suggested
20:28:38 <BlueMatt> dynamic
20:28:45 <roasbeef> ariard: as is yes that's the case, but they can ofc still be included in a block
20:29:18 <roasbeef> we're not saying make it dynamic, we're saying both parties choose their values at the start, just as we do for every other paramter for channel funding
20:29:51 <roasbeef> but in anycase, g2g now
20:30:19 <BlueMatt> sorry, phrasing, "pick it at the open" is not a solution for something you cannot pick dynamically
20:30:19 <joostjgr> this value is already picked to decide whether htlcs should materialize on the commit tx. we are reusing this for the anchor, no new field is added. there is no change at all to the funding msgs in the pr as is
20:30:23 <cdecker> How is that not directly contradicting with joostjgr's desire to reduce the test matrix? Let's start with a fixed value and introduce negotiation once we see the need for it, and not otherwise
20:30:28 <BlueMatt> joostjgr: nope, thats a very different limit!
20:30:51 <roasbeef> cdecker: it's easy to have it float, them impls agree to a value vs caping it then adding an ability to allow it to float
20:30:55 <BlueMatt> joostjgr: thats a economic limit that you expect to be economic at the time you broadcast +/-
20:31:06 <BlueMatt> this limit is a limit that you expect to be economical at some point over the next 6-12 months
20:31:11 <BlueMatt> which is massively different
20:31:29 <niftynei> what's the fear with choosing a constant? that the bitcoin spec will move against it?
20:31:42 <BlueMatt> niftynei: bitcoin hasnt chaned it in many years, because of issues like this :p
20:32:03 <BlueMatt> and I cant imagine it chaning (at least in the upwards direction) without lots of timelag cause people will point out it breaks *lots* of software
20:32:06 <BlueMatt> lightning is not at all uniqe here
20:32:18 <niftynei> right, i'm just trying to understand what the context is around fixed values
20:32:20 <lndbot> <johanth> How do you know the constant will be economical in the next 6-12 montsh?
20:32:32 <cdecker> roasbeef: no, if we allow it to float we need to be able to handle it when our counterparty choses to use another value. If our response is to just slam the door in their face we've just created a netsplit...
20:32:54 <BlueMatt> lndbot: assume at some point you can claim something with 5sat/vbyte, and move on with your life :)
20:33:19 <lndbot> <johanth> That might not be true
20:33:27 <cdecker> Negotiations are a necessary evil some times (*cough*update_fee*cough*) but should be avoided imho if there isn't a really good reason for them
20:33:37 <BlueMatt> well you cant predict it any better at runtime in software for a channel you'll close in 12 months anyway :p
20:33:38 <niftynei> would making it variable as to the bitcoin standard be reasonable?
20:33:44 <lndbot> <johanth> And if the fee level stays there, then we would need to change the constant
20:33:54 <BlueMatt> sure, it may not be true, but if you cannot possibly predict it better in software, why are we debating this?!
20:34:42 <lndbot> <johanth> My software can predict it better in 12 months then I can do now
20:34:48 <niftynei> at least in terms of how the spec is written? it seems like if we're worried what's economic will change, and the economicness is determined by the bitcoin standard, then we could just pin it to the bitcoin standard in spec and call it done
20:35:04 <cdecker> Anyway, got to go, and I don't see us agreeing on this today :-)
20:35:09 <cdecker> See you guys next time ^^
20:35:16 <bitconner> bye cdecker!
20:35:18 <niftynei> tchau cdecker!
20:35:23 <BlueMatt> niftynei: sure, but that == hardcoding it :)
20:35:23 <BlueMatt> cdecker: fwiw, I'm not suggesting that update_fee isnt required in *today's* lightning, I agree its a neccessary evil today, just that I dont think it will be soon :p
20:35:52 <BlueMatt> lndbot: wut? I promise you this is not the case :)
20:36:01 <lndbot> <johanth> hehe
20:36:06 <BlueMatt> see y'all
20:36:08 <lndbot> <johanth> Have you seen my code lol
20:36:38 <BlueMatt> well, I can predict best: my prediction is 1sat/vbyte will at some point in the next 12 months be mined :)
20:36:40 <BlueMatt> perfect!
20:37:16 <joostjgr> thanks for the input here. please keep commenting on the pr
20:37:35 <bitconner> say goodbye to your htlcs lol
20:37:42 <ariard> anyway if any lightning dev wants to concept review package relays it's here : https://github.com/bitcoin/bitcoin/pull/16401
20:37:44 <joostjgr> btw, any other teams actively implementing any of this?
20:37:52 <joostjgr> we are
20:38:05 <bitconner> having a fixed threshold where the whole network becomes crippled seems less than desirable
20:38:12 <BlueMatt> we'd like to, but we still mostly dont feel like implementing update_fee cause its so broken (and doubly hard to get right if you arent writing your own fee estimator, which we are not)
20:38:30 <BlueMatt> bitconner: huh? no one is proposing a fixed dust threshold for htlcs
20:38:41 <BlueMatt> bitconner: this is for the anchor outputs, which, as described above, is a very different type of dust
20:39:05 <bitconner> what is the worst case outcome if that value is too low?
20:39:12 <BlueMatt> they sit in the utxo set forever
20:39:39 <BlueMatt> and the utxo set has more uneconomical crap in it (it already has lots, sadly, but not exactly world-ending)
20:39:51 <bitconner> got it, was thinking this was about commitment fee rate
20:40:02 <BlueMatt> nah, thats the update_fee discussion :p
20:41:23 <bitconner> heh, we have a ways to go before ln creates as many unspendables as coinbase lol
20:41:41 <lndbot> <johanth> Bye all!
20:41:46 <bitconner> adios!
20:42:20 <joostjgr> see you all
20:42:35 <bitconner> #endmeeting