20:12:45 #startmeeting 20:12:45 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:13:09 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 What do you think of only doing long-term stuff tonight? 20:13:46 Unless you have PRs you want to have people look at 20:14:22 there's #764, but the text portion there is pretty small, can prob be mostly hashed out on the PR 20:14:35 main thing there is finding some wording that isn't langauge specific 20:14:53 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 #topic https://github.com/lightningnetwork/lightning-rfc/pull/764/ 20:15:06 #link https://github.com/lightningnetwork/lightning-rfc/pull/764/ 20:15:40 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 It's worded as empty vector 20:16:08 roasbeef: you're a go developer, aren't you? nil vs empty? :) 20:16:32 ok so this is what ariard suggests in this PR 20:16:53 it's true that `0` is misleading 20:16:58 t-bast: there is not BIP for this, it's a standard policy 20:17:01 https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki 20:17:09 op_push(0)? 20:17:11 well many of the BIPs are also very language specific (C++) 20:17:29 right, empty vector in PR wording 20:17:46 this is in BIP 141 20:19:02 roasbeef: right it's in BIP 141 but as standard policies? 20:19:20 I mean rn it's not exported by bitcoinconsensus like other consensus flags 20:19:40 dunno what the lib exports, but yeh it's relay policy 20:19:53 just meant that it's mentioned there at least 20:20:31 yeah it's not switched on in GetBlockScriptFlags 20:20:53 okay so what's wording have people favor ? will update in consequence 20:21:21 why not call it an empty witness field ? 20:21:23 * cdecker abstains 20:21:46 it matches the BIP and is very specific 20:22:06 sstone: like `` or ``? 20:22:09 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 element is fine too 20:22:26 im not sure i grok what exactly 'empty vector' is in this context.. len-zero witness? 20:22:31 ` `? 20:22:40 niftynei: bytes(0) in Python 20:23:31 niftynei: OP_0 : an empty array of bytes is pushed onto the stack 20:23:46 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 the lowest level description may be the best here 20:24:18 ok so len-zero data stack element 20:24:19 witness may be quite confusing as per-BIP141 it has a definition 20:24:57 ? 20:25:01 which would just be the len of the empty stack, which is OP_ZERO? 20:25:15 s/stack/data-element// 20:25:55 mebbe it's me but i find 'len-zero' a lot more descriptive than 'empty' 20:26:23 why not keep the <> notation and explain at the beginning that it represent an empty witness element/field ? 20:26:37 sstone: not a bad idea, then there's more room to elaborate 20:26:49 and a footnode linking back to jl2012 PR and mail? 20:27:01 agree, `<>` is concise and as long as there's a place where it's explained it's all good 20:27:55 wait why can't we just say OP_ZERO? 20:28:22 sstone: where do you see to explain symbol notation ? beginning of BOLT3? 20:28:57 seems like that's the most explicit correct way to explain what's required by MINIMALIF? 20:29:06 maybe we can take this to the PR? 20:29:08 we already explain somewhere that the 'script' element is omitted for brevity, it could be added there 20:29:29 (when we spend p2wsh outputs) 20:29:42 okay in Use of Segwit I see, sgtm 20:30:29 Let's settle on <> in witness dscription and explaining notation in Use of Segwit + footnote to explaining MINIMALIF 20:30:33 and keep discussion for PR 20:30:38 ariard: sgtm 20:32:07 #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 Any other PRs we want to look at or shall we jump to more long term things? 20:33:03 there's anchors, which I don't consider long-term (at least from teh PoV of lnd ;) ) 20:34:18 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 heh let's start with anchor outputs then 20:34:27 #topic Anchor Outputs 20:34:43 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 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 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 Is BlueMatt around? He mentioned rust-lightning would soon have time to look at it last time. 20:36:44 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 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 t-bast: we're still working on this, implem is WIP 20:37:10 but 2)'s not really an issue until update_fee is removed so can be disregarded 20:37:24 niftynei: did you see my email to the list about that stuff? 20:37:25 ariard: great, that should provide good feedback 20:38:10 by 'that stuff' are you referring to expense or to_remote? 20:38:16 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 niftynei: yeh 20:38:27 fwiw, should clarify that lnd master implements the current proposal under feature bits 1336/1337 20:38:41 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 niftynei: ok, wanna reply to it then to point out the gaps there in the arguments it presented? 20:39:54 yes definitely! 20:40:03 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 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 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 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 tx-relay protcol have some timers at relay for privacy reasons 20:42:19 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 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 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 ariard: signalling is just a non final sequence, which is how they are or they inherit from the parent transaction 20:44:13 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 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 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 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 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 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 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 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 Progress in what sense? Drop the "2 implementation" requirement? 20:50:01 cdecker: the operative question...! 20:50:13 I understood it as: keep the PR open while others implement 20:50:34 Ah ok 20:50:37 It needs at least a second implementation in production to be fully interop tested, right? 20:50:38 do CL or eclair commit to having this be a prio for their next releases? 20:50:48 No 20:50:59 * roasbeef looks over at the other side of the IRC room.... 20:51:02 For eclair we can't commit on that right now either 20:51:03 roasbeef: we're spec compliant on 1.0 and we have tested against every other implem on testnet 20:51:10 ok, I expected as much 20:51:27 I mean we won't commit to a major change to c-lightning that'd require shelving everything else for it 20:51:35 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 mhmm, totally reasonable 20:52:14 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 agreed, but it's the same for trampoline on our side ;) 20:52:41 heheh yeh :p, prios prios prios 20:52:53 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 and do that iteratively at every bump fron the LN node 20:53:04 I'm just happy we're no longer discussing the realm byte reuse on the TLV proposal xD 20:53:11 kek 20:53:14 cdecker: xD 20:53:19 hahaha 20:54:37 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 fsho, yeh we also took some time to do some gardening along the way 20:55:01 But rest assured that we're moving in that direction 20:55:26 As frustrating as it is, a slow moving spec is a good thing, allowing us to extensively inspect and analyse 20:55:39 (and ensure compatibility...) 20:55:48 should we move on to the next agenda item? 20:56:05 Yep, let's move on. How about we talk about Trampoline now? 20:56:32 +1 for trampolines (though I have to leave in a couple of mins) 20:56:39 It would love some feedback to move towards a solution everything likes 20:56:56 I can at least give a quick summary, things to look at, etc 20:57:02 5 minutes top ;) 20:57:05 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 wait should we tag the topic change? 20:57:18 so I really dont think is fair to jump on it now 20:57:26 #topic Trampoline 20:57:28 anyway, I also think there are outstanding comments on the PR 20:57:33 (sorry, got dc'd) 20:57:39 * cdecker boing boing boing :-) 20:57:39 ty t-bast :) 20:57:42 #link https://github.com/lightningnetwork/lightning-rfc/pull/654 20:58:01 Allright as discussed last time, I spent some time splitting the trampoline PR 20:58:21 I made it into two documents; the first one in the "proposals" folder is what you should start with 20:58:41 It gives a higher level design overview, and lists many open questions and early proposals 20:58:50 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 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 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 Even simply pointing out things that feel unclear will be helpful to make the review process smoother. 21:01:04 By the way, your diagrams look amazing if you pass them through ditaa :-) 21:01:08 I marked many earlier comments as resolved to avoid having too much to read for newcomers 21:01:44 I didn't know ditaa, this will make my life a lof better xD 21:02:24 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 Definitely, I still have my desk full of scribbles for the RV proposal :-) 21:05:45 @BlueMatt note that trampoline works nicely with either blinded paths or rendezvous (I believe I mention it in the PR now) 21:08:41 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 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 t-bast: nice! I'm happy on the progress, but, sadly I'm not 110% up on the latest state :( 21:10:28 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 BlueMatt: no worries, just to let you know when you have some time available to review 21:11:34 roasbeef, wdym by 'shallow extrapolation' 21:12:03 roasbeef: are you using a mobile wallet on something else than wifi? 21:12:18 roasbeef: and without using it every 6 hours? 21:12:20 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 t-bast: do you have active mainnet or testnet trampoline nodes? 21:13:56 ThomasV: yes, on testnet it's the "endurance" node and on mainnet the "acinq" node 21:14:36 nice. I'll try to play with it in the coming weeks 21:15:33 ThomasV: testnet is 03933884aaf1d6b108397e5efe5c86bcf2d8ca8d2f700eda99db9214fc2712b134@13.248.222.197:9735 21:16:35 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 I will :) 21:17:29 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 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 idk....there's a lot of design space that has yet to be explored 21:18:49 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 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 but ofc y'all are fee to explore this route given eclair is primarily used with a primary "gateway" node 21:19:34 yeh ofc ofc 21:19:45 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 Anyway need to get going, see you all around (hopefully in RL sometime as well) ^^ 21:20:07 yeh don't sync 50k of them, maybe 10% of them even matter 21:20:13 See you cdecker! 21:20:22 roasbeef: but then your payment fails very often 21:20:50 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 depends...do you forget all past history after the payment attempt, are tehre additional hueristics which can be used? etc, etc 21:21:18 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 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 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 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 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 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 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 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 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 roasbeef: if you look at the proposal, you may be surprised, there has been changes since the ML discussions 21:26:27 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 ways of improving graph sync and/or shrinking the graph 21:26:47 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 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 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 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 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 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 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 roasbeef: the issue is that many things can go wrong in estimating what "you'll likely need to traverse" :) 21:31:05 roasbeef: what would bea good pruning strategy? 21:31:20 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 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 #endmeeting