-
Notifications
You must be signed in to change notification settings - Fork 371
Meeting Notes 2023 01 23
Elias Rohrer edited this page Jan 23, 2023
·
1 revision
- 0.0.113 (https://github.com/lightningdevkit/rust-lightning/milestone/30)
- 0.0.114 (https://github.com/lightningdevkit/rust-lightning/milestone/31)
- Closing in on PRs we want included here
- Would like to get that close to out basically end of this week (Val's work for chanman retries will take longer than that) -> nice to get the other items in this week
- Async channelmonitor seeking code review
- 0.1 (https://github.com/lightningdevkit/rust-lightning/milestone/1)
- Developer support
- Payment protocols
- Async payments
- Hoping to open all the channelmanager retry PRs soon and garner review over the next couple weeks
- Offers
- Jeff has a fuzzing PR out
- Working on stateless offers, should be trivial
- Async payments
- Language bindings
- Adapting to the latest bindings may be annoying due to change to camelCase and other changes
- Taproot support
- Taproot depends on anchors so we've been making progress on that
- We had the open channel support merged last week (nothing exposed yet til the full patchset is merged)
- Taproot itself: we've been making a set of refactorings in LDK. had a couple merged last week. Getting close to working on taproot signer, since we're introducing a new TaprootSigner trait, that the InMemorySigner will be implementing. Will be something that VLS needs to do.
- Spec front: no major updates
- Waiting on LND to do some interop and have some PRs to review at the spec level, but nothing major
- Anchor outputs
- LSP
- Updated original ChannelRequest spec to add some granular states
- Deezy.io has implemented the spec. we (Synonym) will proceed with implementing it as well in a few weeks and encouraging breez as well
- VSS (Versioned Storage Service)
- PR for impl of get & put with postgres based impl is up. That contains the logic for optimistic locking and global versioning
- Needs approach review, then will write tests
- PR for impl of get & put with postgres based impl is up. That contains the logic for optimistic locking and global versioning
- LDK Node
- Good progress, merged event handling PR
- Wallet PR is getting close as well as tx sync against esplora
- Jeff to review
- Dual funding channels
- Splicing (new)
- VLS (https://gitlab.com/lightning-signer/validating-lightning-signer)
- Had a security audit by ariard, posted on the mailing list
- Targeting March for first milestone completion
- Tracking LDK, caught up to 0.0.113, and looking forward to 0.0.114 due to some changes that simplify our code
- Sensei (https://github.com/L2-Technology/sensei)
- Synonym (https://github.com/synonymdev/ldk-node-js)
- Jay: been getting crashes with 0.0.112, going to focus on upgrading to 0.0.113, then will re-test everything and send logs
- Also noticed that the gossip server is about 40 hours out of date, when it should be updated every 24 hours
- Matt to investigate
- Matt: "Ah, i believe the gossip sync server being stale was a cron-time-mismatch error across servers (so it was always between 17 and 17+24 hours old). In the future it soulshould be no more than 25 hours old)"
- Relevant issue: https://github.com/lightningdevkit/rust-lightning/issues/1646
- Also noticed that the gossip server is about 40 hours out of date, when it should be updated every 24 hours
- Jay: been getting crashes with 0.0.112, going to focus on upgrading to 0.0.113, then will re-test everything and send logs
- Komodo DEX (https://github.com/KomodoPlatform/atomicDEX-API)
- 2023/01/16 (https://github.com/lightning/bolts/issues/1050)
- Inbound fees discussion. There was no conclusion in the meeting, so presumably it will show up again in future meetings
- BitcoinZavior: been dabbling with LDK recently. Such as bundling LDK Node in rust and bundling it as a flutter package (been coordinating with tnull on this). I've shared this package in the LDK Node channel and some people have tried it
- The architecture i'm using for this is very similar to BDK Flutter, which is starting to be adopted
- Not using the binaries produced as output of ffi project. That's the architecture used by most flutter packages. It's bc we have the rust code, and for flutter there is the flutter-rust bridge, which lately has become quite good
- So it has the same api as LDK Node in rust
- Major issue is that a lot of wrapper code is needed.
- Measured perf of different approaches to bindings - For react-native, prefer swift/android binaries. For flutter, prefer to use the rust interface directly.
- The architecture i'm using for this is very similar to BDK Flutter, which is starting to be adopted
- review begs?