alexbosworth
commented
7 months ago Instead of request_info / buy_channel / check_order for bos get-inbound-channel
I think it could be --dryrun or --recovery <orderId> if you want to only request info or only check an existing flow. This would be consistent with the other commands where you interact with a service and it would leave the command execution itself with the possibility of just working with minimal input
--amount could default to 5mm, that is consistent with open
--priority could be --max-expected-wait-hours and then convert hours to blocks like hours * 6, default to 48 hours. Blocks isn't possible to guarantee, especially at the low end, so let's not give this impression
--pubkey can be the argument: so bos get-inbound-channel 023049203498 - this signals that it's a required option
bos offer-channel-open seems good if it doesn't require any arguments
--fee-rate could be --capacity-fee-rate to distinguish it from the channel fee rate, otherwise it may be confusing
--max-capacity, --min-capacity should be a number, can change to string for the wire protocol
--min-onchain-payment-size I don't see why this is necessary, can omit it
One thing I'm thinking about is like if you can make something in memory when there is a request, is that a DoS vector? Instead maybe it could just not register anything in memory until payment is apparent? Didn't go super deep on that to confirm what's happening there though
niteshbalusu11
Signed-off-by: Nitesh Balusu 84944042+niteshbalusu11@users.noreply.github.com
This is an implementation of LSPS0 and LSPS1 for both client and server.
https://github.com/BitcoinAndLightningLayerSpecs/lsp/blob/main/LSPS1/README.md
I did not add code comments yet expecting changes, please review the code and let me know and I can add comments at the end.