[TESTED IT] Minimum transaction value

[mynonce]

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):

To complete the test, you should do the same to a Bech32 address...

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.

 

[1714683574]

1714683574

[1714683574]

1714683574

[OmegaStarScream]

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

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

[LoyceMobile]

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.

[mynonce]

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

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:

Code:

     // "Dust" is defined in terms of dustRelayFee,
    // which has units satoshis-per-kilobyte.
    // If you'd pay more in fees than the value of the output
    // to spend something, then we consider it dust.
    // A typical spendable non-segwit txout is 34 bytes big, and will
    // need a CTxIn of at least 148 bytes to spend:
    // so dust is a spendable txout less than
    // 182*dustRelayFee/1000 (in satoshis).
    // 546 satoshis at the default rate of 3000 sat/kB.
    // A typical spendable segwit txout is 31 bytes big, and will
    // need a CTxIn of at least 67 bytes to spend:
    // so dust is a spendable txout less than
    // 98*dustRelayFee/1000 (in satoshis).
    // 294 satoshis at the default rate of 3000 sat/kB.

[Charles-Tim]

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.

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.

[LoyceMobile]

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.

[Charles-Tim]

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.

[o_e_l_e_o]

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

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.

I thought nodes validate confirmed transactions

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

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?

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.

[mynonce]

Tested it!

Read the first post (EDIT).

[LoyceV]

I also wanted to know if it's 546 or 547 sats that is accepted. Now we know that it's 546 sat.

I was 1 sat off

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.

[ranochigo]

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.

[mynonce]

To complete the test, you should do the same to a Bech32 address...

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

[nullama]

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

 

Interesting!

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

Regarding the lightning aspect of the recovery process, Muun uses super optimized submarine swaps to execute the lightning payments, both incoming and outgoing. This means that your funds are on-chain and thus recoverable by the mechanism I just described.

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.

[NotATether]

Interesting!

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

Regarding the lightning aspect of the recovery process, Muun uses super optimized submarine swaps to execute the lightning payments, both incoming and outgoing. This means that your funds are on-chain and thus recoverable by the mechanism I just described.

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).

[ranochigo]

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.

[LoyceV]

EDIT (2):

To complete the test, you should do the same to a Bech32 address...

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

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

[mynonce]

@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.

[LoyceV]

'Ten years ago dust, now a fortune'

And half the fortune will be spend on fees.

But I support the 'half a day VPN' idea.

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

I tested if 17 segwit dusts can be sent together, it worked.

Do the same to your legacy dust

Think of it as the 18 dusts from the legacy addresses, sent as segwit dusts.

That is what I expected, but it hasn't moved yet. I thought c7298be8c111422fd0bc3915d67451ea24fba9b3529126e4bf39ca5db94370ba was from you, but now I'm not sure anymore.

[hugeblack]

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

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.

[LoyceV]

but does not mean that it is the lowest transaction that can be broadcast in the network?!

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.