discussion: In-band P2P relay of partially signed transactions (PSBT) #34968

Context

We're implementing in-band P2P relay of partially signed transactions on Gridcoin (a Bitcoin-derived PoS chain). The design enables collaborative multisig signing without out-of-band coordination — partial transactions are relayed through the P2P network, co-signers are notified, and the completed transaction enters the mempool normally.

We're aware that Bitcoin Core has consistently kept PSBTs off the P2P layer (BIP 174 is file-based, BIP 77 Async Payjoin uses external directory servers). We'd like to understand the reasoning better and share our design for feedback, since some of the anti-DoS properties may be of general interest.

Motivation

Our primary use case is foundation governance — a multisig address managed by geographically distributed keyholders. The current out-of-band workflow (manual file exchange) is painful and error-prone. We want the network itself to coordinate the signing.

Design summary

PSGT Pool — a dedicated pool, separate from the mempool, for incomplete transactions. Key properties:

• Mandatory signature gate: A PSGT MUST have at least one valid signature to be accepted into the pool or relayed. You cannot put a partial transaction on the network without proving you are a party to it (you must lock a real UTXO). This is the primary anti-spam measure.

• Image uniqueness: Each PSGT has an "image" = hash(redeem_script + sorted_output_scripts). Only ONE active PSGT per image is allowed in the pool. This prevents duplicate flooding and variation spam.

• Reject-when-full: When the pool hits its size cap, new PSGTs are rejected (not evicted). No silent disruption of in-progress workflows.

• 7-day expiry: Abandoned PSGTs are cleaned up automatically.

• Block-confirmed eviction: PSGTs whose inputs are confirmed spent in a block are evicted via a ConnectBlock handler. Mempool state is NOT used for acceptance decisions (it's local and inconsistent across nodes).

P2P relay uses a new inv type (MSG_PSBT). Non-upgraded nodes silently ignore unknown inv types (standard Bitcoin P2P behavior). Upgraded nodes form a natural overlay without targeted routing.

Signature accumulation: When a co-signer adds their signature, they rebroadcast the PSGT. The pool replaces the existing entry if the new version is a strict superset of signatures.

Lifecycle: Initiator signs and broadcasts → network relays → co-signer's wallet detects matching key and notifies user → user approves and signs → rebroadcast → when fully signed, finalized to standard transaction and broadcast via normal tx flow.

Questions for Bitcoin Core developers

1. Has in-band PSBT relay been formally considered and rejected? We found no issue or mailing list thread discussing it directly. Is the omission deliberate (analyzed and rejected) or simply not yet explored?

2. DoS concerns: The mandatory signature requirement means creating spam PSBTs requires locking real UTXOs — there's a concrete economic cost. Combined with the one-per-image constraint, the attack surface seems manageable. Do you see DoS vectors we're missing?

3. Privacy: We acknowledge that in-band relay reveals multisig arrangements before confirmation. For our use case (foundation governance) this is acceptable. For Bitcoin's privacy model, is this the primary objection?

4. Separation of concerns: Is the philosophical position that the P2P layer should only carry valid transactions/blocks, and coordination belongs at the application layer (external servers, Nostr, etc.)? Or is there openness to extending P2P for structured coordination if the anti-DoS properties are sufficient?

We're not proposing that Bitcoin adopt this — our network is much smaller and the trust assumptions are different. But we'd appreciate the perspective of developers who've thought deeply about P2P protocol design.

Full design: https://github.com/gridcoin-community/Gridcoin-Research/issues/2910

Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.

General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.

Network-wide consensus and/or P2P changes first need to be discussed with the greater ecosystem, for example https://groups.google.com/g/bitcoindev, or https://delvingbitcoin.org/. Also, they need a BIP to be implemented in Bitcoin Core and other software that connects to the bitcoin P2P network.

Has in-band PSBT relay been formally considered and rejected?

Not formally so, but it has been discussed in passing multiple times, generally resulting in it being a bad idea.

The mandatory signature requirement means creating spam PSBTs requires locking real UTXOs — there's a concrete economic cost.

It does not. There is no real threat that the coins actually leave the attacker's control as PSBTs are not valid own their own. Your hash construction includes the output scripts, and is therefore trivial to create new images.

Privacy: We acknowledge that in-band relay reveals multisig arrangements before confirmation. For our use case (foundation governance) this is acceptable. For Bitcoin's privacy model, is this the primary objection?

Privacy is one of the main arguments. PSBTs can contain a lot of additional information that revealing to third parties is generally undesirable. In particular, there's no good reason to be revealing xpubs and derivation paths to the world.

Sharing PSBTs publicly over p2p fundamentally doesn't make sense to me. You already have to communicate with someone out-of-band in order to setup a multi-party transaction, why are you changing communication channels?