BIP-322 Directory Ids and coalition formation

[0xBEEFCAF3]

The Goal

We aim to build a multi-party protocol that utilizes the directory structure to facilitate coalition formation. Privacy peers need to find counterparties to engage in a group PayJoin transaction. However, to prevent peers from joining a session without owning a UTXO, we require proof of ownership. The simplest way to achieve this is by using a BIP-322 proof.

BIP-322 Proofs

BIP-322 defines a standard for proving UTXO ownership. Specifically:

"A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications."

In short, BIP-322 proofs involve creating signed transactions spending a set of UTXOs to an OP_RETURN output. While BIP-322 proofs verify ownership of a private key, they do not confirm that the UTXO exists on-chain. Verifying these proofs requires access to a blockchain data source and the current UTXO set.

The proof consists of a message m = tx (the transaction) and a signature sig = "signed tx sighash using SIGHASH_ALL".

Keeping Directory IDs Uniform

One of our objectives is to keep directory entries indistinguishable from one another. Peers can generate their ID by hashing their BIP-322 signatures (S = set of signatures) and an Elligator2-encoded x-only public key (P). The public key P will later be used for pairwise encrypted authentication between privacy peers. The components S, P, and the outpoints used to generate S must be presented in the BIP-21 URL. There is a concern of data payload size here. There may be a scheme to chunk the BIP-322 proofs. But we can cover that later.

Once the BIP-322 proof is received and validated, users can utilize P to generate pairwise public keys for communication or encryption in the multi-party protocol.

Providing Directory ID to Peers

This section is to be determined (TBD) but will outline how peers share their directory ID with others.

Excluding Certain Input Types

UTXOs that require additional multi-party protocols to spend are problematic for multi-party PayJoin. Therefore, a default set of input types should be excluded from the coalition formation protocol. For example, inputs like p{w}2sh(multi(...)) should be rejected. There will be some cases involving scriptless scripts that are undetectable, and if such an input causes an issue, it could halt the entire PayJoin session. Although there are limits to ensuring protocol success regarding input types (musig keys), excluding specific types can minimize disruptions.

Additionally, BIP-322 only supports certain input types.

Types of Scripts Supported in BIP-322:

BIP-322 is designed to accommodate various Bitcoin script types, including:

• P2PKH (Pay-to-PubKey-Hash): Standard single-signature scripts.
• P2SH (Pay-to-Script-Hash): Scripts that reference more complex scripts, such as multi-signature setups.
• SegWit (P2WPKH, P2WSH): Segregated Witness scripts.
  TODO: does the standard support p2tr key spends?

Expiry and Proof Updates

It is important for peers to:

1. Be able to update their BIP-322 proof, either when spending some UTXOs or adding additional ones.
2. Reject proofs that are no longer valid or relevant.

This introduces a broader discussion on how to handle the expiration and pruning of proofs within the protocol.