Bitcoin Forum

What is the minimum transaction value to be accepted by the nodes?


EDIT:

I tested it ...

1. Took UTXO 2c88d249902586908e55116527ff8cb4c14975bd233cb93a2b759db43a3fe358 vout 0 and created several transactions. Each transaction had 1 input and 18 outputs with increasing values (+1 sat), so a whole range could be tested at once eg. 200 sats - 217 sats, if valid or not.

2. Broadcast the transactions via different providers. It wasn't accepted until 546 sat output. Below, you can see the error messages.

https://blockchair.com
result: Invalid transaction. Error: dust

https://blockstream.info
result: sendrawtransaction RPC error: {"code":-26,"message":"dust"}

https://btc.network
result: Not a valid transaction hash!

https://bitaps.com
result: Mempool accept test failed: dust

3. The first accepted transaction you can check here:

tx hash e849378d3aedb4152aad3ac71f0c15f44ed3e29c90b6e2c1b25a2c8d23d34d62 block 736,966
minimum 546 sats, 18 outputs, each +1 sat


I also wanted to know if it's 546 or 547 sats that is accepted. Now we know that it's 546 sats for non-segwit addresses.

:)




EDIT (2):


Tested it with a TX to the address bc1qwpc320c70sz7mf7v6vyu5v7lzjv3hlsa23d8ew (from a nice bitcointalk user  :) )

This time I made 3 transactions: 293 sats, 294 sats and 295 sats as I knew the limit 294 sats, but didn't know what was the accepted value.

Broadcast 293 sats transaction via same providers:

https://blockchair.com
result: Invalid transaction. Error: dust

https://blockstream.info
result: sendrawtransaction RPC error: {"code":-26,"message":"dust"}

https://btc.network
result: Not a valid transaction hash!

https://bitaps.com
result: Mempool accept test failed: dust


Broadcast 294 sats transaction ... accepted:

tx hash 42bd160a3a473cbe73c4178e126921b45697e810913c8bb21c610025462076bd block 737,081


Now we know that the lowest accepted value for segwit addresses is 294 sats.

 :)

IIRC, the current dust limit is 546 satoshi unless, of course, you're dealing with the lightning network.

Most nodes: 547 sat for legacy addresses, and a bit less when sending to Segwit.
It's quite useless to do, I've seen many transactions that pay more in additional fees than the dust is worth.

Thanks, yes I also thought > 546 but then I saw this today

transaction hash edc38bfb0ee694aa1cca1a050ad002ae390b5c865a8062fa5f8630a9cab014ad
0.00000473 BTC to bc1q25unhdrmc0vnkwgg0vjtf6xmny8g0vykek6j8a

I didn't know that Legacy and Segwit have different limits.

edited:

I am kind of confused, I thought nodes validate confirmed transactions, taken from the mempool and included into a block by miner for it to be confirmed and get validated by nodes.

Can a transaction not up to the minimum amount of bitcoin be broadcasted into the mempool, included into a block and got confirmed but later got invadated by nodes? I was thinking the transaction will never even be broadcasted into the mempool at all.

Nodes have a mempool filled with unconfirmed transactions, and miners run nodes too. Each node can decide whether or not to reject a transaction that hasn't been confirmed yet.
Most of them seem to agree you can't send dust.

Never mind me, node makes up the bitcoin network, even without running full node, no mempool.

Transactions which create outputs less than the dust limit are still valid transactions. Although you will have great difficulty trying to broadcast such a transaction, there is nothing which says it cannot be mined in to a block. The two most likely ways that this transaction ended up in a block was either that one or more nodes had altered their dustRelayFee setting to accept transactions which create smaller outputs, or a miner decided to include it directly in to the block they were mining.

Nodes verify both unconfirmed transactions, which they add to their mempool, and transactions included in the blocks they receive.

If a transaction is included in a block, but a node deems that transaction invalid, then the node will reject the entire block as invalid. Creating outputs less than the dust limit does not make a transaction invalid, however.

Tested it!

Read the first post (EDIT).

:)

I was 1 sat off :o

To complete the test, you should do the same to a Bech32 address. Sweeping from the dust inputs into a new address to make it interesting.

Blockexplorers are not nodes and they usually have weird criteria when relaying TXes as some of them are custom implementations, which may not conform to the rest of the network. One of the blockexplorers that I've tried before actually didn't allow me to push a SegWit non-dust transaction though the reference limit was lower than the 546 threshold. A more accurate representation would be to directly broadcast to the nodes on the network.

Tested it. Read: first post - EDIT(2).

Interesting!

This made me think of Muun, since they support lightning through submarine swaps, and in theory all your sats are on-chain:


I tested with a 293 sats invoice and it went through perfectly fine.

I'm not really sure what is actually happening behind the scenes though.

Most likely, the Lightning node is combining the final amount in the contract (your invoice) with its own sats to at least meet the minimum L1 tx size.

I recall from an earlier post though, that had Bitcoin source code in it that the 294-byte minimum segwit size applied at a 3000 sats/KB fee rate (i.e. 3 sats/byte). I am curious to figure out whether this minimum size would be even smaller if the fee sent was just 1 sat/byte (ditto for the legacy transactions).

It has nothing to do with the fee rates of a transaction.

The fees as stated in the code is actually referring to the dust relay fee instead of the actual transaction fee. This is a user-configurable parameter but the standard is kept at 3sat/byte to maintain the 546sat dust limit that was before the introduction of this dust relay fee. But yes, if the user changes the dust relay fee, then their node would see a different dust limit.

Lol, I thought the dust transaction would have been related to this topic. If I get another dust inputs, I can use them to buy half a day VPN :)

@LoyceV

I wanted to repeat the same test in 10 years and want to use these addresses. And the title of the test will be:
'Ten years ago dust, now a fortune'

 :)

But I support the 'half a day VPN' idea. One segwit dust was sent to bc1qwpc320c70sz7mf7v6vyu5v7lzjv3hlsa23d8ew, now I tested if 17 segwit dusts can be sent together, it worked. Think of it as the 18 dusts from the legacy addresses, sent as segwit dusts.

And half the fortune will be spend on fees.

It's now a week: do you want it?

Do the same to your legacy dust (https://blockchair.com/bitcoin/address/1FNqqWDVpJkMjkyuXdC7kikGWozY3oR1LM) :)

That is what I expected, but it hasn't moved yet (https://blockchair.com/bitcoin/transaction/e849378d3aedb4152aad3ac71f0c15f44ed3e29c90b6e2c1b25a2c8d23d34d62). I thought c7298be8c111422fd0bc3915d67451ea24fba9b3529126e4bf39ca5db94370ba (https://blockchair.com/bitcoin/transaction/c7298be8c111422fd0bc3915d67451ea24fba9b3529126e4bf39ca5db94370ba) was from you, but now I'm not sure anymore.

I don't know, but since the term "dust TX" is client-specific and not network protocol, the statement above cannot be accurate.

294 sats is the lowest transaction that the Bitcoin Core software can accept and less of it is considered a dust transaction, but does not mean that it is the lowest transaction that can be broadcast in the network?! ???

Overall, thanks for proving that such tx can be broadcast.

It could happen, but it's not very likely. Even if you connect to a node that accepts a lower dust limit, that node will also have the same problem so it can't propagate it to other nodes.

Maybe. Or maybe in the future the minimum fee rate is 1 sat/kvB rather than 1 sat/vB. Who knows? :)

294 sats is the smallest segwit output which Bitcoin Core will accept by default. It is defined here, in sats/kvB: https://github.com/bitcoin/bitcoin/blob/623745ca74cf3f54b474dac106f5802b7929503f/src/policy/policy.h#L54


Given an average segwit output could be spent in a minimum of 98 vbytes, then 98*3 = 294 sats.

However, nodes are free to change this limit if they want, and accept transactions which create much smaller outputs. They probably wouldn't be able to broadcast that transaction to other nodes (the majority of which use the default limit), but any miner using such a node to build a block would see such a transaction and would be free to include it. As I said above, such transaction are non-standard but are still perfectly valid.

This is another topic, but it's an interesting one. I'm sure we have a dedicated thread for this, but the question would be what to do if / when the minimum transaction size will be too large for everyday transactions or the minimum transaction fee of 1sat/vB will be in the dozens of dollars or something like that.
An easy answer would be that most transactions will be on some sort of off-chain network like Lightning or a sidechain of Bitcoin, but maybe there will be a softfork which allows to send smaller amounts and use lower fees (maybe in mSat denomination). But nobody knows yet; we can only discuss and introduce our ideas and suggestions to the developers whenever the topic / issue gets tangible.

The thing about fees is that they is set partly based on the price. For example in early days when the price was less than a dollar the fees were super high and at a fixed amount like 0.01BTC. Then suddenly it decreased a couple of times as the price went up and people were paying fixed 10k satoshis. As blocks were filled we started calculating them based on the size (sat/vb). It is reasonable to think in the future with drastic price rises we are going to decrease it further and start paying fraction of a satoshi per vbyte.

Keep in mind that with or without LN the on-chain fees are always going to be an important factor and they need to remain reasonable otherwise it will hurt bitcoin's utility.

A couple of years ago I read about the plan to lower the minimum fee to 0.1 sat/vbyte, but then fees went up again and it didn't happen.

LN can't really work if opening and closing a channel is very expensive, unless most people accept custodial wallets.

Yeah, it's been discussed before: https://github.com/bitcoin/bitcoin/pull/13922
I'm sure it will happen eventually, but there is no need for it at the moment.

Also, a good reply from Pieter Wuille about this here: https://bitcoin.stackexchange.com/a/100862

Sure, but while I wouldn't be willing to pay $5 as a fee to buy a $5 coffee with an on-chain transaction, I'd be happy enough to spend $5 on a fee to open a Lightning channel which would let me buy a $5 coffee every day for the next 10 years.

I don't really expect it to happen if the block size stays the same. I miss those days when I could broadcast up to 1000 byte with 0 fee, as long as one of the inputs was "mature" enough to qualify. I think it was called "medium priority" in Bitcoin Core, when destroying a certain number of coin days.

It's the first time I read about fees being spam protection against using the Bitcoin network as "cheap global broadcast system". I always thought it's only related to on-chain spam.

If you receive your salary on the same channel, that could work indeed. I just don't see many people investing reserving $18,000 to buy coffee for the next 10 years. Once they realize the total cost, they might just buy a coffee machine and a thermos theymos.

That's of little matter, in my opinion. What's making Lightning difficult is liquidity issues. First off, you can't just have one channel; routing will fail often. So, you need bunch of channels to lower those chances. How much money in each? The more the better. Open channels with who? Preferably with a large entity to lower the chances of routing fails and of insufficient liquidity.

If you don't want coffee, close the channel. If you don't want to close the channel, buy something else instead of coffee. You don't invest into anything neither literally nor figuratively.

1 sat/vB limitation only enforced by node, not by Bitcoin protocol. It can be solved easily by changing default minimum relay fee on Bitcoin full node implementation. But if 1 sat is deemed expensive for transaction fee, a fork will be needed.


At that time, people are lucky since miner still following Bitcoin Qt behavior to include fee-less transaction under certain condition. These days, miner simply prioritize profit.

Depends on how widespread adoption you imagine in the future, I suppose.

An analogy. I'm not suggesting I have a "coffee only" channel, but rather a channel I can open, close, rebalance, etc., a couple of times a year and use for daily spending. While regular on-chain transactions need to be cheap for small value transactions to still be viable, on-chain Lightning channel transactions don't need to be that cheap because they can scale. $5 for 1 transaction is too much; $5 for 1000 transactions is absolutely fine.

Interesting. At current fiat prices, that's about 8 cents. (BTC @ $29,500-ish) ... So if the price goes up to low 6 digits (around $295,000) then minimum dust is still worth below $1.

On L1, on-chain, I usually don't bother sending such small amounts anymore anyway. Maybe the core devs will lower the dust limit or the default dust limit in the future, they did it before when the "reasonable" small transaction was 0.01 BTC, then it became 0.001 BTC.

People do pay $5 in order to send $100 to other countries using whatever traditional fiat remittance service they can find but only because they don't know there are cheaper or more efficient ways now. Western Union or whatever bank is what they know.

I think Core devs would at least keep the minimum dust representable in cents.

That is to say, you should always be able to send at least $.01 using L1. So if a sustained price raise keeps the minimum dust as a couple dimes for a while, that's when I think they will take an action to lower the dust limit with a soft fork.

Dust limit is not a consensus rule to need any kind of fork. It is a "client based preference" that the devs should let the user set in a Settings window so that they can change it based on the market situation on their own without needing to upgrade to the new version to change it.