chaincase-app
WIP: receive payjoin
🔥🔥🔥🔥🔥🔥 considering send & receive are independent functions perhaps we can split them into 2 prs?
I think that PR could effectively be separated and reviewed as hidden service, PayJoin Controller on top of that, and UI on top of both.
See the hidden service and P2EPServer portions refactored. DesktopTorManager throws on hidden service controls, so controls must be implemented or otherwise handled in the UI.
Server lifecycle, UI, and P2EPRequestHandler remain. The RequestHandler ought to consider #259 and use BtcPayServer.BIP78.Receiver. Separate derivation of and authorization to use key material dependencies from BIP78 psbt construction & negotiation will let us unit test each component.
Oops this pr lost some history. I thought github would keep @armins88's history for reference while we worked on the substeps when I force pushed. Armin, can you push your original changes to another branch for reference? Otherwise we can just look at onion78.
https://github.com/btcpayserver/BTCPayServer.BIP78 It does not seem like the best choice for receive after a deep dive. There's also no reference implementation. The library is not yet used in BtcPayServer, and the abstractions are a bit too opinionated about the receiver being what the spec describes as a "non-interactive" (payment-processor like) endpoint. Our own implementation, even based on that lib, can help us take the lead by defining the sdk.
Our latest claim to fame is being the first reference implementation of https://github.com/btcpayserver/BTCPayServer.BIP78/tree/master/BIP78.Receiver. Of course being the first mean I found the missing pieces. The lib is missing proper spec-defined http responses, The way the Context object gets passed around isn't as functional/declarative/static/testable as I'd like it to be yet. And this first go didn't decouple the receiver from Chaincase's KeyManager yet either.
Password-in-memory ought to be swapped out in favor of spendable coins. Maybe our PayJoinReceiverWallet Initiate should include spendable coins along with the proposal context. Those spendableCoins can come from a ChaincaseWalletManager helper function. PayJoinReceiverWallet must be decoupled from Chaincase's wallet implementation so it can be SDK-ified. Those spendable coins MUST be disposed from memory when the receiver chooses to shut down, too.
In addition, UI remains
upgraded NBitcoin > v6 to support BtcPayServer.BIP78. to be merged via pull request #261