Bitcoin Wiki - Recent changes [en]

Dust

NotATether — Thu, 27 Aug 2026 19:05:18 GMT

Create page

New page

'''Dust''' is an output whose value is so small that spending it would cost more in fees than the output is worth, at a reference [[fee rate]]. Colloquially the word is also used for any tiny UTXO. In node software the term is a precise mempool policy: transactions that create spendable dust outputs are not relayed or mined by default.

Dust limits are policy, not consensus. A miner may include a sub-dust output in a block, and the output remains spendable if a later transaction pays the fee.

== Background ==

Every output occupies space in the UTXO set until it is spent. Outputs that are uneconomical to spend tend to remain there, imposing a cost on every full node. Early Bitcoin Core versions treated very small outputs as non-standard. The current definition, introduced with a dedicated <code>-dustrelayfee</code> setting, compares the output's value to the fee that would be required to create it and later spend it at that rate.

Dust is also a privacy and wallet-UX problem. [[Dusting attack]]s send tiny amounts to many addresses in the hope that a later spend will link those addresses. Wallets may hide or freeze dust so that automatic coin selection does not sweep it.

== How it works ==

Bitcoin Core's <code>GetDustThreshold</code> estimates the serialized size of the output plus a typical input that would spend it. For witness programs the input size is counted with the SegWit weight discount. That size is multiplied by the dust relay fee rate. If the output value is below the resulting amount, the output is dust.

The default dust relay fee rate is 3,000 sat/kvB (3 sat/vB). At that rate the usual thresholds are:

* 546 satoshis for a [[P2PKH]] output (34-byte output plus a ~148-byte input)
* 294 satoshis for a [[P2WPKH]] output
* 330 satoshis for a [[P2WSH]] or [[P2TR]] output, using a conservative spend-size estimate (Taproot key-path spends are smaller, but the threshold was not lowered further)

Unspendable outputs, such as <code>OP_RETURN</code>, have a dust threshold of zero because they never enter the UTXO set as spendable coins.

The dust relay fee is independent of the node's minimum relay [[fee rate]]. Changing <code>-minrelaytxfee</code> does not by itself change dust thresholds. Operators may set <code>-dustrelayfee</code>, but a transaction still has to satisfy the policies of the peers it must cross.

Wallets apply a related idea when creating [[change address]]es. If a prospective change output would be uneconomical at a discard fee rate (often tied to a long-horizon fee estimate, bounded below by the dust rate), the wallet may add that remainder to the miner fee instead of creating the output.

A later policy relaxation, ephemeral dust, allows a single dust output in limited cases when a child transaction in the same package spends it immediately, so the dust never sits in the UTXO set.

== Implementations ==

[[Bitcoin Core]] enforces dust as standardness in mempool admission and relay. Other full nodes that follow Bitcoin Core policy do the same. Wallet software uses the same numbers when deciding whether a change output is worth creating. Lightning funding and some contract protocols have their own dust-like floors for outputs that must be spendable on chain under time pressure.

== See also ==

* [[Fee rate]]
* [[Mempool]]
* [[Change address]]
* [[Dusting attack]]
* [[Coin control]]

== External links ==

* [https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp GetDustThreshold in Bitcoin Core]
* [https://bitcoin.stackexchange.com/questions/10986/what-is-meant-by-bitcoin-dust Stack Exchange: What is meant by Bitcoin dust?]

[[Category:Technical]]

Ark

NotATether — Thu, 27 Aug 2026 12:54:51 GMT

create page

New page

'''Ark''' is a Bitcoin layer-2 protocol in which users hold virtual transaction outputs (VTXOs). A VTXO is backed by a shared on-chain UTXO and by a path of pre-signed transactions that lets the holder create an on-chain output without further interaction. Users transfer VTXOs off-chain with the cooperation of an Ark server (sometimes called an Ark service provider, or ASP). Payments do not require a pre-existing bilateral channel. The original design was posted to the bitcoin-dev mailing list by Burak. The protocol has been revised substantially since that post.

== Background ==

The [[Lightning Network]] moves bitcoin off-chain by locking a 2-of-2 output between two peers and updating a commitment transaction. Receiving Lightning payments requires inbound channel capacity. A new wallet therefore depends on a counterparty or a [[Lightning service provider]] to open a channel. Ark uses a different liquidity model. Several users share one large on-chain UTXO through a tree of off-chain transactions. A user who can spend a leaf of that tree owns the corresponding VTXO and can either exit on-chain or obtain a replacement leaf in a later tree.

The protocol is intended to work with currently active Bitcoin consensus rules. Covenant-less Ark (sometimes called clArk) uses pre-signed transactions as a pseudo-covenant and can operate on Bitcoin without new opcodes. Proposed [[Covenant]] opcodes such as [[CHECKTEMPLATEVERIFY]] would let the tree be committed without interactive pre-signing, but they are not required.

== How it works ==

An Ark round is organized by the server. In current Bark, rounds are used to refresh VTXOs, not to pay other users. Users who wish to refresh register an intent. The server funds a round transaction whose output anchors a tree of pre-signed transactions. In covenant-less implementations, cooperative spend paths in the tree are represented using [[MuSig2]] aggregate keys, and the relevant participants jointly pre-sign the tree. Root and branch cooperative paths are n-of-n arrangements among the users who share that node plus the server. Leaf cooperative paths are 2-of-2 between one user and the server. Each user receives the pre-signed transactions along the path from the round output to that user's leaf, which is what a unilateral exit needs.

A refresh exchanges a user's old VTXO for a new refresh VTXO belonging to the same user. The user signs a forfeit transaction that would pay the old leaf to the server. The server fronts the on-chain liquidity for the new tree and later reclaims the forfeited value when the old tree expires.

In the classic connector-based construction, refresh atomicity is enforced by making the forfeit transaction spend a connector output created by the new round transaction. This prevents the server from exercising the forfeit unless the replacement round exists on-chain. Some newer implementations use different mechanisms. Bark's hArk design, introduced in version 0.1.0-beta.6 in January 2026, uses hash locks for refreshes and retains connectors primarily for on-chain payments and offboarding. Under hArk, the server generates a preimage for each new VTXO. Both the new VTXO and the forfeit are hash-locked on that preimage, so the server cannot claim the old leaf without revealing the secret that unlocks the new one.

Ordinary user-to-user Ark payments are out-of-round (OOR, also called arkoor). They do not wait for the next round. The server co-signs a transfer of an existing VTXO to the receiver, producing a spend VTXO that extends the sender's leaf. Safety of a spend VTXO depends on the sender and server not colluding to double-spend. Refreshing the received VTXO in a later round replaces it with a refresh VTXO and removes that collusion assumption.

VTXOs expire. Once a VTXO reaches its expiry height, the server gains a unilateral path to reclaim the backing funds. The user may still be able to spend or exit a non-forfeited VTXO, but can no longer rely on exclusive control of the backing output, so wallets must refresh or exit before expiry. A valid, non-forfeited refresh VTXO can be exited unilaterally before expiry, at the cost of on-chain fees and delay. Delegated refreshes used by some mobile wallets have a weaker trust model and are not the same as a standard interactive refresh.

Before expiry, a standard refresh VTXO remains self-custodial. An honest user can unilaterally exit without server cooperation, and the server cannot take the user's funds unless the user has previously authorized a conflicting spend or forfeit. After expiry the server has a competing sweep path, so that exclusive guarantee no longer holds. The server is a liveness and liquidity provider. It is also a trust assumption for spend VTXOs that have not yet been refreshed.

== Implementations ==

Bark is an open-source Ark client and server. No consensus change in [[Bitcoin Core]] is required. Bark publishes Signet instructions. A 2026 paper on off-chain transaction batching describes a mainnet implementation. The protocol is still evolving, and readers should not infer a mature public network from the existence of that implementation.

== See also ==

* [[Lightning Network]]
* [[Lightning service provider]]
* [[CHECKTEMPLATEVERIFY]]
* [[MuSig2]]
* [[Covenant]]

== External links ==

* [https://ark-protocol.org/ Ark protocol overview]
* [https://ark-protocol.org/intro/connectors/index.html Connectors]
* [https://second.tech/docs/learn/forfeits Bark forfeits, hash locks, and connectors]
* [https://second.tech/docs/learn/vtxo Bark VTXOs]
* [https://second.tech/docs/learn/rounds Bark rounds]
* [https://codeberg.org/ark-bitcoin/bark Bark implementation]
* [https://arxiv.org/abs/2605.20952 Ark: Offchain Transaction Batching in Bitcoin]

[[Category:Technical]]

Silent Payments

NotATether — Thu, 27 Aug 2026 12:36:19 GMT

create page

New page

'''Silent Payments''' ([https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki BIP 352]) is a protocol for static Bitcoin payment addresses. A receiver publishes one address. Each payment is sent to a unique [[Taproot]] output that an outside observer cannot link to that address. The protocol does not require interaction between sender and receiver, and it does not create an on-chain notification output.

A Silent Payments address is a [[Bech32m]] string. On mainnet it begins with <code>sp1q</code>. On test networks it begins with <code>tsp1q</code>. A typical mainnet address is 117 characters and encodes two public keys: a scan key and a spend key. The scan private key may be kept on an online device. The spend private key may be kept offline. The outputs created by the protocol are ordinary [[BIP341]] taproot outputs. The resulting transactions are not distinguishable on-chain as Silent Payments.

== Background ==

Using a new address for every payment avoids address reuse, which is an important [[privacy]] practice. Distributing a fresh address for each payment requires interaction. Publishing an [[xpub]] or reusing a single output script lets observers cluster incoming payments.

Earlier static-address designs used an on-chain notification so the receiver could find the payment. Notifications add cost, make the payment easier to fingerprint, and can allow the receiver to link multiple payments from the same sender.

Silent Payments derive a one-time taproot output from the sender's inputs and the receiver's published keys, so no notification output is required. The receiver (or a server the receiver trusts) must scan eligible transactions to detect payments. Scanning is practical for a full node. Light-client scanning is more expensive and is described as an area of research in BIP 352.

== How it works ==

The receiver publishes a pair of public keys <code>(Bscan, Bspend)</code>. The sender sums the private keys of the inputs used for shared-secret derivation, performs ECDH with <code>Bscan</code>, and includes a hash of the lexicographically smallest outpoint so that reusing the same input script does not produce the same destination. The resulting tweak is added to <code>Bspend</code> and encoded as a taproot output. Additional outputs to the same receiver increment a counter <code>k</code>.

The receiver recomputes the tweak using the scan private key and the summed input public keys, then checks whether the derived taproot key appears among the transaction outputs. After the first match, the receiver continues incrementing <code>k</code> until a derived key is not present.

Inputs that contribute to the shared secret are [[P2TR]], [[P2WPKH]], P2SH-P2WPKH, and compressed [[P2PKH]]. Inputs with several public keys, such as multisig, are excluded because a collaborator could change keys after the Silent Payment output was derived. Transactions that spend SegWit version > 1 are not scanned, so a later version of the protocol can introduce new rules without scanning the same transaction twice.

BIP 352 states that collaborative transactions (including some CoinJoin and MuSig/FROST constructions) are possible but not recommended, because there is no formal security proof unless all input keys belong to the same entity.

Optional labels tweak the spend key so the receiver can distinguish sources of payment. Label <code>m = 0</code> is reserved for change. Multiple labeled addresses that share a scan key are visibly related, so labels are not a method of maintaining separate identities.

== Implementations ==

Sending to a Silent Payments address and receiving to one are separate features. Receiving requires a scanner.

As of August 2026:

* [[Bitcoin Core]] does not include Silent Payments in a released wallet. A silentpayments module is present in libsecp256k1. Wallet work is tracked in [https://github.com/bitcoin/bitcoin/issues/28536 bitcoin/bitcoin#28536].
* Cake Wallet can send and receive (v4.18.0, May 2024). Scanning is performed on the device.
* Sparrow can send (v2.3.0, October 2025) and receive (v2.5.0, May 2026). Receiving typically uses a Silent Payments-capable Electrum server such as Frigate.
* Electrum does not have in-tree support. Pull request [https://github.com/spesmilo/electrum/pull/9900 #9900] was declined in favor of an external plugin. A send-only plugin exists.

Hardware signing support depends on the device. Related PSBT fields are specified in BIP 375.

== See also ==

* [[Privacy]]
* [[Taproot]]
* [[Bech32]]
* [[PayJoin]]
* [[CoinJoin]]

== External links ==

* [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki BIP 352 (version 1.1.1, April 2026)]
* [https://github.com/bitcoin/bips/blob/master/bip-0352/send_and_receive_test_vectors.json Test vectors]
* [https://github.com/bitcoin/bitcoin/issues/28536 Bitcoin Core tracking issue]

[[Category:Privacy]]
[[Category:Technical]]

Comparison of mining pools

Johnyto16 — Thu, 27 Aug 2026 12:32:59 GMT

Operational Pools

← Older revision		Revision as of 12:32, 27 August 2026
Line 60:		Line 60:
	\| [[OCEAN]] \|\| {{flag\|us\|label=1}}\|\| Small \|\| No \|\| TIDES \|\| {{SharedFees}} \|\| \|\| 0% \|\| {{Yes}} \|\| {{No}}		\| [[OCEAN]] \|\| {{flag\|us\|label=1}}\|\| Small \|\| No \|\| TIDES \|\| {{SharedFees}} \|\| \|\| 0% \|\| {{Yes}} \|\| {{No}}
	\| 2011-04-27 \|\| Dynamic \|\| \|\| [http://ocean.xyz link]		\| 2011-04-27 \|\| Dynamic \|\| \|\| [http://ocean.xyz link]
			\|-
			\| [[NexusPool]] \|\| {{flag\|us\|label=1}} \|\| Small \|\| No \|\| Solo \|\| None (100% to finder) \|\| 0% \|\| 0% \|\| {{Yes}} \|\| {{No}} \|\| 2026-06 \|\| Solo \|\| [http://bitcointalk.org/index.php?topic=5591448 link] \|\| [https://nexuspool.io/ link]
	\|-		\|-
	\|}		\|}

CurrencyFair

NotATether — Tue, 25 Aug 2026 12:36:58 GMT

add ngn

← Older revision		Revision as of 12:36, 25 August 2026
Line 78:		Line 78:
	\|-		\|-
	\| Country name \|\| Currency \|\| Symbol \|\| Notes / Alternate		\| Country name \|\| Currency \|\| Symbol \|\| Notes / Alternate
			\|-
			\| Nigeria \|\| Nigerian naira \|\| NGN \|\|
	\|-		\|-
	\| South Africa (ZAF) \|\| South African rand \|\| ZAR \|\|		\| South Africa (ZAF) \|\| South African rand \|\| ZAR \|\|

User talk:Justina1995

NotATether — Tue, 25 Aug 2026 12:34:15 GMT

currencyfair edit

New page

== CurrencyFair edit ==

Hi, your proposed edit for [[CurrencyFair]] would overwrite the table heading, so I rejected the edit and performed the modification myself.

--[[User:NotATether|NotATether]] ([[User talk:NotATether|talk]]) 12:34, 25 August 2026 (UTC)

Comparison of mining pools

Johnyto16 — Tue, 25 Aug 2026 12:29:47 GMT

Operational Pools

← Older revision		Revision as of 12:29, 25 August 2026
Line 47:		Line 47:
	\| [[P2Pool]] \|\| Global (p2p) \|\| Small \|\| Merged mining can be done on a "solo mining" basis <ref name="solomm"/> \|\| PPLNS \|\| {{SharedFees}} \|\| \|\| \| 0% \|\| {{Yes}} \|\| {{No}}		\| [[P2Pool]] \|\| Global (p2p) \|\| Small \|\| Merged mining can be done on a "solo mining" basis <ref name="solomm"/> \|\| PPLNS \|\| {{SharedFees}} \|\| \|\| \| 0% \|\| {{Yes}} \|\| {{No}}
	\| 2011-06-17 \|\| User<ref name="changeable"/> \|\| [http://bitcointalk.org/?topic=18313 link] \|\|		\| 2011-06-17 \|\| User<ref name="changeable"/> \|\| [http://bitcointalk.org/?topic=18313 link] \|\|
	\|-
	\|-
	~~\| [[Poolin]] \|\| Global \|\| Medium \|\|[[NMC]] VCASH \|\| FPPS \|\| {{SharedFees}} \|\| 2.5% \|\| 0% \|\| {{Yes}} \|\| {{Yes}}~~
	~~\| 2017-10-01 \|\| Dynamic \|\| [https://bitcointalk.org/index.php?topic=5169994.0 link] \|\| [https://poolin.com/ link]~~
	\|-		\|-
	\| [[SBICrypto Pool]] \|\| Global \|\| Medium \|\| No \|\| FPPS \|\| {{SharedFees}} \|\| 0% \|\| 0% \|\| {{Yes}} \|\| {{Yes}}		\| [[SBICrypto Pool]] \|\| Global \|\| Medium \|\| No \|\| FPPS \|\| {{SharedFees}} \|\| 0% \|\| 0% \|\| {{Yes}} \|\| {{Yes}}
	\| 2020-11-03 \|\| User<ref name="changeable"/>/Dynamic \|\| \|\| [https://sbicrypto.com/ link]		\| 2020-11-03 \|\| User<ref name="changeable"/>/Dynamic \|\| \|\| [https://sbicrypto.com/ link]
	\|-		\|-
	\| [[Slush Pool]]		\| [[Slush Pool\|Braiins Pool]]<ref>In 2022 Braiins renamed Slush Pool to Braiins Pool. [https://braiins.com/blog/hashing-history-the-story-of-braiins Braiins]</ref>
	\| Global \|\| Medium \|\| [[NMC]] \|\| Score \|\| {{SharedFees}} \|\| \|\| 2% \|\| {{Yes}} \|\| {{No}}		\| Global \|\| Medium \|\| [[NMC]] \|\| Score \|\| {{SharedFees}} \|\| \|\| 2% \|\| {{Yes}} \|\| {{No}}
	\| 2010-11-27 \|\| User<ref name="changeable"/> \|\| [http://bitcointalk.org/?topic=1976 link] \|\| [https://~~slushpool~~.com/ link]		\| 2010-11-27 \|\| User<ref name="changeable"/> \|\| [http://bitcointalk.org/?topic=1976 link] \|\| [https://pool.braiins.com/ link]
	\|-		\|-
	\| [[Luxor]] \|\| {{flag\|us\|label=1}}\|\| Medium \|\| No \|\| FPPS & PPS \|\| {{SharedFees}} \|\| 2% \|\| 0% \|\| {{Yes}} \|\|		\| [[Luxor]] \|\| {{flag\|us\|label=1}}\|\| Medium \|\| No \|\| FPPS & PPS \|\| {{SharedFees}} \|\| 2% \|\| 0% \|\| {{Yes}} \|\|
Line 126:		Line 122:
	\| [[Multipool]] \|\| {{flag\|us}}{{flag\|eu}} \|\| Small \|\| [[NMC]] \|\| Score \|\| {{SharedFees}} \|\| \|\| 1.5% \|\| {{Yes}} \|\| {{No}}		\| [[Multipool]] \|\| {{flag\|us}}{{flag\|eu}} \|\| Small \|\| [[NMC]] \|\| Score \|\| {{SharedFees}} \|\| \|\| 1.5% \|\| {{Yes}} \|\| {{No}}
	\| 2012-03-15 \|\| User \|\| [https://bitcointalk.org/index.php?topic=311067.0 link] \|\| [https://www.multipool.us/ link]		\| 2012-03-15 \|\| User \|\| [https://bitcointalk.org/index.php?topic=311067.0 link] \|\| [https://www.multipool.us/ link]
			\|-
			\| [[Poolin]]<ref>Ceased all mining operations July 10, 2026; filed for Chapter 11 bankruptcy July 22, 2026. [https://www.coindesk.com/markets/2026/07/24/poolin-was-bitcoin-s-biggest-mining-pool-and-now-it-s-filing-for-bankruptcy CoinDesk]</ref> \|\| Global \|\| Medium \|\|[[NMC]] VCASH \|\| FPPS \|\| {{SharedFees}} \|\| 2.5% \|\| 0% \|\| {{Yes}} \|\| {{Yes}}
			\| 2017-10-01 \|\| Dynamic \|\| [https://bitcointalk.org/index.php?topic=5169994.0 link] \|\| [https://poolin.com/ link]
	\|-		\|-
	\| [[ZenPool.org]] \|\| {{flag\|us\|label=1}}\|\| Large \|\| ZenCash \|\| PPLNS \|\| {{SharedFees}} \|\| 1% \|\| 0% \|\| {{Yes}} \|\|		\| [[ZenPool.org]] \|\| {{flag\|us\|label=1}}\|\| Large \|\| ZenCash \|\| PPLNS \|\| {{SharedFees}} \|\| 1% \|\| 0% \|\| {{Yes}} \|\|
Line 131:		Line 130:
	\|-		\|-
	\|}		\|}


	== SPV Mining / Old Bitcoin Core ==		== SPV Mining / Old Bitcoin Core ==

Full node

Fiach — Tue, 25 Aug 2026 12:29:20 GMT

Removing mention of knots as another Bitcoin implementation as it is soon to no longer be maintained.

← Older revision		Revision as of 12:29, 25 August 2026
Line 1:		Line 1:
	Any computer that connects to the Bitcoin [[network]] is called a '''node'''. Nodes that fully verify all of the rules of Bitcoin are called '''full nodes'''. The most popular software implementation of full nodes is called [[Bitcoin Core]], its latest release can be found [https://github.com/bitcoin~~/bitcoin/releases on the github page]. Another less popular software implementation of full nodes is called [[Bitcoin Knots]], its latest release can be found [https://github.com/bitcoinknots~~/bitcoin/releases on the github page].		Any computer that connects to the Bitcoin [[network]] is called a '''node'''. Nodes that fully verify all of the rules of Bitcoin are called '''full nodes'''. The most popular software implementation of full nodes is called [[Bitcoin Core]], its latest release can be found [https://github.com/bitcoin/bitcoin/releases on the github page].

	[[File:BitcoinCore-node.jpg\|thumb\|upright=1\|The main window of Bitcoin Core]]		[[File:BitcoinCore-node.jpg\|thumb\|upright=1\|The main window of Bitcoin Core]]