Lightning Specification Meeting 2020/12/07

[t-bast]

The meeting will take place on Monday 2020/12/07 at 7pm UTC on IRC #lightning-dev. It is open to the public.

Pull Request Review

Issues

• reply_channel_range is too strict reply_channel_range is now too strict. #804 Encodings in gossip_queries #811
• export DB format Create a standardized (probably-inefficient) frozen database. #820
• 1 sat/byte for second level HTLCS in anchors++
• channel backup change: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html

Long Term Updates

• Evaluate historical min_relay_fee to improve update_fee in anchors (@rustyrussell and @TheBlueMatt)
• Upfront payments / DoS protection
• Offers Offers #798
• Blinded paths Route Blinding (Feature 24/25) #765 (@t-bast)
• Trampoline routing Trampoline Routing #654 (@t-bast)

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

• Hornet (@cfromknecht)
• lnprototest https://github.com/rustyrussell/lnprototest (@rustyrussell)

---

Post-Meeting notes:

Action items

• @t-bast to propose PR for gossip queries complete field
• @t-bast to propose PR for zlib feature bit
• @Roasbeef or @cfromknecht to draft PR for the 0 sat/byte anchor htlc txs proposal -> feature: define option_zero_htlc_tx_fee (feature 22/23) #824

[t-bast]

Pending action items from the last meeting:

- [ ] #803 small comment pending
- [ ] @ariard to investigate github security feature/page
- [ ] @ariard to write up concrete proposal [for update_fee changes] for next meeting
- [ ] Double-check the calculations in #815 then merge

[t-bast]

I added a section to discuss the proposal @LLFourn sent to the ML today: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html

[t-bast]

Meeting logs:

<t-bast> #startmeeting
<t-bast> Bot still not back xD
* joost_ (~joostjgr@81-207-149-246.fixed.kpn.net) has joined
<t-bast> I'll copy-paste my output to the github issue
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/821
<t-bast> Let's discuss gossip queries first
<bitconner> ariard: i think you have an outdated version of my key, the current expiration is 2021-09-13
<t-bast> #topic gossip queries (slightly) revisited
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/804
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/811
<bitconner> i will email to you
* joost_ has quit (Remote host closed the connection)
<ariard> bitconner: I'm talking about the security@lightning.engineering one, fingerprint: 91FE464CD75101DA6B6BAB60555C6465E5BCB3AF, as linked also in your README
<cdecker> bitconner, are you rotating or modifying the expiry? I just extended the expiry of mine last week, but was unsure what is better
<ariard> bitconner: thanks :)
<t-bast> This revisits the discussion we had about splitting blocks in multiple replies or not. We chose to *not* split, which made it easier to know when sync ended.
* joost_ (~joostjgr@81-207-149-246.fixed.kpn.net) has joined
<t-bast> But it would probably be nice(r) to allow splitting blocks, but needs an explicit signal for end of sync.
<t-bast> My personal choice would be to add an explicit bool field to say "this is the end of my gossip" and allow splitting
<bitconner> ariard: ah okay, will ping roasbeef
<t-bast> WDYT?
<bitconner> cdecker: yeah i extended mine this summer :)
<cdecker> Well, the complete flag was supposed to be something like that and we all interpreted it differently, didn't we?
<roasbeef> complete flag absically isn't used rn 
<t-bast> yes and that's a shame, TBH the complete flag as is interpreted right now is a bit useless IMO
<cdecker> Exactly, we better call it FIN this time :-)
<bitconner> i think only lnd used it as an EOF, but agree i'd like to see an explicit signal
<cdecker> At least that has a specific meaning in networking streams :-)
<roasbeef> latest version of lnd basically never interprets the value 
<bitconner> fin of file :)
<bitconner> i think we do for backcompat with our older nodes
<niftynei> 🐟
<bitconner> though there shouldn't be many of those now...
* kabaum has quit (Ping timeout: 272 seconds)
<t-bast> to be safe, we can use a new field, that's easy with tlv
<cdecker> Right
<t-bast> I can draft a spec PR to add that new field and allow splitting blocks
<roasbeef> new field for?
<t-bast> roasbeef: for FIN
<t-bast> that we would all interpret as an EOF this time :)
<bitconner> could we not just reuse the useless field?
<roasbeef> why do we need that? since you can just tell if they are done based on the block values 
<t-bast> from eclair's point of view, we can re-use complete, it's ignored right now
<t-bast> roasbeef: no you can't if you allow splitting a block in multiple replies
<bitconner> easy for us, we can just revert the changes to make it full_information
<roasbeef> for the last chunk only? 
<bitconner> that made it*
<t-bast> yes, only for the last chunk, so it could be okay, but if we can make it better for almost no cost, why not? :)
* Pavlenex has quit (Quit: Pavlenex)
<cdecker> We seem to be still checking the complete flag
<t-bast> c-lightning and rust-lightning, what's your current interpretation of the complete/full_information field? Is it ok if we re-purpose it?
<t-bast> cdecker: but how do you react to its value?
<cdecker> Oh, wait no, I mixed up the code paths
<bitconner> cdecker: iirc rusty said you look at it bc lnd split across blocks and that it was for lnd compat
<t-bast> if you already interpret it as an EOF, then it's great, let's make it official :D
<cdecker> I don't think we do, otherwise we'd get a conflict with lnd
<ariard> t-bast: we evaluate it as an error and stop sync with peer
<ariard> so yeah EOF for us is fine
<t-bast> hum unfortunately we always set it to `1` by default to say "yes we have full information"
<cdecker> EOF was how we used to interpret it iirc
<t-bast> but since we don't split blocks it should be ok
<cdecker> Ok, just checked: we don't use complete anywhere significate
<cdecker> s/significate/significant/
<t-bast> Ok great, I'll submit a PR to repurpose it (again, hopefully for the last time!)
<bitconner> might be something that we have to roll out progressively
<t-bast> #action t-bast to submit PR to fix #804
<cdecker> ack
<t-bast> bitconner: if you don't split blocks when replying and set this value to true, then the migration should work fine; I'll detail this in my PR
<roasbeef> lnd 0.12 will no longer split on blocks 
<t-bast> :+1:
<bitconner> 1) receiver-side interpretation, 2) set correctly on sender-side, 3) allow block splitting
<roasbeef> seems th worst case w/e the complete flag is you just end up needing to repeat your last query tho/ 
<roasbeef> like the final block range right? 
* Pavlenex (~Thunderbi@185.244.212.67) has joined
<t-bast> bitconner: oh right, yeah I agree for that kind of rollout
<bitconner> or you end after receiving the first reply
<bitconner> if e.g. complete is always 1
<roasbeef> also are we anywhere close to the 8k chans in a single block limit? I would think that'd require nodes to cooperate to make a single transaction to exist, not facotring in anything else that may be in the block 
<t-bast> bmancini55, could you tell us a bit more about #811?
<cdecker> The main problem with not knowing when you are complete is that you are only allowed one concurrent query, so asking too early means you might get dropped
<roasbeef> fwiw lnd already still sets the complete bit/flag as well 
<roasbeef> since we left it in place for older nodes before we stopped relying on it ourselves to know when the other side had stopped 
<cdecker> Yeah, we set it, but ignore it on the read-path
<ariard> t-bast: IIRC the issue described by Brian is that rn you don't have a way to opt-out from zlib support
<bitconner> in 0.12 we added logic to send back shuffle(channels)[:chunkSize] when there are do many for a single reply, that way there is probabilistic propagation for those channels
<t-bast> ariard: that's my understanding as well, the issue is that the sender (who sends query_channel_range) decides on the encoding the response should use, and you're unable to tell it beforehand that you don't handle zlib?
<bitconner> probably a good recommendation to make in the spec if people stick to no-block-splitting
* Pavlenex has quit (Client Quit)
<bitconner> we could remove zlib :)
<ariard> t-bast: yes and thus you have to uselessly initiate syncing with zlib-support-only peers when you're only interested with raw-support peers
<bitconner> t-bast: wdym by don't support zlib? receivers are required to understand both
<roasbeef> this is related to #804 in a sense, re possilby going over the boundary 
<roasbeef> lnd can unpack zlib, but doesn't pack iirc, we opposed addition of it from teh start, but others wanted to save that couple of RTTs or w/e it was at that time, I don't think we're any where close to having 8k channels in a block as well 
<t-bast> bitconner: rust-lightning doesn't want to support zlib, and they have no way of communicating that so when a node sends them a query_channel_range asking for zlib encoding, their only choice is to drop the connection IIUC
<bitconner> t-bast: that's why we argued to make zlib gated by a feature bit from the start :)
<bitconner> but that ship has sailed lol
<t-bast> I'd need to check the actual data (since our node servers a lot of gossip queries to mobile wallets) to see if it's useful or not
<t-bast> As for gating it via a feature bit, do you remember why this wasn't chosen?
<bitconner> i would not be opposed to removing zlib entirely
<bitconner> simplicity
<roasbeef> I think there were oother concerns at the time elsewhere t-bast, since this was pretty early on and it was simple also 
<ariard> t-bast: your node server is sending the whole graph to your clients or you're selecting paths for them?
<roasbeef> as before that we just sent the entire routing table upon connect lol 
<t-bast> yeah but it could really save bandwidth, which can be useful for nodes that have a lot of mobile wallets connecting to it, so I'll need to check, we may want to keep zlib in eclair...
<bitconner> i suppose it's not too late to create a option-no-zlib feature bit
<t-bast> ariard: depends on the wallet, phoenix doesn't need graph data, but eclair-mobile is a full lightning node
<roasbeef> fwiw you can also cut down on bandwidth by just selecting a handfull of peers to "sync" from as lnd does 
<cdecker> t-bast: remember I had mentioned the incremental server-assisted sync? I have a working version of that if you're interested
<t-bast> I agree, we could add this new feature bit now
<roasbeef> +1
<ariard> a option-no-zlib would solve the issue
<t-bast> roasbeef: that doesn't work when you're the one people chose to sync from :D
<cdecker> Only if you make it mandatory, which pretty much splits the network though
<t-bast> cdecker: I'm interested in that, please do share it :)
<cdecker> Need to finish it up, but it's coming along very nicely
<BlueMatt> cdecker: I presume its based on minisketch or similar?
<roasbeef> server-assited? 
<t-bast> I don't think we'd need to make it mandatory, it's just that this way when connecting to nodes that don't support zlib, you ask them for unencoded data
<cdecker> Nope, it just orders gossip messages, and if you synced once you can tell us exactly when that was
<t-bast> *uncompressed
<cdecker> We can then compute an optimal set of messages to catch you up
<bitconner> eventually you would have to make it mandatory yeah
<cdecker> No need for set-reconciliation if you have a canonical order :-)
<BlueMatt> ah, ok, I mean I think there's a lot of room to redo query sync to make that possible in a general case
<ariard> so support of no-zlib signals "I reply with raw scids only"
<BlueMatt> instead of using a server.
<BlueMatt> eg using time-other-node-received instead of block heigh means its should work 95% of the time (instead of now, which may or may not even be close) and then minisketch or similar is a pretty quick pass to check.
<t-bast> ariard: exactly, it means you should only send me query_channel_range *without* zlib activated
<BlueMatt> but all of that is a lot more work than "ugh, no zlib"
<t-bast> true that, that's why we've been discussing better gossip for a while, but no-one dived into implementing it :)
<cdecker> Ok, let's bikeshed a flag to signal no-zlib first, and we can brainstorm other things later
<bitconner> imo option-no-zlib should be blue
<BlueMatt> right.
<t-bast> I can draft a PR for that as well, and we can discuss it on github and during next meeting?
<martindale> Red please
<t-bast> Purple. Definitely purple.
<ariard> t-bast: and it doesn't matter to have a optional/mandatory interpretation
<t-bast> #action t-bast draft a feature flag for zlib support PR
<t-bast> #topic DB export format
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/820
<cdecker> This is pretty much undoable if you ask me
<t-bast> Haha. I was about to say that key handling / derivation would probably be painful, but why undoable?
<bitconner> fwiw a hacky way to do no-zlib today would be to look for mandatory DLP (since i think only lnd sets that) and we never send back zlib
<BlueMatt> standard db of *what*?
<roasbeef> it's possible, but could be hard to maintain compat between all the impls 
<roasbeef> basically they want an exportable channel format 
<BlueMatt> standard db of channel data? yea, thats not nearly worth the amount of effort
<roasbeef> that can be imported into anything else 
<cdecker> We cannot fully describe the entire schema of all implementations, so it'd have to be a subset. A subset means we'd need to have ways to rehydrate the remainder
<BlueMatt> right, what cdecker said.
<t-bast> cdecker: yeah I agree, painful
<t-bast> Other option is to wait for low fees and close your channels
<roasbeef> great idea in the abstract, but will be hard to get right at the impl level, not to mention other impl level local priorities 
<t-bast> Re-open with a new implementation
* jonasschnelli (~jonasschn@static.239.36.216.95.clients.your-server.de) has joined
<cdecker> It might be possible much much later, when development has settled down, and we happen to converge to a common schema, but right now it'd be very limiting for very little upside
<BlueMatt> so, seems there's broad agreement - just not practical, certainly not practical in the coming few years.
<cdecker> ack
<t-bast> Ok, I sense a strong no from everyone :)
<bitconner> it's probably easier for us to start from scratch and build one impl than to make dbs compatible with four existing impls
<BlueMatt> lol, probably indeed bitconner 
<t-bast> I'll answer on the issue.
<roasbeef> ppl can start to dev it thesmevles ofc as well, doesn't neccsrily need to be something on the spec level until it gets some actual uptake 
<roasbeef> lol
<t-bast> #action NACK the issue
<t-bast> #topic 1 sat/byte for second level HTLCS in anchors++
<t-bast> ariard I believe you added that one?
<bitconner> why not 0?
<cdecker> If it were a minimalistic approach like lnd's SCB then I could see it working, but a whole DB, no
<t-bast> as long as it's a constant value, we can pretty much put anything, can't we?
<roasbeef> I just added this
* nobody123 has quit (Remote host closed the connection)
<roasbeef> we implemented a mitigation against the fee leak stuff 
<roasbeef> but found it too restrictive in practice, like smaller channels could only have 4 outstanding htlcs, stuff like that 
* nobody123 (~nobody123@213.153.86.159) has joined
<roasbeef> so we've went ahead and implemented the variant of anchors that has 1 sat/byte at the second level 
<ariard> the only downside I can see is now you have to spend a bumping utxo?
<bitconner> roasbeef: we implemented 0
<roasbeef> to force aggreegation and eliminate the vector 
<roasbeef> err yeh 0 lol
<roasbeef> this is also kinda nice as you can potentially salvage more of the htlc is you need to go on chain 
<roasbeef> ariard: yeh that's the tradeoff, but lnd has a pretty good internal system for bumping/input aggregation 
<ariard> it's fairer for the channel initiator to not have to pay counterparty-initiated HTLCs at the price of increasing the average onchain price
<roasbeef> and users could potentially use swap servies like Loop to swap out and anchor down in a single transaction 
<roasbeef> ariard: well there's two things here: the htlc output, and the second levle feees 
<roasbeef> initiator still pays for the htlc output, but the sender now doesn't pay for the second level fees until broadcast/timeout time 
<ariard> roasbeef: right the htlc output is still paid by channel initiator with your proposal?
<bitconner> on the commitment txn, yes
<roasbeef> so we're looking at obtaining a new feature bit for this, and will likely just advertise this going forward, as we want to start to enable this by default
<t-bast> roasbeef: the swap-out + bump fee idea is interesting, you'd actually be paying off-chain for an on-chain RBF
<roasbeef> t-bast: yeah, also a cool concept independently of this specific use case as well 
<ariard> it's increasing average price but as it's only sad scenario, i.e unilaterla onchain closing I think that's okay
<bitconner> ariard: wdym increasing price?
<t-bast> roasbeef: but that probably requires a protocol to exchange signatures and allow the swap server to attach an input...not sure how feasible it is in practice 
<roasbeef> yeh if you need to swap, but i think many nodes that are routing have output sitting around just due to sweeping random things that go on chain 
<ariard> bitconner: previously the second-level HTLC transactions fees would have been paid from the funding output amount?
<roasbeef> so we just want a bit allocated, and could potentially use a higher one 
<ariard> bitconner: i mean the htlc output
<roasbeef> t-bast: not sure what you mean, ifyou impl swaps as Loop does, this is just the client sweeping that output and anchoring down in a single transacton 
<t-bast> I'm in favor of this, but that really needs a spec PR to ensure we use the same feature bit and constant feerate
* nobody123 has quit (Ping timeout: 256 seconds)
<ariard> and if your input/output pair with outgoing amount is the same than htlc output you have to attach a bumping utxo to pay
<bitconner> ariard: the price is still the same, just comes from a different input, which is already the case bc of single/acp?
<roasbeef> mhmm, we're planning on, but just want to flag that we'll likely move faster than the spec PR, tho the params are pretty consstrained 
<t-bast> roasbeef: oh ok, I think I see what you mean for the swap, I was thinking of something different then
* molz_ has quit (Ping timeout: 272 seconds)
<roasbeef> since from our pov, it's been so long and we're so close to getting this thing out 
<ariard> bitconner: yes and this different input wouldn't have been spent previously, I mean your transaction is bigger by one input?
<BlueMatt> given how many times anchor has been close and then ariard found some new critical-ish issue in it, lets make sure its all written out and there's more time to stare at it.
<t-bast> did you consider a constant feerate, but negotiated at channel_open time?
<bitconner> if you don't attach another input then the fees can be siphoned by anyone.. no? so wasn't that always a requirement?
<t-bast> because you still have the issue that it may end up below the min-relay-fee, don't you?
<roasbeef> you still have the sighash all component bitconner 
<roasbeef> t-bast: this forces aggregation and/or another input 
<t-bast> roasbeef: but without package relay, that won't work, will it?
<bitconner> ah right, only one of the signatures is single/acp
<roasbeef> it will, since you always attach something 
<roasbeef> it's your job to make sure that somethign gets propagated 
<roasbeef> this isn't the commitment transaction with a clamed fee rate, it's the second level htlcs 
<roasbeef> what fee rate the other party signs with 
<t-bast> oooh right
<t-bast> of course
<t-bast> you add inputs, my bad
* mol (~mol@unaffiliated/molly) has joined
<cdecker> Nice, sounds like yet another eltoo feature being backported :+1: 
<roasbeef> yeh so you always add
<roasbeef> hehe
<t-bast> but did you consider negotiating it during channel_open? This way if I want to set it to 5 sat/byte (but constant), it doesn't suffer from the issue ariard found and I may not need to attach a new input
<ariard> roasbeef: the sighash_single counterparty sign the second-level output amount with the same value than the htlc output ?
<bitconner> we chose with zero since it ensures there are no fees to siphon, any chosen constant still has wiggle room for games
<roasbeef> t-bast: that still leaks _something_ tho fee wise 
<roasbeef> may not need to attach, but  likely would in practice given time lock expiry constraints 
<roasbeef> ariard: essentially yeh, so that input+output are "locked" 
<ariard> roasbeef: you will always need to attach otherwise you hit min-relay fee as raised by t-bast?
<bitconner> you also might overpay by 5x
<t-bast> ok got it, that's interesting
<ariard> I concede the attachment is probabilistic, like only if you need to broadcast the transaction
<roasbeef> the change it's impl wise is pretty small, you just remove the "fee decrement" for this chan type 
<BlueMatt> it does kinda suck just in terms of how expensive it is to add the output
<roasbeef> yeh so the "happy path" isn't impacted 
<BlueMatt> errr, input
<roasbeef> BlueMatt: which output? 
<BlueMatt> but also maintain an output on chain
<t-bast> do you have anchor output channels in production you care about? if not that 0-fee on HTLC txs could be the default for anchor output channels, to avoid a compatbility matrix nightmare (once scrutinized and implemented)
<roasbeef> ah to bump? yeh there's that 
<bitconner> this is the change: https://github.com/lightningnetwork/lnd/pull/4840/commits/af1fe6bebc6f4ec9fbc109b9c34d529dfa766ca1
<ariard> it's increasing the cost of the "sad path"
<roasbeef> t-bast: hard to tell, but fwiw it's been a build/dev flag on lnd, so I think adding a new bit is a better path
<BlueMatt> by a nontrivial margin, too.
<roasbeef> ehh disagre it always increases the sad path
<BlueMatt> though I dont know that I care, just pointing it out.
<roasbeef> as you might have been overpaying before 
<BlueMatt> 1 sat/vbyte is never overpaying :p
<roasbeef> and you'd likely want to bump/aggegrate anyway to accoutn for the timelock race on force close 
<t-bast> roasbeef: ok, and probably allows experimenting earlier, and we may later choose to force both feature bits to be mandatory if we want to remove some code
<cdecker> Sounds like exactly what the experimental high feature bits were introduced :-)
<roasbeef> t-bast: mhmm, those that havne't deployed have the option to only signal this new bit as well fwiw, tho the gap between them is pretty small, and for lnd kinda doesn't matter in practice as we have generalized sweeping/aggregation engine internally 
<roasbeef> cdecker: yep, so I think we may pick a high bit to start with, and then bank on something something dynamic commitments in the future to have things eventually be uniform
* kabaum (~kabaum@h-13-35.A163.priv.bahnhof.se) has joined
<roasbeef> how close are others in enabeling anchors as their default chan type? 
<bitconner> there is also the matter of: if we have the safer format, do we allow creation of leaky-anchor channels
<cdecker> Yep, sounds like a plan. I'm curious to see these proposals in action
* laptop has quit (Ping timeout: 240 seconds)
<cdecker> Ideally the lessons learned iterating should inform the golden anchor implementation I think
<roasbeef> cdecker: +1
<t-bast> We've been lagging behind in eclair, we need to work on the whole RBF engine story. Got caught up working on Phoenix iOS, so it will take us a few more months before anchor outputs can safely be enabled.
<ariard> generally, the price "sad path" will have to increase if we're moving off from negotiated feerate (package relay future)
<roasbeef> ariard: the price of the sad path is a function of the ctlv delta and on chain dynamics as well 
<roasbeef> as you're usually force closing for a reason 
<roasbeef> but ok, we'll put up the PR spec wise, and also pick a high bit for our own experimentation 
<ariard> roasbeef: functio nof the cltv delta ? how do this increase your feerate
<bitconner> if we want to make the sad path less costly we could also backport the eltoo txn structure, and remove those expensive outputs on the contested stae
<roasbeef> i wonder if it's possible to add sparse bit encoding w/o adding a new init message as well...
<bitconner> state
<roasbeef> ariard: if the delta is 2 blocks, you need to get into the chain within that delta or the timelock race starts 
<roasbeef> if it's 1000 blocks, you have more time and can likely end up using a lower fee rate 
<roasbeef> bitconner: yeh that "generalized channel" paper starts to go in that direction, soem cool ideas there 
<ariard> roasbeef: i see and you need to increase your feerate but it's already a higher level question that the fee model you're choosing
<t-bast> #action LL to create PR detailing the proposal and exposing an experimental feature bit for compat' testing
<roasbeef> ref: https://eprint.iacr.org/2020/476
<ariard> bitconner: yeah I've a draft post to compare package-relay vs-eltoo+moar malleability, imo either would solve pinning
* laptop (~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com) has joined
<bitconner> nice, looking forward to it!
<cdecker> Absolutely
<bitconner> has CL deployed anchors?
<cdecker> We have an experimental implementation (behind compile guards), so we could test compat, but don't announce experimental things in the changelog
<ariard> roasbeef: what would be really cool is to cooperatively relax timelocks when the mempool is congestionned
<bitconner> if the peer is cooperative, why unilateral close?
<roasbeef> ariard: that can be done w/o cooperation 
<roasbeef> since you just update your CLTV delta in your direction 
<ariard> bitconner: it might disappear in the future when the mempool is still congestionned
<bitconner> gotcha
<roasbeef> but that's a good idea also, possilbe today, impls just need to pick a heuristic
<bitconner> or maybe accidental close
<cdecker> Gotta run off in a couple, shall we address the last topic?
<roasbeef> could also base it off past exp
<roasbeef> ok what's next?
<ariard> roasbeef: I meaned the CLTV in the transaction but you need coordination on the whole path, not only the relay policy
* MrMa (92735271@146-115-82-113.s2410.c3-0.sbo-ubr1.sbo.ma.cable.rcncustomer.com) has joined
<t-bast> Yes, let's quickly go throught the last item
* jonasschnelli has quit (Quit: ZNC - http://znc.in)
<t-bast> #topic Channel backup revisited
<ariard> RL's anchor was pending on spec agreement on the fee leak issue 
<cdecker> Alternative backups
<t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html
* jonasschnelli (~jonasschn@static.239.36.216.95.clients.your-server.de) has joined
<roasbeef> ariard: the value in the transaction, is dervied off your routing channel policy tho? 
<t-bast> This proposal changes the funding tx script to make the remote funding pubkey determinisitc
<t-bast> That makes channel backups easier once you've only backed up your seed
<roasbeef> interesting, haven't read the mail yet 
* jonasschnelli has quit (Remote host closed the connection)
<bitconner> cdecker: got it thanks! for 0.12 lnd still needs to decide whether to allow leaky-anchors, but it sounds like we have some time before elcair and CL deploy in full
<cdecker> This proposal also makes use of the peer's willingness to act on our behalf (close the channel, correctly)
<t-bast> The main issue I see is that when you have multiple channels to a peer, you need a counter (argh)
<cdecker> I'm not sure we should encourage relying on the one node in the network that gains from stealing from us
<roasbeef> how does this avoid re-use? 
* jonasschnelli (~jonasschn@static.239.36.216.95.clients.your-server.de) has joined
<roasbeef> cdecker: yeh nad we've tried to move away from that by doing static remote key 
* jonasschnelli has quit (Remote host closed the connection)
<bitconner> ariard: 👍
<ariard> roasbeef: it's function ofc (i.e max_accepted_htlcs) but it would more a preventive measure to prevent massive channel closures due to nodes running off of bumping utxos
<roasbeef> also this doesn't work for nodes that aren't advertised in the network 
<ariard> and thus closing before to being unable to confirm
* jonasschnelli (~jonasschn@static.239.36.216.95.clients.your-server.de) has joined
<roasbeef> also this still would rewuire you to somehow make the other side force close right? 
<cdecker> Jap
<roasbeef> identifying the output is only half of the recovery scenario 
<cdecker> Recover, connect, signal, wait for close
<bitconner> it is kind of nice that you can just run through all public routing nodes and scan the chain..
<bitconner> even historical ones
<bitconner> you don't even really need a list of pubkeys
<roasbeef> but it also forces re-use, and adds identifyign on chain information back to the LN layer 
<roasbeef> so even unadvertised chanenls would easily be linked back to the nodes 
<t-bast> right, the right to forget when deleting a backup is actually a feature?
<bitconner> roasbeef: re-use?
<roasbeef> it is a link level thing tho, so ppl can start to roll it out if they wanted with an exp feature bit 
<roasbeef> bitconner: all my chanenls to you will use the same multi-sig keys, and have the same script hash 
<bitconner> there's a counter
<roasbeef> now and also in the future
<bitconner> >  Of course, to open
<bitconner> multiple channels with the same node we would have to generate a new shared
<bitconner> secret from each one by hashing a counter.
<ariard> it's still stateful you have to remember the counter
<t-bast> yeah or brute-force the counter
<roasbeef> so it's w/e counter state vs the SCB type format itself which is a few hundred bytes
<bitconner> yeah, but within the realm of brute forcability /shrug
<niftynei> my understanding is it makes brute-forcing a recovery within the realm of possible
<roasbeef> I think it's also overlooking the on-chain brute force cost tho 
<roasbeef> wihch can be prohbitive depending on node set up and age of chan kinda 
<roasbeef> one Q that comes to mind also is how to sync the counter state and if that's needed 
<roasbeef> so it can create a new look ahead gap in a sense 
<roasbeef> if we start funding, then stop for w/e reason, and also how to deal with concucrrent funding attempts
<t-bast> there's something you can do with a cooperative peer: encrypt that counter and send it to him when you `revoke_and_ack`, and have him send it back in `channel_reestablish`
<roasbeef> t-bast: iirc eclair does something liek this already right? 
* Pavlenex (~Thunderbi@185.244.212.67) has joined
<t-bast> yes, we do that for phoenix: https://medium.com/@ACINQ/phoenix-wallet-part-3-backup-f63a9470d4e7
<ariard> t-bast: hmmmm counter is for channel opening ? why does it come at reestablishment, you assume knowledge of funding script at this phase?
<t-bast> ariard: it can simply prevent the brute-force step
<t-bast> ariard: but maybe it's not useful and brute-force is totally ok
<ariard> t-bast: add a new message "do-i-have-channel-with-you" ? information space is cheap
<roasbeef> since chans made w/ unadvertised nodes aren't covered wtih this, it still kinda falls back to an SCB-like structure imo 
<cdecker> You mean "now-is-a-good-time-to-cheat-me-out-of-my-money" message :-)
<roasbeef> kek
<t-bast> lol
<roasbeef> something something watch towers 
<cdecker> "Please blackmail me" message
<bitconner> LOL
<niftynei> bahaha
<roasbeef> --we-do-not-negotiate-with-terrorists=1
<ariard> cdecker: ahahah isn't already the assumption with DLP?
<bitconner> my sides
<niftynei> should probably add a "mercy" flag to that message lol
<cdecker> Hehe, and since it'd be unfair to keep that info private, let's add a "hey-i-restored-from-a-leaky-backup" flag in the node_announcement
<cdecker> So the whole world can have a laugh
<bitconner> roasbeef: yeah that's a good point, something like SCB will always be required for non-advertsided nodes
<t-bast> shame, shame, shame
<cdecker> But yeah, good point on non-public nodes
<niftynei> mmh sounds like this is 'an improvement for public nodes, doesn't help private channels'
<roasbeef> niftynei: yeh, with caveats w.r.t concurrent funding and how to handle the "look ahead gap" when scanning on-chain 
<roasbeef> look ahead gap meaning, when do I stop looking, as it's possilbe we skipped counter values due to failed funding 
<bitconner> yeah it's an improvement for public counterparties, but often public nodes have private counterparties so doesn't help public nodes all that much
<cdecker> The counter can also be replaced with something publicly known: blockheight or blockhash
<niftynei> ah yep. but it does create a 'bounded search space' for recovery
<cdecker> That way we always look +/-100 around the funding TX height and can derive the counter
<ariard> it's rate-limiting your channel opening per-block?
<bitconner> what happend to disseminating blockheight/hash in the ping msg :)
<roasbeef> IIRC CL used to factor in teh node pubkey when deriving certain keys but removed that right? 
<cdecker> ariard: yep, but only per peer
<ariard> bitconner: like a lot of things, will happen in 2021 
<t-bast> we also mix in the funding key in our bip32 path for channel keys
<cdecker> roasbeef: key derivation still includes peer_id