The 141-vbyte Problem: What PISA's Demo Left Out of the Byte Count
SignalStacker
The mempool does not run on press releases. A conventional one-input, two-output payment settles at roughly 141 vbytes. A two-input, two-output Payjoin โ the privacy construction that lets a receiver contribute its own coins and break the common-input-ownership heuristic โ lands north of 200 vbytes. That gap, somewhere between 40 and 60 percent depending on script type, is not an implementation flaw. It is the structural price of interaction. Every wallet engineer who has shipped Payjoin knows this number, and every merchant who has declined to support it has declined on the basis of this number. So when a demo surfaces claiming that Payjoin plus CISA "could shrink Bitcoin transactions," the first question is not whether the idea is elegant. The idea is elegant. The first question is the delta: from what byte count, to what byte count, under which script type, on which network, verified by whom. The announcement supplied none of these. It supplied a verb โ "shrink" โ attached to a conditional.
Let me lay the two components out honestly, because the coverage I reviewed did not.
Payjoin is not new. The Pay-to-EndPoint variant, BIP78, was proposed in 2018. Payjoin v2, BIP77, addressed the interactivity problem by routing negotiation through an untrusted blind relay so the receiver did not need to be online synchronously. Both are application-layer changes. Neither requires a consensus change. Any wallet team could ship BIP78 support tomorrow. For eight years, almost none have done so in production at scale, and the reason has always been economic rather than technical: users pay for privacy in vbytes, and wallets and merchants have consistently declined to absorb that bill on the user's behalf.
CISA โ Cross-Input Signature Aggregation โ is a different animal entirely. It lets multiple inputs sharing the same public key or script type carry a single signature instead of one signature per input. Under Taproot key-path spending, each additional input currently carries roughly 64 bytes of witness data for its Schnorr signature. Aggregation removes the redundant copies. That is a consensus-layer change. It requires a BIP, a mailing list fight, node operator adoption, miner signaling, and coordinated activation. The historical cadence for that work runs two to five years per soft fork: SegWit in 2017, Taproot in 2021.
Then there is PISA. The source text never defines it. The most self-consistent reading is that PISA is a demonstration project combining Payjoin with CISA specifically to cancel Payjoin's size penalty. That is an inference, flagged as such, and I treat it as one throughout.
Now the arithmetic. CISA's saving on an extra Taproot input is roughly 16 vbytes after witness discount accounting. A Payjoin's extra input costs substantially more than 16 vbytes once you include the outpoint, sequence, scriptPubKey, and interaction overhead. Aggregation narrows the gap between a Payjoin and a plain payment. It does not close it, and it certainly does not reverse it. Which means "shrink" cannot honestly mean "Payjoin becomes smaller than a normal transaction." It can only mean "Payjoin stops being punitively large relative to a normal transaction." Those are different claims, and only the second one is authorized by the byte math.
If a demo genuinely produced a Payjoin smaller than 141 vbytes while carrying equivalent privacy properties, it must have stacked additional techniques on top โ output consolidation, script simplification, or a non-standard construction the report never names. Absent that, "shrink" is a marketing verb doing work the numbers have not approved.
Second: the time folding. The article presents Payjoin and CISA as parallel components of one technique. They operate on timelines an order of magnitude apart. Payjoin is a wallet update. CISA is a governance campaign. Whatever PISA demonstrates, its deployment is bottlenecked by the slowest link, and the slowest link has not started moving.
Third, and this is the part nobody writing about PISA wants to touch: Bitcoin in 2025 is in an ossification mood. The CTV, CSFS, and OP_CAT debates of the past two years have made "does this need to exist" the default question for any consensus change. CISA answers that question weakly. It adds no new capability. It is a pure efficiency optimization, and it interacts messily with covenant proposals that want to reason about transaction structure. In a governance environment where every soft fork must justify its political cost, CISA holds one of the thinnest justifications currently on the table.
Fourth: even conditional on activation, the payoff depends on wallet-side engineering nobody has committed to. Aggregation only pays when multiple inputs share a script type and key. Real wallets hold UTXOs of mixed provenance โ P2WPKH change, P2TR receives, legacy P2SH dust. To capture CISA's savings, a wallet must actively co-spend same-type UTXOs and restructure its coin selection. That is a UTXO management problem, not a protocol problem, and it is precisely the kind of work that ships two years after a fork and gets abandoned after one release cycle.
Fifth, the cost that never appears in the announcement: witness structure changes ripple downstream. wtxid derivation, fee estimation heuristics, hardware wallet signing flows, PSBT serialization expectations, and the parsing logic of every chain-analytics vendor. That is a full-stack adaptation bill paid by people who did not request the feature.
Which raises the question the demo has to answer and does not: why Payjoin at all? BIP352 Silent Payments already solves address-reuse privacy without requiring the receiver to be online, without interactivity, and without a size penalty of this shape. It is live. If Payjoin's core selling point โ unlinkability of inputs โ can be achieved by a static payment code a merchant prints on an invoice, then the marginal value of shaving 16 vbytes off a Payjoin is a rounding error layered onto a construction the ecosystem may simply route around.
Now the economics, which is where this gets genuinely interesting and genuinely bad for the thesis.
PISA has no token. No treasury, no foundation, no value-capture layer. The savings accrue entirely to senders and receivers. Ordinarily I treat the absence of a token as a risk-absent flag. Here it is the opposite: it means nobody has a concentrated financial incentive to push CISA through a multi-year consensus process. Taproot had a developer community with ideological commitment. Lightning has exchanges and wallet vendors with commercial motive. CISA has a diffuse benefit โ a few satoshis per user โ and concentrated costs in development, review, coordination, and political capital. That is the textbook public-goods underprovision problem, and it is the cleanest economic explanation for why CISA has sat in discussion for years without activation.
There is a longer-horizon problem this class of article never mentions. Bitcoin's security budget depends on fee growth. Every efficiency optimization โ SegWit, Taproot, batching, and now possibly CISA โ reduces vbytes consumed per unit of economic activity. If transaction count grows while per-transaction fees fall, fee revenue can plateau exactly as the security budget requirement rises with each halving. I am not arguing against efficiency. I am arguing that "cheaper transactions" and "healthier fee market" are not the same sentence, and the coverage of PISA treats them as identical.
Here is the correlation-versus-causation problem in its purest form. A demo exists. An outlet reports it. Readers infer progress. None of those three links is causally connected to deployment. The only signal that would move my estimate is a BIP number on the bitcoin-dev mailing list, a reproducible transaction on signet or a public simulator, and wallet teams committing engineering time. Absent those three, the announcement is a screenshot of an idea.
Note also what the piece does not contain. No timestamp in the version I received. No named team. No repository. No author. No byte counts. No comparison table. The entire construction uses "could," "may," "potential" โ the grammar of possibility, not of achievement. And the headline verb does specific work: "shrink transactions" reads to a casual reader as scaling. Technically it means fitting more transactions into the same block space. Same block space. That is efficiency, not capacity. The distinction matters because this market has repeatedly priced "Bitcoin scaling breakthrough" headlines that turned out to be transaction-format optimizations with two-year adoption tails and a graveyard of orphaned repositories behind them.
The code did not lie; the humans misread the data. In this case there was no data to misread โ only a headline shaped like one.
Watch for three artifacts over the next two quarters: a BIP or mailing list thread spelling out CISA's activation mechanics, a reproducible demonstration shipping a vbyte table, and at least one production wallet committing to same-type UTXO aggregation. Any one of those is a real signal. None appearing is also a signal, and it is the loud kind.
Transition is not an event, but a data stream. Right now the stream is empty, and the mempool has not moved a single byte.