Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

31

The definition of dust is client-specific and not a network rule. Bitcoin Core considers a transaction output to be dust, when its value is lower than the cost of spending it at the dustRelayFee rate. The default value for dustRelayFee is 3,000 satoshi per kilobyte, which results in the same dust values as the dust definition used before Bitcoin Core 0.15.0. ...


28

I'm not sure there is an exact definition of dust. The Armory client wiki says: Sending less than 0.01 BTC to any recipient — The network considers these small outputs to be “dust,” and discourages them by requiring a fee. If it was not discouraged, someone could take 1.0 BTC, and create 1,000,000 transactions of 0.000001 BTC each, for free, which would ...


16

My assumption is that the limitation is set by BlockChain.info itself, to protect the non-educated users for doing transactions which may take days to confirm. However raw Bitcoin protocol supports transaction with any amount and any fee. But because transactions are confirmed by miners they might not have economical incentive to care about dust-like ...


12

In the future, these small amounts of Bitcoins may be worth more. Right now, they're not worth the cost to transfer them. Bitcoin payments are a shared, public resource.


11

The dust limit in 0.14.0+ is set by a value called the dustRelayFee. This is separate from the minRelayTxFee although it has the same default value of 1 satoshi/byte. That is what is used to calculate dust now, and the dust calculation is still the same as before. So the default dust limit in 0.14.0+ is 546 satoshis. You can configure the value you set for ...


8

A deanonymizing dust attack works by sending dust to large amounts of addresses. The assumption is that when people send transactions/perform consolidations in the future, dust from multiple addresses will be grouped into a single transaction, thus revealing many addresses controlled by a single entity, since the dust would be swept in a single tx. (this ...


7

Such transactions will be subject to fees. You can read about the fee schedule here. The fees apply if the transactions send a small amount of coins, or send the same coins over and over (giving the transactions a low priority score). The fee is set at BTC 0.0001 per 1000 bytes. Thus someone who wants to spam the block chain with 10 MB will have to pay ...


6

I do not think there is anything to reach consensus on. very small payments (in relation to the transaction fees) they belong to neither (some developers will create a micro-payment solution on the main chain and other on side chains); both are viable and it depends on the application


6

Bitcoin-ABC (the reference implementation of Bitcoin Cash) is a fork of bitcoin core, there are no big changes to the settings. so bitcoin cash dust limit is exactly the same as Bitcoin which is 546 Satoshi. To make sure you can review Bitcoin-cash-ABC/transactions_test/ file code on GitHub line 546 And on transactions file here /** * "Dust" is defined ...


5

To understand 'dust' you must understand a few things: Firstly, a UTXO is an unspent transaction output. This is essentially a piece of bitcoin somewhere on the blockchain that is unspent. To create a transaction, 1 or more UTXOs are used to form the inputs, and 1 or more UTXOs are "born" in the process. After the transactions are confirmed, the UTXOs that ...


5

Bitcoin Core doesn't use an oldest-first selection but a more complex solver, it will probably end up spending outputs you don't want to in this particular case. You can do manual selection of the outputs you want to spend using the Coin Control section of the advanced GUI, which will let you ignore the dust if you don't want to spend it.


4

You're doing it wrong if your service generates thousands of dust-sized outputs. You need to consolidate your outputs as you go. I assume that a transaction under your current model is like this: Input (x1): Payer Address (X BTC) Outputs (x3): Payee Address (Y BTC) Service Wallet Address (100 satoshis) Payer Change Address (X - Y - 0.00000001 BTC) What ...


4

Anything lower than 5460 satoshis is currently considered dust, that bloats the blockchain, while transferring a value that is lower than what it costs to store the resulting output on disk. From the bitcoinj source: Any standard (ie pay-to-address) output smaller than this value (in satoshis) will most likely be rejected by the network. This is ...


4

Perhaps only for other dust sized transactions with minimal fees. Dust transactions with small fees are low priority and are NOT guaranteed to be confirmed in the order the transaction was placed but rather by the priority. So lets say there is a backlog of 1 million dust transactions, I could create a transaction using 1 output for 0.01 and include a fee of ...


4

You are correct that small payments would be a liability in the case of uncooperative nodes in a channel. I also believe you are correct that when the values get small enough, the trust-less nature of a channel breaks down. Although a 1 satoshi transaction is possible, at some point the cost of the transaction that closes the channel is higher than the ...


4

Yes. Such transactions are valid and standard.


4

To add to Raghav's answer: Practically, as a typical user, it can be difficult to deal with a dust attack. There is no way to stop or disallow the receiving of a transaction, so the user can only react to the attack after it has occurred. The good thing is, by taking the proper actions a user can easily and effectively mitigate against the attack. In a ...


3

This is spam. Point .


3

Yes, it is possible, and called transaction spamming. If you consider it cost effective spamming probably depends on how much it is worth to you to bloat the blockchain, already at a size measured in double-digit GBs, for everybody who keeps a complete copy! However, there are some possible mitigations already implemented. First of all, many clients delay ...


3

Yep. You'll notice increased fees and confirmation times eventually. Those amounts aren't super dusty though, even smaller transactions are the ones that will really bog you down.


3

There already is a limit of 5460 satoshi. It's unlikely any transaction smaller than this will be ever relayed or included in a block without colluding with a miner. https://github.com/bitcoin/bitcoin/blob/b78d1cdf82fb12cc0c8eb9049074b359b9589b7c/src/core.h#L153


3

The smallest transaction value is actually 0 as you are allowed to create 0 value outputs. However such transactions are considered non-standard and thus will not be relayed. But they are completely valid if they appear in a block. The smallest standard output value (also known as the dust limit) changes with the fee rate. The dust limit for a given fee ...


3

The dust limit is not actually fixed, technically - it varies based on the type of output. 546 satoshis is simply the most commonly known one, for a p2pkh output. Being the longest-lived output type, I suspect some wallets/blog posts/literature might treat it as a hard coded dust limit. As to how to arrive at 546 satoshis, we must first know what "dust" ...


2

They won't be lost. But it won't be easy to get them recovered. The wiki page on Transaction Fees mentions the following: A transaction may be safely sent without fees if these conditions are met: It is smaller than 10,000 bytes. All outputs are 0.01 BTC or larger. Its priority is large enough (see the Technical Info section below) So if ...


2

I have not tried it myself, but Peter Todd has a python script called dust-b-gone.py https://github.com/petertodd/dust-b-gone


2

why not do include such dust, so that spammers are harmed economically and stop doing it? I'm still not sure that would be enough to prevent this kind of spam activity. Even if these transactions were committed to the blockchain, 100,000,000 such broadcasts could be made from 1 BTC, that's a lot of reach for $700.


2

As amended, your calculations look essentially correct to me. (The total time will actually be worse, since you are competing with all other users of the network for block chain space. And some miners enforce a smaller block size limit - in the default client I think it is 350K.) So I suggest that you don't do that :-) As far as I know, Bitcoin was never ...


2

There is no minimum amount. You can send 0.00000001 btc and even 0.0 btc without fees and there is a possibility that this transaction would be mined by some miner. But the probability is very low, because "standard nodes" (by bitcoin devs) do not relay such transactions. You should add a fee if you want to send less than 0.00005xxx (I do not remember the ...


2

If your proposed transaction is to have an input of BTC 1.00000001, one output of BTC 0.9999 and a change output of BTC 0.00000001 (leaving BTC 0.0001 as a fee), then yes, most clients will reject it under the dust rule. Bitcoin Core's rule is to refuse transactions with any output that is too small - the precise details are a little complicated, but ...


2

Your transaction (1.00000001 ===> 0.99990000 transfer + 0.00010000 fee + 0.00000001 change) will be valid. But it is not guaranteed that other nodes will pass your transaction. May be yes, may be no. Modern referral clients do not relay such transactions, because developers hate dust and spam. But there are nodes which relay such transactions and there are ...


Only top voted, non community-wiki answers of a minimum length are eligible