Split Modules from main function #17
Conversation
|
4403560 Passes (manual) smoke/integration test ✅ Each commit should be linted ( |
DanGould
changed the title
|
819ad8a integration tested ✅ please review for design |
| }; | ||
| let body = req.into_body(); | ||
| let bytes = hyper::body::to_bytes(body).await?; | ||
| dbg!(&bytes); // this is correct by my accounts |
There was a problem hiding this comment.
Nit: dbg! usage doesn't need to be on a separate line.
| #[derive(Clone)] | ||
| pub struct Scheduler { | ||
| lnd: LndClient, | ||
| pjs: Arc<Mutex<HashMap<Script, ScheduledPayJoin>>>, // payjoins mapped by owned `scriptPubKey`s |
There was a problem hiding this comment.
I don't like the idea of ScheduledPayJoin. We should just have a list of channels we want to open (funding amount + node we want to open with). And when payjoin requests come, we check the amount, and determine if it is enough to open a channel (or multiple), by looking at our list of "scheduled channels".
Maybe this is out of scope of this PR (since this is just a refactor so the codebase becomes more maintainable), but I think this would be a decent change.
There was a problem hiding this comment.
How do you determine the amount to put in the bip21? Just allow it to be arbitrary?
There was a problem hiding this comment.
So we would have 2 admin endpoints: add scheduled channel, add bip-21 request.
"Add bip-21 request" will add to a map that associates recipient (owned) scriptPubKey to "payment constraints" (i.e. minimum acceptable amount, maximum acceptable amount, etc.) so when we receive a payment, we know whether we have requested it, and whether the payment satisfies requested amount.
Now when we actually receive a payment request (via an incoming bip-078 original psbt), we check:
- Whether the psbt contains outputs that match our recipient
scriptPubKeys. If one or more do, we need to ensure that the outputs that match satisfy the value constraints. If not, we need to reject the payment (I'm not sure how this is usually done). If we deem the outputs okay, continue to 2. - We need to check if the original psbt actually creates a valid tx (because this is our fallback in case we fail payjoin).
- We sum up the values of "owned" outputs of the psbt. This is the max value we can work with when opening channels. We check how many scheduled channels we can open given this value.
- We initiate opens of these picked scheduled channels and create proposal psbt that we send back to sender.
| let (owned_vout, pj) = | ||
| self.find_matching_payjoin(&original_psbt).ok_or(SchedulerError::NoMatchingPayJoin)?; | ||
|
|
||
| // FIXME does this need to go before find_matching_payjoin(...) ? |
There was a problem hiding this comment.
+1 this can go later to reduce unnecessary processing.
Co-authored-by: 志宇 <[email protected]>
Co-authored-by: 志宇 <[email protected]>
Co-authored-by: 志宇 <[email protected]>
Co-authored-by: 志宇 <[email protected]>
DanGould
force-pushed
the
split-scheduler
branch
from
819ad8a to
2b5e4f1
Compare
|
Tested ✅ rebased with cargo +fmt in between and credit to Evan for developing the concepts from scratch to draft |
1st commit: split rpc request creation from the now-async call. Integration Tested ✅
this PR splits scheduler and http as mods so that main is much more manageable