Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lightning Specification Meeting 2021/01/18 #831

Closed
17 tasks
t-bast opened this issue Jan 11, 2021 · 2 comments
Closed
17 tasks

Lightning Specification Meeting 2021/01/18 #831

t-bast opened this issue Jan 11, 2021 · 2 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented Jan 11, 2021 •
edited
Loading

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

Pending from last meetings

Pull Request Review

Issues

Long Term Updates

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.

Post-Meeting notes:

Action items
@t-bast
Copy link
Collaborator Author

t-bast commented Jan 11, 2021

As usual, don't hesitate to add topics you'd like to see discussed.

@t-bast t-bast pinned this issue Jan 11, 2021
@t-bast
Copy link
Collaborator Author

t-bast commented Jan 18, 2021 

<t-bast> #startmeeting
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/831
<bitconner> side note: planning to update/replace the current amp draft PR this week
<t-bast> #topic Bolt 3 test vectors
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/539
<t-bast> bitconner: nice!
<t-bast> jkczyz I see you merged to rust-lightning the test vectors, so it looks like they worked on your end?
<jkczyz> yes, hi verified the new test vector for RL. thanks for helping out t-bast!
<t-bast> great!
<t-bast> cdecker do you know if someone tested them in c-lightning?
<t-bast> shall we merge them or wait for another ACK?
<cdecker> Not sure, we're putting the finishing touches on a new release, so a lot of things in flight atm
<t-bast> Allright, there's no hurry to merge this PR, we can wait for you to test it out after your release
<t-bast> I'll tag rusty for that
* rdymac (uid31665@gateway/web/irccloud.com/x-egpflvuxyltuygug) has joined
<t-bast> #action wait for c-lightning to verify the test vectors after their release
<t-bast> #topic Sync complete flag
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/826
<t-bast> Quick update on that one: I've made the changes in eclair to correctly set `sync_complete`
<t-bast> lnd already does this
<t-bast> what about rust-lightning and c-lightning?
<t-bast> once all implementations have merged support for correctly setting the field, we can start interpreting it and later split blocks across queries
<ariard> not yet implemented, I think bmancini is working on it
<cdecker> c-lightning still implements the old behavior
<cdecker> Opening a new PR on our side to get this back on the radar
<t-bast> Cool thanks, probably for after your release. Let's keep this item on the agenda and we'll get there.
<t-bast> #topic anysegwit
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/672
<t-bast> Has someone implemented this yet (apart from c-lightning)?
<t-bast> We had a concept ACK, it's simply pending an interop test once someone has time to implement it.
<bitconner> not yet for lnd, probalby 0.13
<t-bast> :+1:
<ariard> I'll open an issue in RL
<t-bast> Ok then, let's keep it on the agenda to track when we've got interop testet
<t-bast> *tested
<t-bast> #topic 0-fee htlc anchor outputs
<t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/824
<t-bast> I've seen that lnd merged support for this already
<t-bast> Has someone finalized another implementation and been able to do an interop test?
<bitconner> yes it will be available in 0.12
<bitconner> but opt-in
<t-bast> by default you'll keep using the standard commitment format?
<roasbeef> yeh we want to expieriment w/ a few diff ways of ensuring utxos are available or able to be tacked on 
<t-bast> ok great, that gives us more time to catch up xD
<roasbeef> as otherwise stuff like sendall would start failing overnight for ppl if it were made the default
<roasbeef> so wanted to soften that change on wallets, etc 
<t-bast> cool, makes sense, don't hesitate to share what you learn there (on the PR or elsewhere)
<roasbeef> yeh my fave solution to the UTXO reservation in general is ppl using stuff like Loop Out to be able to move funds from existing channels, but then you still have an edge case when you only have that one channel that's inactive or w/e that you want to force close 
<ariard> or ask for reserve bumping UTXO at channel funding, automatically splitted from the funding
<roasbeef> in the end, it pushes the problem a bit out into the future, but lets you better utilize the funds in a channel until that point (which may never come also since it's a force close scenario) 
<roasbeef> ariard: yeh we have that impl'd rn, if someone tries to use sendall, we insert another output if there's no c hange to resreve for the channel 
<bitconner> there still needs to be a solution that doesn't depend on third-party service
<roasbeef> Q ofc is how big you should reserve there 
<roasbeef> sure, it's just an easy way for those that're already using it 
<ariard> roasbeef: that's a really good question have you heard fractional reserve ?
<roasbeef> big Q is how big the UTXOs should be that you reserve, which kiiinda gets you back to "guess fees ahead of tiem" 
<bitconner> (which is why node should implement some sort of on-chain fee reserve)
<roasbeef> tho in this case it's an exceptional thing, and you can still recover if able to get more funds into the wallet 
<ariard> game-theory you would like to have the full-channel value available too burn in fees
<ariard> but that's not realistic on the economic-side
<roasbeef> possibly on the API level, this can be exposed to users as another "on chain reserve" for a channel 
<bitconner> there are also some edge cases around initial funding: should you accept an anchor channel if you have no utxos?
<ariard> roasbeef: you bumping utxo reserve can be shared across channel
<t-bast> it opens a huge can of worms :)
<bitconner> you may need funds to sweep a disputed htlc
<ariard> it works if you don't have to close all of them as the same time
<roasbeef> ariard: mhmm, so q is do you always aggregate it each funding attempt, or leave them as diff utxos which increases costs at force close stime slightly 
<ariard> bitconner: the bumping utxo can be either attached to the CPFP on anchor or aggregate with second-level
<ariard> at least my implementation is doing this
<bitconner> ariard: how do you do that with no utxos?
<roasbeef> yeh that's how we do it as well, works pretty good in practicve so far, and we can also just aggregrate the htlc second lvl w/ other sweeps or w/e going on at the time 
<t-bast> he's a bitcoin core dev, he doesn't need utxos
<ariard> roasbeef: yeah this q should also encompass your onchain activitty if you have an unified wallet
<roasbeef> the main reason we didn't do it by default was wasan't very confident in the down stream UX for developers and those running services, etc -- as some things they're doing rn would possilby just be prevented or work in a slightly diff way 
<bitconner> we just need a magic opcode that will sweep htlcs for free :)
* roasbeef dials up f2pool
<lndbot> <johanth> that would be cool :slightly_smiling_face:
<ariard> bitconner: you ask them to reserve utxos at channel opening, forcing a reserve from the channel value they want to open
<t-bast> that's an issue we've raised right from the beginning: anchor outputs moves the complexity away from estimating the on-chain fee to reserving utxos efficiently but safely, which is really hard to put in a nice UX for a mobile wallet
<ariard> I agree, we're going to grope a bit here...
<t-bast> it's especially hard for "small" nodes
<t-bast> in particular for the case bitconner mentionned: if you're a small node, what do you do if many people want to open channels to your but you don't have that many utxos?
<ariard> t-bast: you mean for the ones buying channels, like phoenix?
<t-bast> it's awesome to get incoming liquidity so you shouldn't brush it off, but are you taking a risk there?
<ariard> which don't have utxo at all
<t-bast> I meant for all small nodes/wallets, that have limited funds but want to maximize the utility of their btc, without having too much unused capacity
<bitconner> t-bast: it's not so bad if you're not a routing node, worst case is you leave a timeout on chain that can be swept later if funds are added
<ariard> t-bast: you can have one bumping utxo for all your channels, and chain your CPFP for closing if multiples have to be closed
<t-bast> bitconner: true, it's better for wallet since they don't relay, many attack vectors simply disappear there
<ariard> but beware not hitting the mempool packages limit
<t-bast> ariard: I think it can still be exploited, if someone opens many channels to you, then slowly closes them as you bump: the RBF rules may make it very hard for you to adapt your sweep to additional channels being closed
<roasbeef> t-bast: imo matters a bit less for mobile nodes, since they likely aren't forwarding payments, so there's no worst case scenario where they lose funds due to not being able to claim on time 
<t-bast> Mallory opens 10 channels to you, closes one: you use your utxo to bump, then Mallory closes a second one, you need to either chain or RBF, then she repeats until you hit mempool limits or can't RBF because you can't afford the minimum increment
<t-bast> roasbeef: yes I agree, it's not very risky for mobile wallet, but small-ish routing nodes may have issues there
<roasbeef> t-bast: as long as the utxo is confirmed you can add that as a new input to your RBF transaction 
<t-bast> right, you can wait for a few blocks if you have high enough cltv_expiry_deltas
<roasbeef> idk doesn't seem like something to be too worried about...mallory needs to also spend an amt of chain fees in the same order of mag 
<t-bast> it still makes me uneasy, coupled with a period of high on-chain fees, this feels dangerous for small nodes
<roasbeef> someone's gonna get something confirmed eventually
<roasbeef> it's waaay better for small nodes, they can actually adaptnow 
<ariard> I don't think Mallory needs to spend here, you just hold on channel update to force your honest counterparty to close
<roasbeef> but yes adapting properly needs to be carefully implemented, but before they'd be fucked and have no way to update things at all 
<t-bast> you just don't ACK a fulfill for example, forcing the remote to close
<bitconner> yes but if you're not forwarding payments then you don't lose money if you can't get confirmed in time
<ariard> roasbeef: yes you can aggrregate and thus stay under mempool package limits
<roasbeef> goes back to the "...are we still talking about fees" questrions -- yes, fees are hard at the end of the day 
<ariard> it's 2021 we're still talking about fees :p
<bitconner> nothing is certain but death and fees
<ariard> xD
<t-bast> It's really the hardest thing about lightning, it always boils down to "is the assumption that you're able to settle on-chain in time holds"?
<t-bast> But there's clearly no silver bullet there
<t-bast> We'll have to deal with this with trade-offs (as always) :)
<ariard> t-bast: even worst you have to consider systematic risks like mempool getting full, people starting to preempttively close channels
<ariard> fees getting higher, nodes running out of bumping utxos, closing more channels...
<cdecker> Agreed, and I think it's ok to set up some (explicit) assumptions for our security model
<ariard> side-note: I do have a gist listing tx-relay jamming vulns if interested: https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af
<ariard> and the kind of works required core-side to patch them 
<t-bast> But don't get me wrong, it's great to be working on these, it's a net improvement from the standard commitment format
<roasbeef> t-bast: def
<ariard> cdecker: it's hard to modelize, you have to adapt to your counterparty behavior which might not be known because mempools aren't global
<cdecker> Agreed, we should come up with a good attacker model, explicitly write it down, and then work up to that line, but not beyond
<ariard> cdecker: yeah I should motivate myself to write such paper this year...already thought about it
<cdecker> Hehe, not saying it has to be you, but you're the one whose most knowledgeable about these pitfalls
* ddustin has quit (Remote host closed the connection)
<t-bast> Back to something you mentioned roasbeef about looping out to help that scenario: it would be very cool if you could, via a lightning payment, directly bump an anchor. You would ask the loop server to do a swap out to your address, adding a specific anchor as input. Does that make sense?
<cdecker> Nice idea ^^
<ariard> t-bast: it's third-party security like watchtower but yes interesting to explore
<t-bast> You could use off-chain funds to make up for your lack of utxos
<cdecker> I think we were playing with a couple of things in that direction, with the PSBT support
<bitconner> t-bast: yes that's correct
<roasbeef> t-bast: yeah that works rn w/ our loop out as implemented: you can sweep the HTLC directly into your bump transaction 
<roasbeef> the daemon doesn't do so yet, but as we can package loop+lnd in a single binary it can be adapted to do so easily or even remotely if needed since you can do custom signing w/ the lnd APIs 
* ddustin (~ddustin@unaffiliated/ddustin) has joined
<roasbeef> so I like it as a fall back plan if w/e else fails before that 
<t-bast> right, you mean that you do a normal loop out then add this (new) utxo of yours as input to your HTLC tx
<roasbeef> mhmm, seems like you want more coordination to save that exta transaction (?) 
* ThomasV__ is now known as ThomasV
<ariard> or as a CPFP to bump your commitment but you're relying on good confirmation time of your loop out provider
<cdecker> Could this be short-circuited: have the loop server provide a single-sig input (and corresponding change output) that can then be attached to my close?
<roasbeef> well you can use CPFP to anchor down that swap transaction (that one that makes the HTLC), so you can help accelerate the conf ariard  
<t-bast> cdecker: that's the kind of thing I had in mind
<cdecker> Gotcha
<roasbeef> cdecker: yeh I think so, but then they need to reserve that utxo for your in a sense 
<cdecker> Right, that's a downside
<roasbeef> rn it uses RBF to essentially "add more ppl" to a bastch continually until one of them confirms 
<roasbeef> batch*
<cdecker> We'd also need to communicate how much of my loop out ought to be in fees
<roasbeef> on the other end, splicing helps w/ this kinda, as you can move funds from a channel, tho you need a solution still when you only have that one channel left 
<cdecker> (and single-sig isn't safe either: miners can strip the payload tx, and just keep the fee payer part)
<ariard> roasbeef: if it's a batch tx it's better to wait for confirmation otherwise a batch member can mempool-junk its utxo to prevent using yours as an input for a CPFP
<t-bast> yes, do you have a way to trustlessly ensure the loop server uses a given feerate?
<roasbeef> t-bast: the on-chain fee rate for the transaction creating the swap htlc? 
<t-bast> yes, it feels to me you have to trust the loop server to use the right feerate
<roasbeef> as defined not really, but at the service level we have a few diff "speeds" ppl can choose from which affects the end fee 
<t-bast> I don't see how you could force him to use an agreed upon feerate
<bitconner> if the utxo was reserved in a multisig setup you could do that
<t-bast> but it's based on trust? Or can the sender verify the tx feerate before sending the lightning payment?
<roasbeef> yeh not really, but you can accelerate it somewhat since you can anchor down w/e is there to use to pay for your input 
<bitconner> so the user knows the fee rate being used bc they also have to sign
* ThomasV_ (~ThomasV@unaffiliated/thomasv) has joined
<roasbeef> t-bast: the fee rate as defined rn yeh, also we're free to modify that fee rate in order to get a conf in 
<cdecker> Well, we could also send the close to the loop server and ask it to make it whole, but that's the same as the taxi.* stuff we have on liquid
<roasbeef> the swap serve is also incentivzed to get things confirmed on time as there're time lock risks as a normla htlc 
<ariard> roasbeef: you have to trust the server, it might have already double-spend the swap but you don't the pinned copies in your local mempool?
<roasbeef> ariard: why would it do that? it's sellilng a service -- any other party in the batch can also anchor down the swap transaction to accelerate their loops
* ThomasV has quit (Ping timeout: 264 seconds)
* ThomasV_ is now known as ThomasV
<roasbeef> or maybe i'm not following, you're saying it is itself onthe other side of the channel and wants to block you? 
<ariard> roasbeef: security-wise, you have to consider the service as a third-party which might be also your attacker, economic-wise such service won't hold for sure
<roasbeef> w/ the way it's impl'd it wouldn't even know that it's you really, each user has an LSAT that identifiers them that they can rotate out if they want 
<ariard> roasbeff: yes it might be itself the other side of the channel
<roasbeef> but it's possible, but prob not something most ppl need to fear
<ariard> in practice, I agree it's relying on reputation
<roasbeef> prob greater risks ppl need to watch out for that're more direclty under their control 
<roasbeef> ppl can also make their own, the core mechanic of a sub-swap is pretty simple, but we've added on a lot over time to enchance it and add other uses cases/flows, etc, etc 
<ariard> well I think the initial discussion was using loop as bumping utxo providers for mobile wallets
<roasbeef> imo it's better for routing nodes, mobile wallets aren't really at risk 
<ariard> mobile wallets aren't designed for high-stakes anyway so they should be fine relying on such loop services
<roasbeef> ariard: yeh, should be pretty smol amounts, tho from exp ppl really just like to YOLO into things xD 
<t-bast> yeah and they'll just end up having txs that are painful to confirm because they need to find utxos to bump, but they shouldn't lose any money
<ariard> I expect big routing nodes doing their own bumping utxos management...
<roasbeef> and sudden price increases can change your risk profile also lol
<ariard> ...once we know what does it mean :p
<t-bast> we've seen crazy amounts in mobile wallet channels...#reckless
<roasbeef> t-bast: yeh same, then ppl forget it's there and send in support tickets years later once it's worth 10x 
<t-bast> I had a lightning channel in 2018, I've lost my backups, my seed, my phone and the keys to my appartment, but can you help me recover my funds?
<t-bast> Those damn boating accidents...
<roasbeef> kek
<ariard> t-bast: sure just give me the property title of your appartment 
<cdecker> I had a channel bakc in 2005, can you help me?
<roasbeef> yeh we officially shut down that old wallet mobile wallet we made this year, have been dealing w/ a lot of those...
<cdecker> Yeah, lightning could be so cool, if only there weren't these pesky users
<cdecker> xD
<t-bast> :D
<roasbeef> any other major things on the agenda ppl wanted to get to?
<ariard> I've already met LN users in real life, they're good people I swear!
<t-bast> We're already over 1 hour, I don't think we'll start another topic, shall we keep chatting a bit and then close today's meeting?
<t-bast> I liked that utxo / bumping discussion, I think it's really helpful
<ariard> have a look on the bitcoin-dev ML, darosior has started a topic around HW support for L2
<t-bast> right, that's a fun one
<ariard> and gathering a list of grievances to HW vendors
<t-bast> HW lightning wallets are another way to open a can of worms
<roasbeef> yeh pretty big problem space, but also depends on what you're after...
<roasbeef> stuff like being able to *fund* a channel using a HW is pretty much here using PSBT stuff 
<t-bast> I completely agree with zman that they're not a silver bullet as you need a separate solution to monitor the chain
<ariard> it's more signing channel operations in a trusted enclave
<roasbeef> any other thing you need to come to terms w/ how much auto signing and how much verification you can really do if it's about also signing commitment states 
<ariard> yeah lightning is harder than vaults due to states
<roasbeef> yeh that's a whole thing in itself 
<roasbeef> just inserting some validation proxy in front of the signer prob gets you a lot in practice 
<ariard> devrandom has pretty good documentation on trustless lightning nodes: https://gitlab.com/lightning-signer/docs
<roasbeef> but also depends on what kinda of security model yuo're interested in as well 
<ariard> "If you're main lightning node is compromised are you losing funds"
<ariard> ideally you might have a number of tower replicas, you're safe if at least one isn't compromised
<ariard> where compromised is extensively defined as do you still have acces to the chain
<t-bast> does their proposed solution also encompass the bitcoin wallet?
<t-bast> I'm thinking in particular for anchor outputs and swaps
<ariard> wdym?
<t-bast> It's really hard to a HW wallet to verify you're an attacker is not making it sign txs/htlcs that exfiltrate funds
<t-bast> *to verify an attacker [...]
<ariard> it's really hard I agree but you assume access to a UTXO set oracle you can implement something like this
<t-bast> The flow of funds that must be enforced by the HW wallet is very much non-trivial once it has to deal with both on-chain and off-chain funds
<ariard> in the far shiny future I hope to have core's validation engine running attached to a L2 signer inside a HSM
<t-bast> And it has to deal with both on-chain and off-chain, otherwise you can exploit channel close to steal funds
<ariard> just need a lot of refactoring
<roasbeef> t-bast: yeh at that point it's not really a HW wallet anymore, just some like "isolated" process somewhere 
<roasbeef> this kinda leads to "the LN impls is *in* the hardware wallet jajaja" 
<roasbeef> (yes we laugh in spanish now) 
<t-bast> haha yes, but if you want the HW to be useful, it has to implement a lot of lightning logic
<t-bast> if it's only securing your keys, it's not really securing your funds, it's easy to still exfiltrate funds by making it sign whatever
<ariard> really likely you need to rewrite a micro lightning state machine in your hardware-something
<roasbeef> yeh theoretically it could keep track of things like all pending htlcs to validate if something is a forawrd or payment, etc 
<roasbeef> create the oniion blob so it knows where the payment is actually going, etc, etc 
<ariard> if you're a routing node, just always incrase your balances, accounted holistically
<t-bast> isn't that what devrandom is doing with this project?
<ariard> roasbeef: you don't care where the payment is going if you're a routing
<ariard> if you're a sender get user input to authenticate the destination
<roasbeef> ariard: you do care that it's "balanced" tho, and not an attempt to send it all elsewhere 
<t-bast> always increase your balance doesn't work, as lightning nodes may lose money in case too many channels close and they don't collect enough routing fees
<roasbeef> i think we're saying the same thing tho 
<ariard> yes we're saying the same :)
<ariard> t-bast: yes we're have already landed few chunks in RL
<ariard> t-bast: this is a different problem IMO, the economic efficiency of your lighting operations
<ariard> your security cost shoud be part of your ops cost
<t-bast> yeah but that means your HW cannot use that as a protection to decide whether or not to sign txs
<t-bast> because it won't work as soon as you're not economically balanced
<t-bast> and if at that point your HW refuses to sign txs, you're even more screwed
<ariard> t-bast: in that case sign the txn, the not economically-balanced should have been evaluated at channel opening
<t-bast> still a lot of fun stuff to figure out xD
<ariard> okay have to go but was a good meeting, see you :)
<t-bast> I've gotta go, thank you guys for these discussions!
<t-bast> See you next time!
<t-bast> #endmeeting

@t-bast t-bast unpinned this issue Feb 2, 2021
@t-bast t-bast closed this as completed Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@t-bast