DanGould
commented
1 month ago Regarding the Multiparty Scenarios
It seems to me that Payment Cascade is a special case of the scenarios. Communication from A -> B -> C -> B -> A is serial and introduces no additional rounds of communication. In order for Bob and Carol to add input, you do note that the requirement for Carol would need relaxed requirements, since Bob cannot both add new signed inputs without invalidating Alice's input.
However, a narrow case of Payment Cascade is possible with a mere 'soft fork' (additional requirement) to the payjoin protocol, if you will. Bob may allocate some of his output paid from Alice in the Original PSBT to Carol, without adding any inputs, and pass the Original PSBT to Carol who may add inputs and alter Bob's payment output such that a Payjoin PSBT would satisfy Alice's payjoin checklist according to BIP 77.
Other than Payment Cascade, all of the scenarios appear to require more rounds of communication.
0xBEEFCAF3
nothingmuch
Multiparty cut through scenarios
The following are cut-through scenarios which are not supported in BIP 77, but might improve block space utilization and privacy.
In particular, privacy from counterparties could be obtained in a multiparty setting, since parties to a payment could avoid learning each others' inputs and outputs in principle, just not in the 2 party case which leaves no room for guessing.
Payment Cascade
Alice initiates a payjoin to Bob, who then initiates a payjoin to Carol.
In the current protocol, Bob couldn't take Alice's original PSBT, modify it to a payjoin PSBT, and then send that as his original PSBT to Carol, since he can't sign for Alice and original PSBTs must be fully signed.
Suppose it not problematic to accept unsigned original PSBTs. In that case there wouldn't be a problem for him to wait for Carol to respond with her payjoin PSBT, fill in the signatures for his own inputs and pass that to Alice as his own payjoin PSBT.
Payment Cycle
If Carol additionally wants to pay Alice in the same transaction, initiating a payjoin to Alice, an additional restriction is that she is not allowed to modify her own change output(s) from the first original payjoin, since for she is supposed to know those might be Carol's. This presents an an inefficiency and a privacy leak for Alice with respect to 3rd parties (not Carol).
Suppose this restriction was also lifted, Alice could reply to Carol with a payjoin PSBT with all her inputs signed, Carol would amend it with her signatures and finally Bob's signatures would complete the transaction, which he could still send as a payjoin PSBT to Alice to complete the interaction.
Note that this is a strawman, all parties learn that there was a payment cycle, and likely each others' output mappings, on top of the hypothetical relaxations to the protocol exposing clients to more privacy leaks.
Fan-in & Fan-out
On the other hand if Alice and Bob both initiate a payment to Carol, if she merges the two original PSBTs she can't sign Alice or Bob's inputs and therefore can't respond to either with a payjoin PSBT only missing signatures from one or the other, relaxing the specification would not suffice since an additional round of communications would be required.
The same basic argument precludes Alice initiating two concurrent payjoins to Bob and Carol and merging those transactions. In this case Alice could construct a payjoin with Bob, paying Carol, and send the final output as an original PSBT to Carol, but if Carol wishes to modify it then there is no way to ask Bob to sign again.
Towards a multiparty protocol
A (brittle) multiparty protocol can be built on top of a slightly modified directory.
Multiparty sessions can be created if either receiver or sender share in a payjoin shared the ephemeral private key with their direct counterparties. In the receiver's case this could be in response to an original PSBT, in the BIP 21 URI, using BIP 353 etc.
All parties who learn the key could then both read and write to/from the subdirectory, as well as invite others. This implies that such multiparty transactions only happen between economically proximate entities, which limits the quality/robustness of privacy, but is still an improvement.
To avoid introducing a concept of appending to subdirectories, after a subdirtory has been written to, its ID and the written value could be hashed to derive a new subdirectory key, but it would be more efficient to allow appending values.
Using such a subdirectory, parties could then unsigned TxIns and TxOuts in any order. Once finalized signatures can be added. By phasing TxIns and TxOuts, silent payments can be supported at the cost of an additional round of communication.
A multiparty protocol presents more possibilities for DoS, and liveness is not guaranteed, anyone who learns the session key could add superfluous TxOuts without even contributing inputs. This can be addressed by using BIP 322 ownership proofs to authenticate inputs (though not as strongly as BIP 77's original PSBTs), and homomorphic value commitments to enforce output integrity. Note that this is independent of DoS protection for the directory itself, which could be addressed by rate limiting using anonymous credentials.
Safety can be enforced by each participant only signing with all their inputs if all their requested outputs are present. To ensure duplicate TxOuts are properly accounted for and not accidentally spent as fees (e.g. when two users donate the same amount to the same static address), the message transcript hash can be the random seed in a shuffling of the outputs. A random permutation of 25 outputs has 83 bits of entropy, so even smaller transactions would provide reasonable assurances that all parties agree on the set of messages. Note that the transcript must either be the encrypted payloads, or the cleartext ones must contain idempotence IDs and for the shuffling to commit to those.
Parties will need to agree (a priori) on a reasonable (minimum) feerate, values for nlocktime & version, and any constraints on nSequence a priori, or restriction of allowed input types (e.g. to ensure a stable txid legacy inputs might be disallowed). Given that duplicate outputs can be detected, whether or not they should be merged can also be specified. The specific parameters governing such rules should be committed to by the session key.