Skip to content

Add comprehensive zero-confirmation transactions content #4608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
refined-element wants to merge 2 commits into
base: master
Choose a base branch
from
+159 −0
Open

Add comprehensive zero-confirmation transactions content #4608

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5eed2ea
Add comprehensive zero-confirmation transactions content
refined-element Jan 28, 2026
25c22fd
Fix grammar: "Zero confirmations means" -> "Having zero confirmations…
refined-element Jan 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
107 changes: 107 additions & 0 deletions _templates/zero-conf.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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
---

<div class="hero">
<div class="container hero-container">
<h1>{% translate pagetitle %}</h1>
<p class="summary">{% translate pagedesc %}</p>
</div>
</div>

<div class="container">

<div class="row card-row">
<div class="card">
<h2 id="what-is-zero-conf">{% translate whatiszeroconf %}</h2>
<p>{% translate whatiszeroconftext1 %}</p>
<p>{% translate whatiszeroconftext2 %}</p>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="mempool">{% translate mempool %}</h2>
<p>{% translate mempooltext1 %}</p>
<p>{% translate mempooltext2 %}</p>
<p>{% translate mempooltext3 %}</p>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="double-spending">{% translate doublespending %}</h2>
<p>{% translate doublespendingtext1 %}</p>
<h3>{% translate zeroconfdoublespend %}</h3>
<p>{% translate zeroconfdoublespendtext %}</p>
<h3>{% translate chaincommitted %}</h3>
<p>{% translate chaincommittedtext %}</p>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="stuck-transactions">{% translate stucktx %}</h2>
<p>{% translate stucktxtext1 %}</p>
<p>{% translate stucktxtext2 %}</p>
<ul>
<li>{% translate stucktxsolution1 %}</li>
<li>{% translate stucktxsolution2 %}</li>
<li>{% translate stucktxsolution3 %}</li>
</ul>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="risks">{% translate risks %}</h2>
<p>{% translate riskstext %}</p>
<ul>
<li><strong>{% translate risk1title %}</strong> - {% translate risk1text %}</li>
<li><strong>{% translate risk2title %}</strong> - {% translate risk2text %}</li>
<li><strong>{% translate risk3title %}</strong> - {% translate risk3text %}</li>
<li><strong>{% translate risk4title %}</strong> - {% translate risk4text %}</li>
</ul>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="timelocks">{% translate timelocks %}</h2>
<p>{% translate timelockstext1 %}</p>
<h3>{% translate cltv %}</h3>
<p>{% translate cltvtext %}</p>
<h3>{% translate csv %}</h3>
<p>{% translate csvtext %}</p>
<p>{% translate timelockstext2 %}</p>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="consensus">{% translate consensus %}</h2>
<p>{% translate consensustext1 %}</p>
<p>{% translate consensustext2 %}</p>
<p>{% translate consensustext3 %}</p>
</div>
</div>

<div class="row card-row">
<div class="card">
<h2 id="best-practices">{% translate bestpractices %}</h2>
<p>{% translate bestpracticestext %}</p>
<ul>
<li>{% translate bestpractice1 %}</li>
<li>{% translate bestpractice2 %}</li>
<li>{% translate bestpractice3 %}</li>
<li>{% translate bestpractice4 %}</li>
<li>{% translate bestpractice5 %}</li>
</ul>
</div>
</div>

</div>
52 changes: 52 additions & 0 deletions _translations/en.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -558,6 +558,57 @@ en:
ircjoin: "<a href=\"https://webchat.freenode.net/?channels=bitcoin-core-dev\">IRC Channel #bitcoin-core-dev</a> on freenode."
stackexchange: "<a href=\"https://bitcoin.stackexchange.com/\">Bitcoin StackExchange</a>"
bitcointalkdev: "<a href=\"https://bitcointalk.org/index.php?board=6.0\">BitcoinTalk Development &amp; Technical Discussion Forum</a>"
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. 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)"
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"
Expand Down Expand Up @@ -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
Expand Down