Zero-confirmation transaction - Revision history

NotATether: Add Double-spend risks and Relay and packages sections

2026-09-13T07:30:38Z

Add Double-spend risks and Relay and packages sections

← Older revision		Revision as of 07:30, 13 September 2026
Line 2:		Line 2:

	Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. [[Replace by fee]] policies weakened those assumptions. BIP 125 defined opt-in signaling with <code>nSequence</code> and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The [[Lightning Network]] and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one [[Confirmation\|confirmation]], reversing the payment requires a chain reorganization.		Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. [[Replace by fee]] policies weakened those assumptions. BIP 125 defined opt-in signaling with <code>nSequence</code> and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The [[Lightning Network]] and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one [[Confirmation\|confirmation]], reversing the payment requires a chain reorganization.

			== Double-spend risks ==

	Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under [[Full RBF]]. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.		Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under [[Full RBF]]. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.

	Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.		Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.

			== Relay and packages ==

	Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.		Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.

	Under [[Cluster mempool]] and [[Package relay]], a child can raise a parent's effective feerate without making the parent final. A receiver who credits on first sight of a low-fee parent can still lose to a replacement package that miners prefer. Policies that wait for the payment to clear the node's mempool minimum and to remain unconflicted for a short timer only reduce, not eliminate, that risk.		Under [[Cluster mempool]] and [[Package relay]], a child can raise a parent's effective feerate without making the parent final. A receiver who credits on first sight of a low-fee parent can still lose to a replacement package that miners prefer. Policies that wait for the payment to clear the node's mempool minimum and to remain unconflicted for a short timer only reduce, not eliminate, that risk.


	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:26:59Z

Expand See also links

← Older revision		Revision as of 07:26, 13 September 2026
Line 17:		Line 17:
	* [[Full RBF]]		* [[Full RBF]]
	* [[Mempool]]		* [[Mempool]]
			* [[Package relay]]
	* [[Just-in-time channel]]		* [[Just-in-time channel]]
	* [[Lightning Network]]		* [[Lightning Network]]

NotATether: Add package fee bumps versus finality

2026-09-13T07:26:57Z

Add package fee bumps versus finality

← Older revision		Revision as of 07:26, 13 September 2026
Line 8:		Line 8:

	Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.		Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.

			Under [[Cluster mempool]] and [[Package relay]], a child can raise a parent's effective feerate without making the parent final. A receiver who credits on first sight of a low-fee parent can still lose to a replacement package that miners prefer. Policies that wait for the payment to clear the node's mempool minimum and to remain unconflicted for a short timer only reduce, not eliminate, that risk.

	== See also ==		== See also ==

NotATether: Add relay visibility versus consensus finality

2026-09-13T07:26:55Z

Add relay visibility versus consensus finality

← Older revision		Revision as of 07:26, 13 September 2026
Line 6:		Line 6:

	Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.		Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.

			Compact block relay and fee filters do not change the consensus rule that unconfirmed transactions remain reversible by a higher-work chain tip. They only affect how quickly a receiver might see a payment or a conflicting double spend. Explorers that mark a transaction as confirmed after one block are reporting chain inclusion, not merchant risk policy.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:22:46Z

Expand See also links

← Older revision		Revision as of 07:22, 13 September 2026
Line 11:		Line 11:
	* [[Confirmation]]		* [[Confirmation]]
	* [[Replace by fee]]		* [[Replace by fee]]
			* [[Full RBF]]
	* [[Mempool]]		* [[Mempool]]
			* [[Just-in-time channel]]
	* [[Lightning Network]]		* [[Lightning Network]]

NotATether: Add private vs open-network acceptance

2026-09-13T07:22:44Z

Add private vs open-network acceptance

← Older revision		Revision as of 07:22, 13 September 2026
Line 4:		Line 4:

	Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under [[Full RBF]]. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.		Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under [[Full RBF]]. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.

			Some services still accept 0-conf from known customers or over private payment channels where replacement is contractually constrained. On the open P2P network, policy diversity means a transaction may be replaceable on one relay path and sticky on another until miners choose. Lightning inbound receives that rely on unconfirmed funding (including some JIT opens) inherit related risks until the funding transaction confirms.

	== See also ==		== See also ==

NotATether: Add double-spend races and receiver heuristics

2026-09-13T07:22:42Z

Add double-spend races and receiver heuristics

← Older revision		Revision as of 07:22, 13 September 2026
Line 2:		Line 2:

	Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. [[Replace by fee]] policies weakened those assumptions. BIP 125 defined opt-in signaling with <code>nSequence</code> and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The [[Lightning Network]] and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one [[Confirmation\|confirmation]], reversing the payment requires a chain reorganization.		Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. [[Replace by fee]] policies weakened those assumptions. BIP 125 defined opt-in signaling with <code>nSequence</code> and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The [[Lightning Network]] and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one [[Confirmation\|confirmation]], reversing the payment requires a chain reorganization.

			Double-spend races can be finney attacks (a miner pre-mines a conflict), race attacks (two conflicting broadcasts), or fee-bump replacements under [[Full RBF]]. Receivers who accept 0-conf often limit face value, require the payment to hit their own node quickly, and watch for conflicts until the first confirmation. None of those heuristics matches the security of waiting for blocks.

	== See also ==		== See also ==

NotATether: create Zero-confirmation transaction stub (0-conf provisional vs RBF)

2026-09-06T07:57:56Z

create Zero-confirmation transaction stub (0-conf provisional vs RBF)

New page

A '''zero-confirmation transaction''' (also called a 0-conf payment) is a Bitcoin payment that a receiver treats as settled before any block includes it. The receiver sees the transaction in the [[Mempool|mempool]] or on the P2P network and may release goods or credit an account immediately. Settlement under that policy is provisional. A conflicting spend of the same inputs can still be mined instead, leaving the receiver unpaid.

Bitcoin's consensus finality is tied to block inclusion and subsequent work. Early merchant practice sometimes accepted unconfirmed payments for small face-to-face purchases under a first-seen heuristic. [[Replace by fee]] policies weakened those assumptions. BIP 125 defined opt-in signaling with <code>nSequence</code> and replacement fee rules focused on higher absolute fees and incremental payment for relay bandwidth. It did not prohibit replacing non-signaling transactions at consensus. Bitcoin Core later added full RBF settings that allow replacement regardless of signaling. As full RBF became widespread default policy, any unconfirmed payment could be displaced by a higher-paying conflict that honest miners prefer. The [[Lightning Network]] and other off-chain protocols exist in part because on-chain 0-conf cannot provide fast, high-assurance settlement for open-network commerce. After one [[Confirmation|confirmation]], reversing the payment requires a chain reorganization.

== See also ==

* [[Confirmation]]
* [[Replace by fee]]
* [[Mempool]]
* [[Lightning Network]]

== External links ==

* [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP 125: Opt-in Full Replace-by-Fee Signaling]
* [https://bitcoinops.org/en/topics/replace-by-fee/ Bitcoin Optech: Replace by fee]
* [https://bitcoin.org/en/bitcoin-paper Bitcoin whitepaper]

[[Category:Technical]]