-
Notifications
You must be signed in to change notification settings - Fork 367
Meeting Notes 2022 09 19
Elias Rohrer edited this page Sep 19, 2022
·
1 revision
- 0.0.111 (https://github.com/lightningdevkit/rust-lightning/milestone/28)
- It’s out! Bindings coming soon
- 0.0.112 (https://github.com/lightningdevkit/rust-lightning/milestone/29)
- Let us know if there’s anything you want in it, prob gonna have offers stuff
-
Developer support
- Likely something with rapid gossip sync for the tabconf workshop
- Also gonna have a builder day
-
Payment protocols
- Onion messages are public and forwardable in LDK as of 0.0.111! Yay!
- Waiting on MPP feature bit resolution for offer encoding
- Offers encoding PRs are chugging along in review
- Progress on OM pathfinding for reply paths, etc
- Offers OM handling side isn’t there yet, looking at it on top of encoding PRs to identify blockers/groundwork PRs May be some smaller issues available if other contributors want to get involved
-
Language bindings
- Matt had to do some work here to get them to work for 0.0.111
- Bluewallet had some startup issues that arik is looking into
-
Taproot support
- Arik pairing w wpaulino, quite dependent on figuring out final versions of the actual taproot bolt which is changing and still not compatible with other parts of lightning due to overlap in flag usage, but it seems to be partially working. We’ve got funding channel open, funding txs up, musig aggregate sigs, all of that fully working and tests passing and we’re just moving forwards to getting the entire commitment tx/htlcs also fully converted. I hope we’ll have sth demonstrable soon
- Flag overlap = feature bit overlap = draft bolt still using byte flags 50/51 for simple taproot, and that is conflicting with 0conf feature bit
- Arik pairing w wpaulino, quite dependent on figuring out final versions of the actual taproot bolt which is changing and still not compatible with other parts of lightning due to overlap in flag usage, but it seems to be partially working. We’ve got funding channel open, funding txs up, musig aggregate sigs, all of that fully working and tests passing and we’re just moving forwards to getting the entire commitment tx/htlcs also fully converted. I hope we’ll have sth demonstrable soon
-
Anchor outputs
- Wilmer contributed more test vectors for the spec, got some acks and waiting on merge
- 1 PR up waiting on concept acks before putting up remaining changes. Think i received 1 from ariard on friday, will prob move forward with that
- Next PR will be a similar event to expose for the htlcs on the commit tx. If they can be aggregated, you’ll receive an event for that aggregated set
- Ariard: would be nice to have a 3rd reviewer after matt/myself, to make sure it’s all right
- There was a review club session on anchors last week if people wanna check that out in #review-club discord / ldk.reviews
-
LSP
- John carvalho: similar state to last meeting. We’re hashing out what specs we wanna do for the marketplace aspect, bringing up some bikeshedding ofc but i think we’re close to a first version (simple). Need to explore who’s actually gnna use this and how it’s gonna be implemented, been debating how this relates to pool, magma, liquidity ads, etc, and liquidity ads has some new designs they’re proposing for fee cards. Lots subtleties here, so not sure where things will land, but at least the engineers will know where people from the market are thinking in terms of spec. First version should be done in next meeting or so. We do have the channel_request spec done from prev session, w JIT channel stuff. As a company we’re focused on shipping our mobile app at the end of october so havent updated our lsp to use that spec yet, but will get to that in the winter
-
WSP (Wallet Storage Provider)
- Gursharan: after multiple discussions w the team, we’re close to a complete design on how to structure the storage and how we’ll be modeling the chanmon/chanman storage. Also synced w devrandom on friday for how VLS can use the storage service. I think we are aligned that we’ll be building a common storage service that both VLS and LDK can use. Currently figuring out whether to start on ldk side from client side POV to get this rolling
-
LDK Lite
- Good progress here
- Looking at bindings and how that’ll work now
- Lots of PRs open
- Everybody invited to review
- Steve: raised topic in discord about whether we should be thinking about diff use cases and configurations. To date this has been mobile-focused, but i’d be interested in if we wanna focus on the lsp use case, or other. How hard would it be to switch out diff parts/make it customizable for these?
- J: v1 has bdk built into it, not customizable.
- E: tricky q of whether we want to make it configurable for diff setups. I fear that when we open everything up and make it all configurable, we lose hte “Lite” part and it gets the same interface as ldk cuz we need all these features. Ofc we want some configurability of modules, but q would be what are the specific requirements – e.g. in lsp use case, what kind of params or diff behavior is needed in the api? Maybe ldklite is a good starting point for that, and maybe it goes a long way, but not sure if we discover quite different reqs from mobile that it becomes not-lightweight anymore
- Steve: 100% agreed we need to be strict on the lightweight part, …
- Ariard: enterprise may be a diff api/direction
- Gursharan: regarding steve’s q of whether we’ll need diff defaults/api – current api is built modularly, could technically plug in a diff impl of storage and enterprise org
- E: maybe we could have different “features” to switch on in LdkLite for different use cases
- V: i'm scared that when people are asked to switch to full Ldk they'll feel like they're now just maintaining an LdkLite fork
- VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
- Devrandom: working on storage server geared towards VLS requirements. I met with gursharan about potentially getting to a single design that works for both ldk and vls
- Ken: working on invoice approval mechanism, better to fail on invoice creation than on payment itself
- Umbrel Tony working on fork for privacy(?)
- Sensei (https://github.com/L2-Technology/sensei)
- Synonym (https://github.com/synonymdev/ldk-node-js)
- John carvalho: Not too much new, still implementing ldk mobile in upcoming wallet. Making good progress on regtest, hopefully mainnet soon. It’s WIP. the ldknode is open source
- The project for doing the full node is gonna be paused for a while, the dev working on it is no longer w the company so prob won’t pick that back up til the current wallet app
- No requests for the ldk team at the moment
- John carvalho: Not too much new, still implementing ldk mobile in upcoming wallet. Making good progress on regtest, hopefully mainnet soon. It’s WIP. the ldknode is open source
- 2022/08/29 (https://github.com/lightning/bolts/issues/1019)
- 2022/09/12 (https://github.com/lightning/bolts/issues/1024)
- Dual funding:
- Ariard: reviewed this recently
- Discussion on the mailing list on splicing and dual funding. Still not sure if it’s the right approach for anchor
- Channel jamming
- Lots of blinded route, onion message routing, offers discussion
- Heated discussion on whether mpp feature bit is gonna be in offers, so we can continue to support phantom invoices
- Dual funding:
- May be good to wait for matt here
- review begs?