You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we don't follow user feedback we will never know what they want! This is a sprint to their feedback. Let's define exactly what that means
☑ Proof of Concept
Our PoC(s) already exists. We can open a scheduled channel via lightning interaction (loptos). We can host payjoin receiving server from iOS. Epic channel funding.
Think of the utility of Pay-to-Endpoint first PayJoin is CoinJoin functionality built on top of the P2EP interaction.
The minimum quantum of usefulness we can reliably deliver seems to be channel opens from BTCPayServer's internal wallet to their Lightning LND/CLN node. I think [Voltage(https://voltage.cloud/)] is the most popular way to do LN. Say a merchant made some bitcoins and wants to cash out KYC-free to thebitcoincompany.com's lightning only visa cards. They have to open a channel. Users ask for it
Typically, they'd move funds from BTCPay On-Chain -> LND On Chain ->, request their LN peer's channel ID, then Open a channel to them. Instead, the first step can be asking that peer for a channel ID, Queueing a channel open to them, and then spend funds directly from BTCPay On-Chain to LND Channel.
This seems to me to be the minimum stable quantum of value we can offer even before privacy preserving. It's strictly better than the first flow. I especially think e.g. Cash app will be interested in this because it's purely p2p and already in rust
CLI interface
a package / name that Chaincase ships
LND Setup ("loptos")
Depends on github.com/kixunil/payjoin
90% crash-free PayJoin Receiver: error handling and fallbacks in payjoin receiver
even though it doesn't crash, many errors aren't propagated into the UI. this is ok for alpha but not beta
Because the above alpha protocol is input substitution only and has no regard for receiver coin selection it's simple to deploy. However, CoinJoin has the added benefit of defeating common input ownership heuristic
stretch: fee to get outside Chaincase inputs to avoid UIH via 3rd payjoin participant
☐ Production Batching Beast: ship with btcpayserver, umbrel, passport, blue wallet receiver
Semver all dependencies so we can upload to crates.io for cargo install
Delightful channel opening scheduler GUI
Receiver running on lightning node in < 5 minutes (Umbrel)
Stretch: Integrated GUI: Ride the Lightning, ThunderHub, an externally connected Lightning GUI (Zeus, Zap, Spark, etc) supports us
open Taproot channels
After we have complete spec support thoroughly tested we will release into the stores without any beta label. Increments from here will continue to be driven from user feedback.
The text was updated successfully, but these errors were encountered:
Chaincase Lightning PayJoin Roadmap
If we don't follow user feedback we will never know what they want! This is a sprint to their feedback. Let's define exactly what that means
☑ Proof of Concept
Our PoC(s) already exists. We can open a scheduled channel via lightning interaction (loptos). We can host payjoin receiving server from iOS. Epic channel funding.
☑ Alpha: Minimum Viable P2EP
Think of the utility of Pay-to-Endpoint first PayJoin is CoinJoin functionality built on top of the P2EP interaction.
The minimum quantum of usefulness we can reliably deliver seems to be channel opens from BTCPayServer's internal wallet to their Lightning LND/CLN node. I think [Voltage(https://voltage.cloud/)] is the most popular way to do LN. Say a merchant made some bitcoins and wants to cash out KYC-free to thebitcoincompany.com's lightning only visa cards. They have to open a channel. Users ask for it
Typically, they'd move funds from BTCPay On-Chain -> LND On Chain ->, request their LN peer's channel ID, then Open a channel to them. Instead, the first step can be asking that peer for a channel ID, Queueing a channel open to them, and then spend funds directly from BTCPay On-Chain to LND Channel.
This seems to me to be the minimum stable quantum of value we can offer even before privacy preserving. It's strictly better than the first flow. I especially think e.g. Cash app will be interested in this because it's purely p2p and already in rust
☐ Beta PayJoin: We're preserving privacy now
Because the above alpha protocol is input substitution only and has no regard for receiver coin selection it's simple to deploy. However, CoinJoin has the added benefit of defeating common input ownership heuristic
ApiError
on non-SUCCESS HTTP response instead of panic. from Reorganise and refactor repository to prepare for integration testing. #10☐ Production Batching Beast: ship with btcpayserver, umbrel, passport, blue wallet receiver
cargo install
After we have complete spec support thoroughly tested we will release into the stores without any beta label. Increments from here will continue to be driven from user feedback.
The text was updated successfully, but these errors were encountered: