Open dunxen opened 2 years ago
Thinking through LSP onboarding strategies having the ability to start with a balanced channel is a really nice option. Definitely watching this one 👀
I think one of the first step could be to make OnchainTxHandler
its own interface that way the reorg/fee-bumping/rebroadcast logic could be shared between our ChannelMonitor
and MultipartyConstruction
stuff. See : https://github.com/lightningdevkit/rust-lightning/issues/606#issuecomment-619338323 for ideas.
There is also an open question on how much code for doing that is already available in BDK.
I think one of the first step could be to make
OnchainTxHandler
its own interface that way the reorg/fee-bumping/rebroadcast logic could be shared between ourChannelMonitor
andMultipartyConstruction
stuff. See : #606 (comment) for ideas.There is also an open question on how much code for doing that is already available in BDK.
Thanks for the comment link! I'll sync up with the BDK peeps on that open question too.
Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.
Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.
Great, picking up refactor next! 🙏
Available to review advances in dual-funded implementation, even if it's early refactor for now. I've reviewed back recently the state of the BOLT proposal and it's sounds to be mature enough to solidify around a v0.1.
Great, picking up refactor next! pray
Next is now. So picking up from now :)
Good to have this, don’t hesitate to “review pin” like glozow doing for package relay: https://github.com/bitcoin/bitcoin/issues/27463#issue-1668056618 good practice imho to allocate review bandwidth accordingly.
FYI, current version of nversion=3 and package RBF sounds working well for both dual-funding and splicing: https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1712350787
There is one caveat where the first splicing transaction transitioning from nversion=2 to nversion=3 might have to be signed with a compelling feerate to be able to replace a pinning nversion=2 commitment state. If correct, I think it can be documented when nversion=3 is specified on the bolt-side.
All reserves kept as both package relay / nversion=3 / dual-funding and splicing are still work in progress and non-final.
Hi, what is the status here?
Does LDK support dual-funding, and if it does, how? Thanks.
Dual-funding and splicing in LDK is still a WIP, but hopefully coming soon.
Ok, thanks. I will stay tuned here.
If there is another place I can follow along for early releases / and or testing please let me know.
@optout21 I'm struggling to also assign you to this issue. Not sure if you can also assign yourself? :)
UPDATED Here's my take on splicing tasks:
Updated splice tasks (in earlier comment)
Updated splice tasks (in earlier comment)
Thanks! Updated!
I updated the quiescence section based on a discussion with @wpaulino.
Overview
Project tracking and implementation status of interactive transaction construction, dual-funding (V2 channel establishment), channel quiescence, and splicing.
Specifications:
Wire messages
1794
2253
2542
Interactive Transaction Construction
2419
2989
3281 (depends on #3137)
Dual-funding (V2 channel establishment)
0. Refactoring
2077
2382
1. Accept dual-funded channels
3137
3416
2. Accept dual-funded channels with RBF
3281
3. Create & accept dual-funded channels
1571
2302 (depends on #3137)
Dual-funding implementation phase feature table
Channel quiescence
2933
Splicing
Prototype
3274 (depends on #2302)
0. Preparations
3295
3317 (#3300 )
3316 (#3312 )
3332
1. Basic implementation
3298
3407
2. Additional features