Unsettled Inputs Break Zero-confirmation Transactions
Title: Unsettled Inputs Break Zero-confirmation Transactions
Type: Standards
Layer: Applications
Maintainer: 2qx
Status: Draft
Initial Publication Date: 2025-11-25
Latest Revision Date: 2025-11-25
Version: 0.1.0-draft
Summary
A rule is proposed for wallet implementers to manage expectations around defi contracts and zero-conf.
Discussion
As this is primarily a problem of coordination among various teams, it should be handy to limit high-level succinct discussion “on the record” to this BCR thread.
Background
For several years, new uses of contracts employing anyone-can-spend miner extractable value (MEV) have been expanding throughout the Bitcoin Cash ecosystem. There has begun to be some conflict, at times, about the implications of these latent features in contracts to the way Bitcoin Cash has historically been used, as cash.
This CHIP is an attempt to reduce conflict by articulating the problem and the minimum wallet requirements to prevent this issue from ever negatively affecting merchants and retail users.
In short, there are now and have always been, transactions possible on the network which are subject to race conditions, reversions and replacement in the mempool. Despite this potentiality, some of these contracts are becoming increasingly useful in a Cambrian Explosion of new systems. Anyone can build these transactions. Some systems are better (or worse) at deploying this feature in a reliable way.
Proposed Solution
In the context of a physical retail environment, of Alice paying a merchant for goods at a point-of-sale (which is of critical importance to the whole project) it would be good to manage expectations about the block confirmations needed in the case of a p2sh input.
Both Alice and the Merchant MUST have clear indication in their respective software if an input to a transaction has an unconfirmed p2sh somewhere in the chain of inputs.
Traditionally, in banking or finance, such funds would be called “unsettled” or “pending”.
As a solution, the following rule is proposed:
If there is any non-p2pkh input in the unconfirmed chain of transactions funding a transaction, a wallet or PoS SHOULD present a message of “pending” or “unsettled” and NOT show the merchant or user any visual indication that could imply the transaction is complete, as it otherwise would be in a zero-confirmation transaction.
There is a LOT of jargon around the industry. This standard proposes the simplest words in a given locale MUST be used for what has traditionally been called a pending or unsettled financial transaction.
While exceptions could be made for well known pay to script hash contracts that are signed, for general contracts, we don’t always have every potential spending path revealed. In addition, as more folks are learning script and weird new things are being built, it may be better to err on the safe side for now.
Along with a rule that BIP44 wallets MUST search all possible xpaths in a known list, we could move towards a common standard of wallet behavior around Bitcoin Cash’s quirks and features.
As it is not a CHIP affecting consensus, industry leaders may adopt it at any time.
Copyright
This document is placed in the public domain.
