Status: Experimental application-layer draft
Intended use: Static private donation/payment codes for eCash
Deployment status: Regtest/testnet only until independent review
Protocol version: 0
Draft revision: 0.3
Date: 2026-07-03

Source code: https://codeberg.org/vibe-labs/xsp-core

Security warning: XSP v0 is a new cryptographic wallet protocol, not an accepted eCash standard. Do not use it to receive material mainnet funds until it has received independent cryptographic review, two interoperable implementations, published test vectors, fuzz testing, and a sustained testnet trial.

1. Abstract

XSP v0 defines a reusable eCash payment code that lets a receiver publish one static code while every payment is sent to a fresh, ordinary P2PKH output.

The sender and receiver derive the same one-time destination using secp256k1 ECDH:

the sender uses the private keys of the transaction inputs and the receiver's scan public key;
the receiver uses the public keys revealed by those P2PKH inputs and the receiver's scan private key;
the resulting output is a normal eCash P2PKH output;
no OP_RETURN notification, server-issued address, or consensus change is required.

XSP v0 is inspired by BIP352 Silent Payments but is deliberately adapted to eCash's ordinary P2PKH transaction model.

2. Goals

XSP v0 MUST provide:

A reusable public payment code.
A unique P2PKH destination for each valid transaction input set.
No receiver interaction at payment time.
No on-chain notification marker.
No consensus or script upgrade.
Separation between scanning and spending keys.
Seed-based backup and deterministic recovery.
Sender and receiver implementations that can be developed independently from published vectors.

XSP v0 does not claim to hide:

the sender's input clustering or change output;
the public identity associated with a published donation code;
the fact that outputs later spent together probably share an owner;
information leaked to a third-party remote scanner.

3. Mandatory v0 scope

An XSP v0 sending transaction:

MUST contain at least one standard P2PKH input eligible under Section 8;
MUST use 33-byte compressed secp256k1 public keys for every eligible input;
MUST derive the shared secret from the complete eligible-input subset, with each eligible input occurrence included exactly once;
MAY contain other non-P2PKH inputs, but those inputs are ignored for XSP shared-secret derivation by both sender and receiver;
MUST be controlled by one wallet/signing entity;
MUST finalize its complete input set before deriving XSP outputs;
MUST sign all inputs with SIGHASH_ALL | SIGHASH_FORKID (commonly exposed as ALL_BIP143);
MUST NOT use ANYONECANPAY;
MUST NOT be a collaborative transaction such as CashFusion, CoinJoin, PayJoin, or an externally assembled multisig transaction;
MUST NOT spend token-bearing UTXOs in the first implementation;
MUST NOT create more than 64 outputs to the same XSP code in one transaction;
MUST perform the pre-broadcast conformance self-check in Section 10.2.

Already-fused ordinary P2PKH UTXOs MAY later be spent by a single-owner XSP transaction. The CashFusion round itself is outside v0.

The eligible-subset rule intentionally follows the general Silent Payments principle that unsupported input types may fund a transaction without participating in ECDH. It avoids silent receiver failure when a single-owner wallet includes a non-P2PKH input. A sender MUST NOT include a private scalar for an input whose public key cannot be recovered by the receiver under Section 8.

v0 receiving outputs are standard:

OP_DUP OP_HASH160 <20-byte HASH160(compressed one-time pubkey)>
OP_EQUALVERIFY OP_CHECKSIG

4. Notation and primitives

G: secp256k1 generator.
n: secp256k1 group order.
Lowercase symbols are private scalars.
Uppercase symbols are public curve points.
serP(P): 33-byte compressed SEC encoding of point P.
ser32(i): 4-byte unsigned big-endian integer.
serOutpoint(txid, vout): 32-byte transaction ID in consensus little-endian byte order followed by 4-byte little-endian output index.
CompactSize(i): Bitcoin/eCash CompactSize integer encoding.
HASH160(x) = RIPEMD160(SHA256(x)).
||: byte concatenation.

4.1 Tagged hash

TaggedHash(tag, msg) =
SHA256(SHA256(tag) || SHA256(tag) || msg)

tag is the ASCII string exactly as specified.

4.2 Hash to scalar

HashToScalar(tag, msg):
x = int_big_endian(TaggedHash(tag, msg))
require 1 <= x < n
return x

Implementations MUST NOT silently reduce the value modulo n, because that would create incompatible implementations.

Failure behavior is asymmetric because the sender controls transaction construction while the receiver processes adversarial blockchain data:

A sender that obtains an out-of-range value MUST abort before broadcast and rebuild with a different input set.
A receiver that obtains an out-of-range value while scanning MUST classify that transaction as non-conforming, discard all candidate matches from that transaction, and continue with the next transaction without terminating the scan loop.

The event is cryptographically negligible for honestly generated inputs, but receiver behavior MUST still be explicitly implemented and tested.

5. Network identifiers

Network HRP network_id eCash mainnet xecsp 0x00 eCash testnet txecsp 0x01 eCash regtest rxecsp 0x02

The network_id is included in cryptographic derivation. A code for one network MUST be rejected on another network.

6. Receiver key derivation

Wallets using a BIP32 seed SHOULD derive:

scan_private_key = m / 352' / 1899' / account' / 1' / 0
spend_private_key = m / 352' / 1899' / account' / 0' / 0

Then:

B_scan = b_scan G
B_spend = b_spend G

Requirements:

b_scan and b_spend MUST be valid nonzero secp256k1 scalars.
B_scan and B_spend MUST be distinct.
The hardened branches MUST NOT be replaced with an xpub-derived scheme.
The wallet MUST record a birthday block height alongside the seed backup or descriptor.

The purpose 352' follows the Silent Payments convention. 1899' is the currently registered XEC coin type. This path is separate from normal eCash receive/change paths.

7. Payment-code encoding

An XSP v0 code encodes:

version: one 5-bit value, currently 0
payload: serP(B_scan) || serP(B_spend) // 66 bytes
checksum: Bech32m

Encoding procedure:

Select the HRP for the network.
Set the first data value to 0.
Convert the 66-byte payload from 8-bit groups to 5-bit groups with padding.
Append a Bech32m checksum.
Implementations MUST allow strings longer than the ordinary 90-character Bech32 address limit. A maximum of 160 characters is sufficient for v0.

A v0 decoder MUST enforce all of the following internally, rather than returning unchecked fields to its caller:

the HRP exactly matches the caller-supplied expected network;
the version value is exactly 0;
after removing the six checksum values, the data part contains exactly 107 5-bit values: one version value and 106 payload values;
conversion of the 106 payload values produces exactly 66 bytes;
both public keys parse as valid compressed secp256k1 points and are distinct.

A checksum-valid string containing only an HRP, separator, and six checksum characters has no version/data field and MUST return a normal decoding error. It MUST NOT cause an index, bounds, panic, or process exception.

Because XSP codes exceed the original Bech32 90-character limit, the strongest short-string error-detection guarantees do not fully apply. Random corruption still has approximately the security of the 30-bit checksum, but UI implementations SHOULD prefer QR scanning or copy/paste, SHOULD display a short fingerprint, and SHOULD discourage manual transcription.

Example from the published test vector:

xecsp1qqw8dh7c066f02j2vqcul5kapwh7d4gv43tnt473aacw5kwp4legy7qa7al4tjx6xahdkxasa5kpaltnmr07rnl0qrctk4e7ahy3ev3nz5yd2wt62

An XSP code is not an ordinary eCash CashAddr address. A wallet MUST route it to the XSP parser and MUST NOT pass it to a normal address parser.

Names, avatars, campaign names, suggested amounts, and messages are outside the cryptographic payload. They SHOULD be carried by a separate signed profile or application link.

8. Eligible input parsing

For every transaction input, the receiver attempts to determine whether it belongs to the v0 eligible-input subset.

An input is eligible only when the receiver can obtain:

the previous outpoint;
a standard previous-output P2PKH script;
the signed input script;
exactly one distinct 33-byte compressed public key whose HASH160 matches the previous P2PKH pubkey hash.

The previous-output script is eligible P2PKH only if it is exactly 25 bytes and byte-for-byte equal to:

76 a9 14 <20-byte pubkey hash> 88 ac

Equivalently, the byte sequence is 0x76a914{20-byte-hash}88ac. Consensus-valid or semantically equivalent variants, including a non-minimal OP_PUSHDATA1 0x14 encoding of the 20-byte hash, are non-eligible. Implementations MUST NOT use a semantic script classifier whose accepted byte set is broader than this template.

The input scriptSig MUST be scanned from left to right as raw script bytes, without executing it and without requiring the usual <signature> <pubkey> template:

OP_0 contributes an empty pushed byte string.
Direct pushes 0x01..0x4b and OP_PUSHDATA1, OP_PUSHDATA2, and OP_PUSHDATA4 contribute their declared byte strings. Minimal push encoding is not required.
Every other opcode, including non-push opcodes such as OP_DROP, is skipped as one opcode byte and parsing continues. Small-integer opcodes do not produce a public-key candidate.
If a push length field or pushed payload is truncated or otherwise malformed, the input is non-eligible. The parser MUST NOT resume after the malformed push.

Only pushed values that are exactly 33 bytes and begin with 0x02 or 0x03 are compressed-public-key candidates. This rule intentionally follows BIP352's requirement to find the P2PKH public key even in a non-template scriptSig such as <dummy> OP_DROP <signature> <public key>, rather than treating third-party scriptSig malleation as a different eligible-input subset.

If no matching key exists, if more than one distinct matching key exists, if the key is uncompressed, or if the previous output does not match the exact P2PKH byte template above, that input is non-eligible and is ignored for v0 derivation. The entire transaction is skipped only when no eligible input remains, or when another explicit transaction-level skip condition in Section 11 applies.

Each eligible input occurrence is included separately. If the same key spends two UTXOs, its point and scalar are included twice in the aggregate. Implementations MUST NOT deduplicate repeated public keys.

The sender MUST use exactly the same eligible-input subset definition. A sender that derives with a private scalar from a non-eligible input creates an output that a conforming receiver cannot discover and is therefore non-conforming.

eCash Static Private Payments