Jit channels clean#20
Conversation
johncantrell97
force-pushed
the
jit-channels-clean
branch
from
43102d9 to
5634d6e
Compare
|
This needs a rebase. |
johncantrell97
force-pushed
the
jit-channels-clean
branch
2 times, most recently
from
f28ea02 to
00fa488
Compare
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Started a thorough pass, still have to take a closer look at message handler commit and following.
| { | ||
| entropy_source: ES, | ||
| peer_manager: Mutex<Option<Arc<PeerManager<Descriptor, CM, RM, OM, L, CMH, NS>>>>, | ||
| channel_manager: Arc<ChannelManager<M, T, ES, NS, SP, F, R, L>>, |
There was a problem hiding this comment.
Since LDK 0.0.117, we can use the AChannelManager trait here now.
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Completed the pass.
Looks pretty good to me, but I have yet to do another pass comparing the logic once more to the spec.
johncantrell97
force-pushed
the
jit-channels-clean
branch
2 times, most recently
from
301174e to
dc72629
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
3 times, most recently
from
bf7e14b to
6291be8
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
from
6291be8 to
a334959
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
from
a334959 to
8a61a5e
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
from
8791c15 to
05ea541
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
5 times, most recently
from
278e730 to
f03a1aa
Compare
johncantrell97
force-pushed
the
jit-channels-clean
branch
from
f03a1aa to
646d54f
Compare
| per_peer_state: RwLock<HashMap<PublicKey, Mutex<PeerState>>>, | ||
| peer_by_scid: RwLock<HashMap<u64, PublicKey>>, | ||
| promise_secret: [u8; 32], | ||
| min_payment_size_msat: u64, |
There was a problem hiding this comment.
Will probably need all of the config options, so might be worth holding a JitChannelConfig here?
| } | ||
|
|
||
| impl RawOpeningFeeParams { | ||
| pub(crate) fn into_opening_fee_params(self, promise_secret: &[u8; 32]) -> OpeningFeeParams { |
There was a problem hiding this comment.
Still would be nice to have this be a util method analogous to is_valid_opening_fee (could also DRY this one up then) to keep LSP-specific logic separate from the messaging/type serialization.
Happy to have that happen in a follow-up though.
There was a problem hiding this comment.
Now tracking here: https://github.com/lightningdevkit/ldk-lsp-client/issues/30
|
|
||
| bitcoin = "0.29.0" | ||
|
|
||
| chrono = { version = "0.4", default-features = false, features = ["std", "serde"] } |
There was a problem hiding this comment.
Seems we don't actually require full std here, alloc should be enough.
| } | ||
|
|
||
| /// Configuration options for JIT channels. | ||
| pub struct JITChannelsConfig { |
There was a problem hiding this comment.
This probably should be renamed OutboundJitChannelConfig or LSPS2OutboundChannelConfig and get moved to the jit_channel/lsps2 module.
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Alright. I had another look at the spec and poked around a bit more.
While nothing in particular stood out, we'll def. want want to increase our input validation, error handling and test coverage going forward, i.e., before this is deemed stable and usable in production.
I had some minor comments which however can be addressed as follow ups. To this end, and to generally track next steps, I now opened a bunch of issues.
That said, for now, I'm merging this first draft 🎉
2 participants
This implements LSPS2: JIT Channels on top of LSPS0 transport layer.