Payjoins #1764
Replies: 4 comments
-
In payjoin protocols the recipient of a transaction appends an input and outputs to a transaction in order to disrupt the "common input heuristic" and gain more privacy. Currently our support for the payjoins won't be great because all out UTXOs are k/n P2WSH. So you'd only be able to do payjoins with users who had similar UTXOs. But after we have a Taproot on-chain wallet, then our k/n multisig UTXOs would look like any other taproot inputs so long as we sign them in the signature aggregation way (think that's called "key path spend"?). |
Beta Was this translation helpful? Give feedback.
-
Payjoin is one of many ways to append bytes to the blockchain such that sats are transferred at the same time that utxos are merged. This preserves user privacy and, can be used to consolidate utxos in the same transaction. Doing so during times of low fees can save absolute fee expenditure. Payjoins would help to keep the line between coins that are inside or outside of a mint blurred and prevent mints and mint users from being censored. Regarding Mixed InputsMore software is supporting mixed-input spends, so this might not be a huge privacy problem. There is a proposal to allow it in bip78 too. Taproot would get rid of the mixed input problem entirely. That might be a better solution. Send sats out of a Fedimint via payjoinSending payjoin requires signing two PSBTs within a time window of a minute or so. How can a mint deliver two rounds of signatures? Maybe using the lightning gateway would be the easiest way to delegate this signing. BIP21 unified payment uri includes parameters for sending payjoins. The protocol involves two rounds of signing for a sender: Upon receipt of the uri, the sender constructs a typical transaction funding the bitcoin address supplied in the bip21 as fallback if the payjoin fails. They send it over http and wait for a response. The recipient responds with an augmented a payjoin PSBT that includes their input. Since it has changed, the sender needs to sign this altered PSBT and broadcast it. Receiving sats into a Fedimint via payjoinReceiving payjoin requires hosting a secure endpoint, contributing a utxo to consolidate, and signing one payjoin proposal PSBT of incoming sats. When and how to authorize fedimint signatures is my biggest open question about this deployment. I'm curious what the constraints are. |
Beta Was this translation helpful? Give feedback.
-
Discord context:
Per #3264 I think a payjoin UTXO Gateway (UG) could make sense. This could remove the concern of pinning attacks or general muddling with the core ecash backing UTXO set while also offering fedimint users a more private way to enter into a federation. Similar to how a LN gateway can be either CLN or LND (or others), a UTXO gateway could server different purposes at a functional level.
|
Beta Was this translation helpful? Give feedback.
-
I've responded to some of these legitimate concerns regarding payjoin receivers on Discord and would like to add them here for future discussion. Fortunately, I believe they are all being addressed in implementation already. All of the attacks described have automated defenses.
Implementing payjoin peg-ins only creates the opportunity to use potentially many of their UTXOs as input, not a requirement. Depending on the liquidity constraints, I recommend a federation only add payjoin input while it already has peg-outs queued. In doing so it can fund the peg-outs using the incoming payjoin sender's UTXO in addition to the settled, internal UTXOs via output substitution. In doing so it has a chance to never be encumbered by the fees of that peg-in UTXO. Funds would flow directly from a peg-in to a peg-out in a single batched transaction. Payjoin therefore effectively gives the federation more liquidity. This kind of combined peg-in peg-out payjoin batching is being developed in Galoy's batching service bria to take advantage of the opportunity it presents to more effectively manage UTXOs, scale bitcoin, and save fees.
True. If a federation contributed input to any incoming transaction without regard to fee rate it could get stuck. Fortunately fee rate negotiation is part of the payjoin specification and implemented in Payjoin Dev Kit. Senders typically pay for both sender and receiver input to incentivize an outcome of better privacy. Fees are negotiated automatically based on peer preferences when the protocol runs and fall back to transactions funded entirely by the sender if negotiation fails. A federation payjoin receiver would only ever sign transactions that were in its benefit to do so. If a peg-in transaction were proposed with too low a fee rate, then the federation can automatically choose not to contribute any inputs to construct a payjoin. Instead, it would proceed with a peg-in funded only with external UTXOs as it does today by broadcasting the "original psbt" fallback. In an unlikely emergency situation where a transaction did get stuck even after successful fee negotiation, a beneficial UTXO owner, fedimint or client, could always bump the fee using CPFP. Payjoin trades non-interactive simplicity for some interactive complexity to gain in the ability to batch transaction intents. Just like fedimint makes that interactivity tradeoff to gain federated custody. If interaction fails, payjoin receivers can always fall back on non-interactive transaction construction. I am aware of no situation where Payjoin puts receivers in a position where they sign transactions they would not otherwise voluntarily sign. |
Beta Was this translation helpful? Give feedback.
-
TODO
Beta Was this translation helpful? Give feedback.
All reactions