-
Notifications
You must be signed in to change notification settings - Fork 374
Meeting Notes 2022 12 12
Elias Rohrer edited this page Jan 10, 2023
·
3 revisions
- 0.0.113 (https://github.com/lightningdevkit/rust-lightning/milestone/30)
- Last release of the year
- Everything that doesn’t have a PR are not big deals and will just slip
- 1890 is just release notes note, will deal w that in the release notes
- 2 have a PR and should be close, one’s just a docs change
- Looking good for this week. PRs that are open will land and we’ll call it a day
- 0.0.114 (https://github.com/lightningdevkit/rust-lightning/milestone/31)
- No particular theme. Would like to get a bunch of stuff in, like getting anchors public and offers public
- Want to land some big locking changes from Viktor as well
-
- big channel state machine rewrite from matt
- So probably will be a big release, logic-change-wise
- Developer support
- Not a ton here, conor at conference last week (focus for devs was largely about figuring out a path in open source bitcoin dev, and figuring out architecting wallets)
- Duncan: I had a chat with okjodom from Kenya and he’s working on some Fedimint stuff. Wants to look at routing with LDK. Keeping in touch with him.
- Payment protocols
- Offers invoice request landed!
- Refunds follow-up opened, seeking conceptual feedback
- Largest part: if you get an invoice, how do you k now if it came from an invreq vs a refund? Presence of the field is how that’s determined, but how we represent an invoice in those two cases is an open question
- Not huge to worry about right now, but will become more pressing when the invoices PR is open
- Async payments:
- Met with rusty/t-bast last week, nice to get consensus between everyone that we’re going to build on top of offers using keysend invoices (TODO(val) need a high-level writeup here)
- Everyone agrees the overall design is solid
- Val was going to work on prototyping, but after the meeting it seems like it’d be best to build on top of offers to avoid writing a lot of temporary code that would be thrown out
- Therefore, working on chipping away at the dependencies to get to a real async payments implementation for now. Atm, that means working on moving payment retries into channelmanager, which unblocks trampoline, which will allow sender’s LSPs to retry on behalf of senders, without which async payments are kinds useless
- Language bindings
- Arik: huge updates coming. Was able to rework the entire generator/parser and a bunch of major features such as camelcase method names and not having to deal w types that users should not be facing, + handling some memory issues we previously had undiagnosed, making sure mem is kept around when you’re passing an instance by a pointer. Also doc annotations fixed.
- Taproot support
- Arik has PR open
- One of the multi phasic steps towards TR, still have some broken tests to fix there. Should have those done later today and will switch it from draft
- Last week spec meeting – laolu said the nonce proposal is FTW, so that should be going forward. He wants to be ready to do interop testing by end of this month, we’ll see about that, would be great
- Some discussion regarding shutdown handling, but it’s minor and not really pertinent to the overall spec
- Anchor outputs
- Making good progress, landed 1825 last week
- Following that, there’s the PR wilmer currently has in draft, exposing the feature bit + allowing the actual channel open at ChanMan level
- Working on some tests, should be updating that today
- In the background, working on tx event handler. Still a bit unresolved, will reopen the discussion once wilmer gets back to it (tmrw/weds)
- Antoine also has been highlighting some issues to be addressed as well anchors-wise
- LSP
- VSS (Versioned Storage Provider)
- Gursharan: currently trying to close the model PR, hopefully this week
- Apart from that, tested e2e server impl w basic rust client that uses GET, PUT etc. currently working on client-side lib that will maintain all the versioning on the client side, so ldk or any other app doesn’t have to maintain versions against a certain key
- LDK Lite
- Some progress on LdkLite PRs
- Biggest progress: tx sync crate, also made some progress and should be pretty stable currently. Opened a PR to esplora server component that adds some more data fields to one API call that should ensure that there are no race conditions during sync w/ a reorg, so that hopefully will be reviewed sometime, otherwise will ping someone there
- Otherwise, implemented the first e2e test on LdkLite against a local esplora regtest. Seems to work!
- Dual funding channels (new)
- 1794 is open for comment
- VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
- Devrandom: continuing to work on our MVP milestones. Going to put up a roadmap on our website explaining what that entails
- Also involved in security audit being done by a 3rd party
- going to have a couple of announcements coming up
- Ken: past couple weeks, working on pre-approve invoice and pre-approve keysend APIs upstream into CLN. so those are ways for the node to check that an invoice/keysend will be OK in a good soft failure environment, so easy to fail if they exceed a velocity control.
- In ldk, looking forward to helping out testing bolt12 code. We should be ready to parse invoices, etc, so should be able to flush out any early issues.
- Sensei (https://github.com/L2-Technology/sensei)
- Synonym (https://github.com/synonymdev/ldk-node-js)
- Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
- Shamardy: everything’s good. Was working on failed swap payment refunds. Seems like the backgroundprocessor wouldn’t work for web, so working for that. Also looking to use offers in the future. Right now don’t need anything.
- Tony: mutiny has a background processor fork that works on wasm web https://github.com/BitcoinDevShop/mutiny-web-poc/blob/master/node-manager/src/background.rs
- (not pretty and needs to be cleaned up but it works)
- Shamardy: will check it out
- Lexe
- Working thru funding flows with 0-conf
- Looking forward to val’s HTLC interception work getting released, + bdk wallet that replaces the bitcoind wallet that comes w ldk sample
- One thing we’ve been waiting on is async event handling. Been a while since i looked at that, but we tried to use the api that was exposed and didn’t work for us. Can follow up after i refresh on that.
- Matt: i know there were issues with the futures stuff we landed in 0.0.111, some things to get done here still
- Jeff: 1787 was merged a while back, that should be in the next release coming out
- Max: hoping the api would be some what similar to channelmonitor persist api, where you can return a TemporaryFailure and later update that the event was handled. Bc right now there’s a semantic where you need to return from the async method after you handle the event, which isn’t acceptable for us bc it blocks our entire single-threaded program.
- Matt: in 113, not the same semantics, more native rust features optionally for handling events. (not some of the other persistence stuff). Not gonna support bindings for that in today’s version, so far no requests for that. We have a future struct we can expose for bindings that we use for other stuff, could use that here but we just haven’t yet
- 2022/12/05 (https://github.com/lightning/bolts/issues/1046)
- Nothing pressing here
- Channel jamming call is 2 hours from now
- review begs?