From 5eed2eac26125deb40c62c73e0917768001c2758 Mon Sep 17 00:00:00 2001 From: Mike Rahel Date: Wed, 28 Jan 2026 16:16:21 -0500 Subject: [PATCH 1/2] Add comprehensive zero-confirmation transactions content Addresses issue #1216 - Content request: zero-conf transactions This PR adds a dedicated page explaining zero-confirmation transactions, covering all requested topics: - What zero-conf transactions are - Mempools and lack of mempool consensus - Double spending (zero-conf vs chain-committed) - Stuck transactions and solutions (RBF, CPFP) - Risks of accepting zero-conf - Timelocks (CLTV and CSV) and their benefits - Impossibility of instantaneous consensus - Best practices for merchants and users Bounty payment address: btcevangelist@coinos.io --- _templates/zero-conf.html | 107 ++++++++++++++++++++++++++++++++++++++ _translations/en.yml | 52 ++++++++++++++++++ 2 files changed, 159 insertions(+) create mode 100644 _templates/zero-conf.html diff --git a/_templates/zero-conf.html b/_templates/zero-conf.html new file mode 100644 index 0000000000..b0ce0e4b61 --- /dev/null +++ b/_templates/zero-conf.html @@ -0,0 +1,107 @@ +--- +# This file is licensed under the MIT License (MIT) available on +# http://opensource.org/licenses/MIT. + +layout: base +id: zero-conf +--- + +
+
+

{% translate pagetitle %}

+

{% translate pagedesc %}

+
+
+ +
+ +
+
+

{% translate whatiszeroconf %}

+

{% translate whatiszeroconftext1 %}

+

{% translate whatiszeroconftext2 %}

+
+
+ +
+
+

{% translate mempool %}

+

{% translate mempooltext1 %}

+

{% translate mempooltext2 %}

+

{% translate mempooltext3 %}

+
+
+ +
+
+

{% translate doublespending %}

+

{% translate doublespendingtext1 %}

+

{% translate zeroconfdoublespend %}

+

{% translate zeroconfdoublespendtext %}

+

{% translate chaincommitted %}

+

{% translate chaincommittedtext %}

+
+
+ +
+
+

{% translate stucktx %}

+

{% translate stucktxtext1 %}

+

{% translate stucktxtext2 %}

+
    +
  • {% translate stucktxsolution1 %}
    • +
  • {% translate stucktxsolution2 %}
    • +
  • {% translate stucktxsolution3 %}
    • +
+
+
+ +
+
+

{% translate risks %}

+

{% translate riskstext %}

+
    +
  • {% translate risk1title %} - {% translate risk1text %}
    • +
  • {% translate risk2title %} - {% translate risk2text %}
    • +
  • {% translate risk3title %} - {% translate risk3text %}
    • +
  • {% translate risk4title %} - {% translate risk4text %}
    • +
+
+
+ +
+
+

{% translate timelocks %}

+

{% translate timelockstext1 %}

+

{% translate cltv %}

+

{% translate cltvtext %}

+

{% translate csv %}

+

{% translate csvtext %}

+

{% translate timelockstext2 %}

+
+
+ +
+
+

{% translate consensus %}

+

{% translate consensustext1 %}

+

{% translate consensustext2 %}

+

{% translate consensustext3 %}

+
+
+ +
+
+

{% translate bestpractices %}

+

{% translate bestpracticestext %}

+
    +
  • {% translate bestpractice1 %}
    • +
  • {% translate bestpractice2 %}
    • +
  • {% translate bestpractice3 %}
    • +
  • {% translate bestpractice4 %}
    • +
  • {% translate bestpractice5 %}
    • +
+
+
+ +
diff --git a/_translations/en.yml b/_translations/en.yml index 1059dbac8f..87975b9105 100644 --- a/_translations/en.yml +++ b/_translations/en.yml @@ -558,6 +558,57 @@ en: ircjoin: "IRC Channel #bitcoin-core-dev on freenode." stackexchange: "Bitcoin StackExchange" bitcointalkdev: "BitcoinTalk Development & Technical Discussion Forum" + zero-conf: + title: "Zero-Confirmation Transactions - Bitcoin" + pagetitle: "Zero-Confirmation Transactions" + pagedesc: "Understanding unconfirmed Bitcoin transactions, their risks, and when they might be acceptable." + whatiszeroconf: "What Are Zero-Confirmation Transactions?" + whatiszeroconftext1: "A zero-confirmation transaction (also called \"zero-conf\" or \"0-conf\") is a Bitcoin transaction that has been broadcast to the network but has not yet been included in a block. Until a transaction is confirmed in a block, it exists only in the memory pools (mempools) of nodes that have received it." + whatiszeroconftext2: "When you send Bitcoin, the transaction is first broadcast to the peer-to-peer network. Miners then select transactions from their mempools to include in the next block. Only after a transaction is included in a block and that block is added to the blockchain is the transaction considered \"confirmed.\"" + mempool: "Mempools and Transaction Propagation" + mempooltext1: "Each Bitcoin node maintains its own mempool - a waiting area for unconfirmed transactions. When a transaction is broadcast, it propagates across the network as nodes relay it to their peers." + mempooltext2: "Critically, there is no global mempool consensus. Each node independently decides which transactions to accept into its mempool based on its own policies. A transaction in one node's mempool may not exist in another's due to different relay policies, transaction conflicts, or network delays." + mempooltext3: "This lack of mempool consensus is fundamental to understanding zero-conf risks: just because you see a transaction doesn't mean everyone else does, and just because a transaction is in your mempool doesn't mean it will be mined." + doublespending: "Double Spending" + doublespendingtext1: "Double spending occurs when someone attempts to spend the same Bitcoin twice. This is the primary risk that zero-confirmation acceptance exposes merchants to." + zeroconfdoublespend: "Zero-Conf Double Spending" + zeroconfdoublespendtext: "Before a transaction is confirmed, an attacker can broadcast a conflicting transaction that spends the same inputs to a different address. If miners include the conflicting transaction instead of the original, the merchant loses their payment. This attack is relatively easy to execute and requires no special equipment or significant resources." + chaincommitted: "Chain-Committed Double Spending" + chaincommittedtext: "Once a transaction is confirmed in a block, reversing it requires reorganizing the blockchain - an attack that becomes exponentially more difficult with each additional confirmation. This is why multiple confirmations are recommended for high-value transactions." + stucktx: "Stuck Transactions" + stucktxtext1: "Sometimes transactions become \"stuck\" in the mempool for extended periods. This typically occurs when the fee attached to a transaction is too low compared to current network demand." + stucktxtext2: "Stuck transactions create uncertainty for both senders and recipients. Solutions include:" + stucktxsolution1: "Replace-By-Fee (RBF): Broadcasting a new transaction with a higher fee that replaces the original" + stucktxsolution2: "Child-Pays-For-Parent (CPFP): Creating a child transaction with a high fee to incentivize miners to confirm both" + stucktxsolution3: "Waiting: Mempools eventually drop old transactions, allowing the funds to be respent" + risks: "Risks of Accepting Zero-Conf" + riskstext: "Accepting zero-confirmation transactions carries several significant risks:" + risk1title: "Double-spend attacks" + risk1text: "An attacker can broadcast conflicting transactions, potentially receiving goods while redirecting payment elsewhere" + risk2title: "No guarantee of confirmation" + risk2text: "Low-fee transactions may never confirm, leaving the payment in limbo indefinitely" + risk3title: "Network propagation delays" + risk3text: "A transaction you see may not have reached miners or may conflict with a transaction they received first" + risk4title: "Miner policies" + risk4text: "Miners can choose which transactions to include; they may prefer a conflicting higher-fee transaction" + timelocks: "Timelocks: CLTV and CSV" + timelockstext1: "Bitcoin includes timelock features that can constrain how certain zero-conf transactions behave, providing additional security in specific use cases." + cltv: "CheckLockTimeVerify (CLTV)" + cltvtext: "CLTV allows transactions to specify that outputs cannot be spent until a certain block height or Unix timestamp. This is useful for payment channels and escrow arrangements where funds should only be accessible after a specific time." + csv: "CheckSequenceVerify (CSV)" + csvtext: "CSV enables relative timelocks - outputs that cannot be spent until a certain number of blocks have been mined since the transaction was confirmed. This is essential for Lightning Network payment channels and other second-layer protocols." + timelockstext2: "While timelocks don't make zero-conf transactions safe for general commerce, they enable sophisticated protocols where the risk of double-spending can be mitigated through economic incentives and cryptographic commitments." + consensus: "The Impossibility of Instant Consensus" + consensustext1: "A fundamental property of decentralized systems is that instant global consensus is impossible. Information takes time to propagate, and different nodes may have different views of the current state at any given moment." + consensustext2: "Bitcoin's solution is to use proof-of-work mining to establish consensus over time. Each block represents agreement on the ordering of transactions, but this agreement only emerges after the fact - not instantly." + consensustext3: "This is why confirmations matter: they represent increasing confidence that the network has reached consensus about a transaction's validity and ordering. Zero confirmations means no consensus has been reached." + bestpractices: "Best Practices" + bestpracticestext: "When dealing with unconfirmed transactions:" + bestpractice1: "For high-value transactions, always wait for at least one confirmation (6+ confirmations for very high values)" + bestpractice2: "For low-value, in-person transactions where the customer is known, zero-conf may be acceptable given the economic impracticality of attacks" + bestpractice3: "Use payment processors or Lightning Network for instant settlement needs" + bestpractice4: "Monitor for conflicting transactions if accepting zero-conf" + bestpractice5: "Consider the value at risk relative to the cost of potential fraud" download: title: "Download - Bitcoin" pagetitle: "Download Bitcoin Core" @@ -1236,6 +1287,7 @@ en: support-bitcoin: support-bitcoin vocabulary: vocabulary you-need-to-know: you-need-to-know + zero-conf: zero-conf bitcoin-paper: bitcoin-paper whitepaper-mirrors: whitepaper-mirrors spend-bitcoin: spend-bitcoin From 25c22fd79d1df0b2ae437edaca6d687568fdd86d Mon Sep 17 00:00:00 2001 From: Mike Rahel Date: Wed, 28 Jan 2026 16:30:29 -0500 Subject: [PATCH 2/2] Fix grammar: "Zero confirmations means" -> "Having zero confirmations means" Address review feedback for correct subject-verb agreement. Co-Authored-By: Claude Opus 4.5 --- _translations/en.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_translations/en.yml b/_translations/en.yml index 87975b9105..164c47b1a8 100644 --- a/_translations/en.yml +++ b/_translations/en.yml @@ -601,7 +601,7 @@ en: consensus: "The Impossibility of Instant Consensus" consensustext1: "A fundamental property of decentralized systems is that instant global consensus is impossible. Information takes time to propagate, and different nodes may have different views of the current state at any given moment." consensustext2: "Bitcoin's solution is to use proof-of-work mining to establish consensus over time. Each block represents agreement on the ordering of transactions, but this agreement only emerges after the fact - not instantly." - consensustext3: "This is why confirmations matter: they represent increasing confidence that the network has reached consensus about a transaction's validity and ordering. Zero confirmations means no consensus has been reached." + consensustext3: "This is why confirmations matter: they represent increasing confidence that the network has reached consensus about a transaction's validity and ordering. Having zero confirmations means no consensus has been reached." bestpractices: "Best Practices" bestpracticestext: "When dealing with unconfirmed transactions:" bestpractice1: "For high-value transactions, always wait for at least one confirmation (6+ confirmations for very high values)"