20:12:45 <t-bast> #startmeeting
20:12:45 <lightningbot> Meeting started Mon Apr 13 20:12:45 2020 UTC.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:12:45 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:13:09 <t-bast> Luckily we've been able to merge quite a few PRs recently, so I think this is a good opportunity to discuss long term stuff
20:13:33 <t-bast> What do you think of only doing long-term stuff tonight?
20:13:46 <t-bast> Unless you have PRs you want to have people look at
20:14:22 <roasbeef> there's #764, but the text portion there is pretty small, can prob be mostly hashed out on the PR
20:14:35 <roasbeef> main thing there is finding some wording that isn't langauge specific
20:14:53 <roasbeef> we've had this issue in the past on the lnd side, and actually you need to specify a "nil vector" rather than "an empty one"
20:15:02 <t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/764/
20:15:06 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/764/
20:15:40 <t-bast> Agreed, it's a matter of wording, how is this worded in BIPs (if there are some where this case is mentioned)?
20:16:07 <darosior> It's worded as empty vector
20:16:08 <t-bast> roasbeef: you're a go developer, aren't you? nil vs empty? :)
20:16:32 <t-bast> ok so this is what ariard suggests in this PR
20:16:53 <t-bast> it's true that `0` is misleading
20:16:58 <ariard> t-bast: there is not BIP for this, it's a standard policy
20:17:01 <darosior> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
20:17:09 <cdecker> op_push(0)?
20:17:11 <roasbeef> well many of the BIPs are also very language specific (C++)
20:17:29 <ariard> right, empty vector in PR wording
20:17:46 <roasbeef> this is in BIP 141
20:19:02 <ariard> roasbeef: right it's in BIP 141 but as standard policies?
20:19:20 <ariard> I mean rn it's not exported by bitcoinconsensus like other consensus flags
20:19:40 <roasbeef> dunno what the lib exports, but yeh it's relay policy
20:19:53 <roasbeef> just meant that it's mentioned there at least
20:20:31 <ariard> yeah it's not switched on in GetBlockScriptFlags
20:20:53 <ariard> okay so what's wording have people favor ? will update in consequence
20:21:21 <sstone> why not call it an empty witness field ?
20:21:23 * cdecker abstains
20:21:46 <sstone> it matches the BIP and is very specific
20:22:06 <t-bast> sstone: like `<empty>` or `<empty_witness>`?
20:22:09 <roasbeef> sstone: "element" is used more commonly in my experience, but idk if saying empty witness element is all more that specific depending on the context...
20:22:24 <sstone> element is fine too
20:22:26 <niftynei> im not sure i grok what exactly 'empty vector' is in this context.. len-zero witness?
20:22:31 <t-bast> `<local_delayedsig> <empty>`?
20:22:40 <darosior> niftynei: bytes(0) in Python
20:23:31 <ariard> niftynei: OP_0 : an empty array of bytes is pushed onto the stack
20:23:46 <cdecker> b'\x00' is interpreted as OP_0 which pushes a zero-length vector / bytearray on the stack, but it's also used to represent false
20:23:55 <roasbeef> the lowest level description may be the best here
20:24:18 <niftynei> ok so len-zero data stack element
20:24:19 <ariard> witness may be quite confusing as per-BIP141 it has a definition
20:24:57 <ariard> <empty_bytearray> ?
20:25:01 <niftynei> which would just be the len of the empty stack, which is OP_ZERO?
20:25:15 <niftynei> s/stack/data-element//
20:25:55 <niftynei> mebbe it's me but i find 'len-zero' a lot more descriptive than 'empty'
20:26:23 <sstone> why not keep the <> notation and explain at the beginning that it represent an empty witness element/field ?
20:26:37 <roasbeef> sstone: not a bad idea, then there's more room to elaborate
20:26:49 <ariard> <zero-len vector> and a footnode linking back to jl2012 PR and mail?
20:27:01 <t-bast> agree, `<>` is concise and as long as there's a place where it's explained it's all good
20:27:55 <niftynei> wait why can't we just say OP_ZERO?
20:28:22 <ariard> sstone: where do you see to explain symbol notation ? beginning of BOLT3?
20:28:57 <niftynei> seems like that's the most explicit correct way to explain what's required by MINIMALIF?
20:29:06 <niftynei> maybe we can take this to the PR?
20:29:08 <sstone> we already explain somewhere that the 'script' element is omitted for brevity, it could be added there
20:29:29 <sstone> (when we spend p2wsh outputs)
20:29:42 <ariard> okay in Use of Segwit I see, sgtm
20:30:29 <ariard> Let's settle on <> in witness dscription and explaining notation in Use of Segwit + footnote to explaining MINIMALIF
20:30:33 <ariard> and keep discussion for PR
20:30:38 <t-bast> ariard: sgtm
20:32:07 <t-bast> #action update to <> in witness dscription and explaining notation in Use of Segwit + footnote to explaining MINIMALIF, continue discussion on the PR
20:32:31 <t-bast> Any other PRs we want to look at or shall we jump to more long term things?
20:33:03 <roasbeef> there's anchors, which I don't consider long-term (at least from teh PoV of lnd ;) )
20:34:18 <roasbeef> impl wide on the lnd side not much has changed, ariard has a comment re someone trying to decrease the fee rate of a 2nd levle transaction, but that would require them to block broadcast of the base transaction which has a higher fee rate, so i don't think it's a major concern
20:34:20 <t-bast> heh let's start with anchor outputs then
20:34:27 <t-bast> #topic Anchor Outputs
20:34:43 <roasbeef> we'll be tagging lnd 0.10 this week, which as mentioned in my email from 2 weeks or so ago will include opt-in anchors as defined in the specification as is
20:35:09 <roasbeef> i think on the spec end, we need to update some constants, but other than that it's pretty much in-line
20:35:31 <roasbeef> so my main question now is when/if the other implementations willl start to undertake the task of implementing it top to bottom?
20:36:17 <t-bast> Is BlueMatt around? He mentioned rust-lightning would soon have time to look at it last time.
20:36:44 <ariard> roasbeef: not exactly a) you need to signal RBF on higher feerate original tx, b) it's going to be same issue than outputs without CSV_DELAY?
20:36:54 <niftynei> i'm super behind on writing up some thoughts i've had re:anchor outputs, but my general gist is that other than being 'more expensive in some cases, sort of' the only other real 2 quibbles i have with the existing proposal (not having implemented it) are 1) re-using to_remote and 2) the inclusion of uneconommical htlc outputs
20:37:08 <ariard> t-bast: we're still working on this, implem is WIP
20:37:10 <niftynei> but 2)'s not really an issue until update_fee is removed so can be disregarded
20:37:24 <roasbeef> niftynei: did you see my email to the list about that stuff?
20:37:25 <t-bast> ariard: great, that should provide good feedback
20:38:10 <niftynei> by 'that stuff' are you referring to expense or to_remote?
20:38:16 <roasbeef> ariard: iirc they already do signal opt-in, but you seem to assume that they'd race to get this into the mempool widelyu beofre ours? so they have a special hook up or are abel to censor our view of the network
20:38:20 <roasbeef> niftynei: yeh
20:38:27 <bitconner> fwiw, should clarify that lnd master implements the current proposal under feature bits 1336/1337
20:38:41 <niftynei> i did see your email and do not remember it addressing my specific concerns but i also haven't done the modeling i've been wanting to yet so haven't responded
20:39:05 <roasbeef> niftynei: ok, wanna reply to it then to point out the gaps there in the arguments it presented?
20:39:54 <niftynei> yes definitely!
20:40:03 <roasbeef> the modeling is pretty trivial, the func is just: feeRate*weight + constant, the constant in this case is the extra anchor sats (660), the fee rate scaling dominates at anything above 1 sat/byte, which commitments would be above if theyr'e actually trying to get into the chain in time to resolve contracts
20:40:41 <ariard> roasbeef: on RBF, they inherit RBF from commitment but if commitment gets confirmed in between 2nd-stage txn won't be RBF anymore? (need to verify mempool code on this)
20:41:18 <ariard> roasbeef: it's easy to win the race for an attacker, you just have to be connected to the base full-node of the LN node and don't respect tx-relay protocol
20:41:25 <roasbeef> dunno what you mean by in-between, the transaction itself woudl still signal, and the  commitmetn needs to be confirmed before the second level can be spent, so it won't take in any unconfirmed inputs
20:41:35 <ariard> tx-relay protcol have some timers at relay for privacy reasons
20:42:19 <niftynei> wrt to c-lightning implementation, which is probably more relevant it definitely won't be in the release we're cutting this week
20:42:36 <ariard> right now with anchor commitment transaction has to confirm before spending, but we don't signal RBF per-se on 2nd-stage txn ?
20:43:32 <niftynei> we should have a discussion shortly about the next release features, i'm pretty excited about the htlc tx batching that the anchors opens up and it'd be good to get that in for users
20:43:55 <roasbeef> ariard: signalling is just a non final sequence, which is how they are or they inherit from the parent transaction
20:44:13 <niftynei> it's looking like we'll probably ship some much better accounting facilities in this release which might make our users a bit more aware of chain fees in unilateral closures XD
20:44:49 <roasbeef> ok cool, I also wouldn't under estimate the size of the implementation itself, since it touches so many aspects, for example in lnd we already have a CPFP bumping engine so we were able to plug that in pretty easily
20:45:59 <roasbeef> my main qualm is that it may be sometime near the end of summer before the other implementations have somethign operational for anchors itself, so do we want to block the spec progress on that all together? deployment-wide lnd is ambivalent as we're already at teh finish line and will have a way to update our commitments in-flight in stuff cahnges
20:47:18 <ariard> roasbeef: you're right signaling is fine, but someone can still stuck in the mempool a low-feerate package, and you will have to pay more than its absolute fee to replace
20:48:34 <ariard> roasbeef: we already have dynamic bumping engine and refactored monitoring in backend, I think we can test inter-op by end of month
20:48:55 <roasbeef> ariard: which may already be the  case given you should want to get that htlc in asap, so you should already be ready to bump the fee up as you go. either the other party needs to do this (only can after a commitment confirms), or someone needs to intercept before broadcast
20:49:07 <t-bast> I think we've done quite a lot of comments without implementing it, so the state of the spec PR is what other implementations will be looking at while implementing. There will probably be new comments coming in as implementations catch up, but unless a comment really impacts the whole design we can probably make progress on the PR as it comes. WDYT?
20:49:34 <roasbeef> ok, I mean this in an amicable manner, but do we "count" RL? given that it itself isn't really "finished" nor deployed anywhere in production
20:49:41 <cdecker> Progress in what sense? Drop the "2 implementation" requirement?
20:50:01 <roasbeef> cdecker: the operative question...!
20:50:13 <t-bast> I understood it as: keep the PR open while others implement
20:50:34 <cdecker> Ah ok
20:50:37 <t-bast> It needs at least a second implementation in production to be fully interop tested, right?
20:50:38 <roasbeef> do CL or eclair commit to having this be a prio for their next releases?
20:50:48 <cdecker> No
20:50:59 * roasbeef looks over at the other side of the IRC room....
20:51:02 <t-bast> For eclair we can't commit on that right now either
20:51:03 <ariard> roasbeef: we're spec compliant on 1.0 and we have tested against every other implem on testnet
20:51:10 <roasbeef> ok, I expected as much
20:51:27 <cdecker> I mean we won't commit to a major change to c-lightning that'd require shelving everything else for it
20:51:35 <t-bast> It's on our todo-list but I can't really commit on when exactly we'll be able to start implementing...
20:51:41 <roasbeef> mhmm, totally reasonable
20:52:14 <roasbeef> on our end, it was a big thing we were working on over the past quarter or two, so understand that y'all would need to shift things around
20:52:29 <t-bast> agreed, but it's the same for trampoline on our side ;)
20:52:41 <roasbeef> heheh yeh :p, prios prios prios
20:52:53 <ariard> roasbeef: threat model is someone being connected to your full-node, not eclisping you, it's easy to intercept announced txn, add a low-feerate branch
20:53:02 <ariard> and do that iteratively at every bump fron the LN node
20:53:04 <cdecker> I'm just happy we're no longer discussing the realm byte reuse on the TLV proposal xD
20:53:11 <roasbeef> kek
20:53:14 <t-bast> cdecker: xD
20:53:19 <niftynei> hahaha
20:54:37 <t-bast> We have some work to do on our tx handling in eclair and phoenix as preliminary before anchor outputs, so it will take us some time. We're working towards it, but well...limited time!
20:54:58 <roasbeef> fsho, yeh we also took some time to do some gardening along the way
20:55:01 <t-bast> But rest assured that we're moving in that direction
20:55:26 <cdecker> As frustrating as it is, a slow moving spec is a good thing, allowing us to extensively inspect and analyse
20:55:39 <cdecker> (and ensure compatibility...)
20:55:48 <niftynei> should we move on to the next agenda item?
20:56:05 <t-bast> Yep, let's move on. How about we talk about Trampoline now?
20:56:32 <cdecker> +1 for trampolines (though I have to leave in a couple of mins)
20:56:39 <t-bast> It would love some feedback to move towards a solution everything likes
20:56:56 <t-bast> I can at least give a quick summary, things to look at, etc
20:57:02 <t-bast> 5 minutes top ;)
20:57:05 <cdecker> Yes, please
20:57:05 * BlueMatt notes that roasbeef et al explicitly maintained that anchor and other predecessors wasnt a priority for the last year or two
20:57:16 <niftynei> wait should we tag the topic change?
20:57:18 <BlueMatt> so I really dont think is fair to jump on it now
20:57:26 <t-bast> #topic Trampoline
20:57:28 <BlueMatt> anyway, I also think there are outstanding comments on the PR
20:57:33 <BlueMatt> (sorry, got dc'd)
20:57:39 * cdecker boing boing boing :-)
20:57:39 <niftynei> ty t-bast :)
20:57:42 <t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/654
20:58:01 <t-bast> Allright as discussed last time, I spent some time splitting the trampoline PR
20:58:21 <t-bast> I made it into two documents; the first one in the "proposals" folder is what you should start with
20:58:41 <t-bast> It gives a higher level design overview, and lists many open questions and early proposals
20:58:50 <roasbeef> BlueMatt: we've been working on it for over 6 months...and before then it was blocked on the carve out stuff
20:59:10 <t-bast> Then trampoline-wip.md contains something that's more in "spec format" if you want to look at the details or prefer reading that.
20:59:59 <t-bast> I think reading the high level proposal shouldn't take too much time, if some of you can please spend a bit of time on that and leave comments that would be helpful to get the discussion going.
21:00:19 <t-bast> Even simply pointing out things that feel unclear will be helpful to make the review process smoother.
21:01:04 <cdecker> By the way, your diagrams look amazing if you pass them through ditaa :-)
21:01:08 <t-bast> I marked many earlier comments as resolved to avoid having too much to read for newcomers
21:01:44 <t-bast> I didn't know ditaa, this will make my life a lof better xD
21:02:24 <t-bast> I don't know about you but for onion things and packets, I feel it's much easier to understand something very visual like those diagrams
21:04:01 <cdecker> Definitely, I still have my desk full of scribbles for the RV proposal :-)
21:05:45 <t-bast> @BlueMatt note that trampoline works nicely with either blinded paths or rendezvous (I believe I mention it in the PR now)
21:08:41 <t-bast> On the implementation side, we've implemented a one-hop trampoline; this allowed us to validate the onion construction and play with MPP for Phoenix
21:09:16 <t-bast> The multi-hop trampoline has many sections where we have multiple options, so it will be interesting to start the discussion (gossip, filters, etc)
21:09:26 <BlueMatt> t-bast: nice! I'm happy on the progress, but, sadly I'm not 110% up on the latest state :(
21:10:28 <roasbeef> motivation for trampoline in general is still lacking from my PoV based on where things are w/ the network even with shallow extrapolation
21:10:38 <t-bast> BlueMatt: no worries, just to let you know when you have some time available to review
21:11:34 <niftynei> roasbeef, wdym by 'shallow extrapolation'
21:12:03 <t-bast> roasbeef: are you using a mobile wallet on something else than wifi?
21:12:18 <t-bast> roasbeef: and without using it every 6 hours?
21:12:20 <cdecker> I'd love to get a sample implementation done as a plugin, hopefully I can find some time to work on it and give feedback
21:13:19 <ThomasV> t-bast: do you have active mainnet or testnet trampoline nodes?
21:13:56 <t-bast> ThomasV: yes, on testnet it's the "endurance" node and on mainnet the "acinq" node
21:14:36 <ThomasV> nice. I'll try to play with it in the coming weeks
21:15:33 <t-bast> ThomasV: testnet is 03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134@13.248.222.197:9735
21:16:35 <t-bast> ThomasV: it may need a specific feature bit in the invoice, don't hesitate to get in touch in private for help on making it work with your client code
21:17:01 <ThomasV> I will :)
21:17:29 <t-bast> roasbeef: honestly it's quite impossible to have a decent UX on mobile wallets without trampoline unless you're paying nodes you're directly connected to
21:18:00 <roasbeef> niftynei: I mean like extrapolating some level of consistent growth in the number of open channels (imo we'll start to see it drop a bit as peopel start to manage their channels better), seems to early to jump to something like this which just concentrates paths even more (adding to the privacy short comings we already have)
21:18:13 <roasbeef> idk....there's a lot of design space that has yet to be explored
21:18:49 <roasbeef> re the 6hr thing, background syncing is possible, and the paths of an avg user are likely pretty concentrated, so you don't need to sync every random channel update
21:19:09 <cdecker> Well, let's explore then, using the lack of research to shoot down a viable proposal seems weird... especially when it tackles an issue that one of us is already facing today
21:19:22 <roasbeef> but ofc y'all are fee to explore this route given eclair is primarily used with a primary "gateway" node
21:19:34 <roasbeef> yeh ofc ofc
21:19:45 <t-bast> background syncing on iOS is pretty much unusable, and even on android if (like me and many others) you're frequently in battery saving explicitly to disable background jobs, you have 50k channel_updates to sync every time you launch the app...
21:20:05 <cdecker> Anyway need to get going, see you all around (hopefully in RL sometime as well) ^^
21:20:07 <roasbeef> yeh don't sync 50k of them, maybe 10% of them even matter
21:20:13 <t-bast> See you cdecker!
21:20:22 <t-bast> roasbeef: but then your payment fails very often
21:20:50 <t-bast> this is a horrible UX honestly, that just fuels opponents of lightning saying: look it never works, it has to retry 7 times before a payment goes through
21:20:52 <roasbeef> depends...do you forget all past history after the payment attempt, are tehre additional hueristics which can be used? etc, etc
21:21:18 <roasbeef> yeh we can solve all that by just using 3 nodes as well (not saying this srsly, just this is the other extreme)
21:21:42 <t-bast> I agree that there's design space to explore, but I think reviewing our proposal and pointing out what you don't like is a good first step, this way we can step-by-step do more research and converge towards something everything is comfortable with
21:21:45 <roasbeef> also don't ignore the critical component of ppl actually manging their nodes properly, path finding can just route aruond those that set and forget
21:22:56 <roasbeef> i don't think we ultimatley  need something that everyone will adopt, we already have so mcuh hooks in the protocol as is for side routing protocols like these to emerge which is a great thing, I don't see everything using the base set of what we have years from now, as you may want to make certain tradeoffs to further optimize for certain use cases
21:23:41 <roasbeef> I also understand that eclair has a unique view point given it's a very popular mobile wallet and they deal directly w/ support tickets, etc
21:24:31 <niftynei> i haven't had a lot of time to look at the existing trampoline proposal but i really like the 'proposal' design you've adopted for it t-bast
21:25:33 <niftynei> imo the fact that eclair is focusing pretty pointedly on the mobile usecase is great, since ya'll definitely are surfacing issues that probably wouldn't come up otherwise
21:25:42 <roasbeef> we'll always need to straddle the boundary between the desire to have a diffuse/resllient graph and just concentrating things in order to achieve better ux (which also comes with several tradeoffs)
21:25:43 <t-bast> roasbeef: I agree, but I really think this is a problem we need to start tackling as users are clearly asking for mobile LN wallets, and even if lnd doesn't implement this your opinion on the proposal is useful to shape this to a good solution that has as few trade-offs as possible
21:26:26 <t-bast> roasbeef: if you look at the proposal, you may be surprised, there has been changes since the ML discussions
21:26:27 <bitconner> t-bast: some drive by comments after a quick skim 1) the gossip filtering could probably be it's own proposal, it's pretty unrelated to the packet format/construction, 2) the privacy arguments are still pretty weak imo, idt they should be a core argument for trampoline, 3) o/w draft looks very detailed and thorough! overall tho i still think trampoline is a little premature when there are simpler
21:26:33 <bitconner> ways of improving graph sync and/or shrinking the graph
21:26:47 <niftynei> but i'm sure i'm missing some nuance of roasbeef's points. i also sadly have to run, but it was great to talk to some ppl today :)
21:27:00 <t-bast> niftynei: thanks, I really think that this high-level proposal format is very useful for review/design discussions :)
21:27:19 * t-bast waves goodbye at niftynei
21:27:50 <roasbeef> mhmm, also don't forget that we also observe/support the mobile use case (although it isn't our primary focus rn) and have from a a distinct perspective (we don't operate a gateway node for the app users)
21:28:30 <t-bast> bitconner: thanks! Clearly I think the PR will eventually be split (I believe I do mention this in the description), I totally agree on that but wanted a first high-level view that encompasses most aspects.
21:29:07 <t-bast> bitconner: can you suggest other ways of improving graph sync? Honestly we've tried some of those and found them all lacking
21:29:55 <roasbeef> btw, i'm not trying to like shoot this down or anything, just sharing a bit of my pov which includes a foray into the mobile land and also the belief there's a lot we can gain from better node management tools for the internal network
21:30:15 <roasbeef> t-bast: i think it depepnds on if you always want the entire graph, or are willinag to prune more aggressilvey at the clients to only keep the graph that you'll likely need to traverse
21:30:48 <t-bast> roasbeef: the issue is that many things can go wrong in estimating what "you'll likely need to traverse" :)
21:31:05 <ThomasV> roasbeef: what would bea good pruning strategy?
21:31:20 <t-bast> either it ends up still requiring more syncing than is acceptable for a decent mobile UX on non 4G network, or payments fail quite often
21:32:48 <t-bast> I'll have to drop off too it's getting late here :), but thanks for your early comments roasbeef/bitconner. I'd really appreciate a summary of those on the PR to keep the discussion going (and potentially explore other ideas) and allow others to chime in
21:33:06 <t-bast> #endmeeting