Why doesn't this transaction get included?

[Mitchell]

Hello everyone,

4 hours ago I did a transaction with BTC0.0025 fee to persons who requested a payment from my faucet (TX can be found here). Normally these get confirmed very quickly, but this time it takes such a long time. The transaction isn't to big, fee's are high enough and all the inputs are confirmed.

Can anyone shed a light on this, because I don't get it.

EDIT: Could a pool owner please include this transaction (and the other not confirmed transaction)? It would be much appreciated and I think my users would love you for it.

[1714006475]

1714006475

[Rluner]

These things take time depending on how old or new the BTC were and other factors too, that you sent. This link should explain:-

https://en.bitcoin.it/wiki/Transaction_fees

Also the following link maybe helpful too:-

https://bitcointalk.org/index.php?topic=322194.msg3469117#msg3469117

[deepceleron]

Maybe miners have increased the value of what they consider spam transactions themselves. BTC amounts:

0.00005450
0.00005450
0.00005500
0.00005500
0.00005550
0.00005550
0.00005550
0.00005600
0.00005650
0.00005650
0.00005650
0.00005650
0.00005650
0.00005700
0.00005700
0.00005750
0.00005750
0.00005750
0.00005750
0.00005850
0.00005900
0.00005935
0.00005950
0.00005950
0.00006050
0.00006300
0.00006300
0.00006400
0.00006500
0.00006500
0.00006550
0.00006600
0.00006800
0.00006805
0.00006850
0.00007000
0.00007000
0.00007300
0.00007750

[Mitchell]

Maybe miners have increased the value of what they consider spam transactions themselves. BTC amounts:

-snip-

Well, I never had that problem, so that would be odd...

[warut]

Hello everyone,

4 hours ago I did a transaction with BTC0.0025 fee to persons who requested a payment from my faucet (It can be found here). Normally these get confirmed very quickly, but this time it takes such a long time. The transaction isn't to big, fee's are high enough and all the inputs are confirmed.

Can anyone shed a light on this, because I don't get it.

I'm very curious to know too, especially since my payout is also in that tx.

The fee is higher than the default. All outputs are larger than 54.3 uBTC. There is no reason why it shouldn't get confirmed.

[warut]

These things take time depending on how old or new the BTC were and other factors too, that you sent. This link should explain:-

https://en.bitcoin.it/wiki/Transaction_fees

Old or new BTC is relevant only when you want to send without fee.

Also the following link maybe helpful too:-

https://bitcointalk.org/index.php?topic=322194.msg3469117#msg3469117

That tx is different; it's delayed because the fee paid was less than the default.

[michagogo]

This transaction has two outputs (3 and 13) with a value of 0.00005450, which is below the dust threshold of 0.00005460 (yes, 0.00005460. The often-quoted value of 0.00005430 is a miscalculation.) Therefore, the transaction won't be accepted or relayed by unmodified satoshi clients at the default settings.

[Mitchell]

This transaction has two outputs (3 and 13) with a value of 0.00005450, which is below the dust threshold of 0.00005460 (yes, 0.00005460. The often-quoted value of 0.00005430 is a miscalculation.) Therefore, the transaction won't be accepted or relayed by unmodified satoshi clients at the default settings.

Gonna the threshold then. But still, that doesn't explain why my other transactions got accepted that fast, but not this isn't.

[Mitchell]

Would increasing the fee and pushing it again help?

[warut]

This transaction has two outputs (3 and 13) with a value of 0.00005450, which is below the dust threshold of 0.00005460 (yes, 0.00005460. The often-quoted value of 0.00005430 is a miscalculation.) Therefore, the transaction won't be accepted or relayed by unmodified satoshi clients at the default settings.

This fact is totally new to me. Thanks!

[dalek]

You can also specifically add nodes for miners that indiscriminately include any transactions, regardless of the dust limit:
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

[Mitchell]

You can also specifically add nodes for miners that indiscriminately include any transactions, regardless of the dust limit:
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

Well I use the BlockChain.info API so I don't think that is possible.

[deepceleron]

Would increasing the fee and pushing it again help?

No. This blocking rule is about the creation and sending of dust that is completely worthless to the recipient, dust that is more expensive to spend out of a wallet than to discard. They are now considered non-standard transactions, and will not be accepted into the transaction memory pool. History:

Bitcoin didn't anticipate that people would pay fees to spam the blockchain - we required a fee for anything below .01, and if you have a profit model you can pay that...

Payments need to be self-funding, that the recipient will have a net gain by receiving the payment after including retransmittal costs.

So then what is the definition of not making "economic sense to spend"?...  I would say it is a payment that as an input, when evaluated by minimum fee rules in aggregate with like inputs, would cost more to send in fees than the value of the payment. This is a payment likely to become an unspent TXO - for most it is cheaper to discard than to spend.

1 input: 257-259 bytes = minimum payment .00050001
2 inputs: 436-439 bytes = minimum payment .00025001
5 inputs: 976-980 bytes = minimum payment .00010001
6 inputs: 1157-9 bytes = minimum payment .00016668
8 inputs: 1514 bytes = minimum payment 0.00012501
39 inputs: 5848 bytes = minimum payment 0.00008975

So it looks like a good "receiving this payment will cost the recipient" threshold is any output that is less than 1/5 of minimum fee, from the examples, 20%-40% of minimum fee should be required.

The amount decided on was if the payment was three times smaller than the minimum fee. The final formula for exactly what is useless dust spam ends up being dependent on the construction of the particular sending transaction:

IsDust = TxOutAmount < 3 * MinRelayFeePerKB / 1000 * (TxOutBytes + 148)

https://github.com/bitcoin/bitcoin/pull/2577

Bitcoin design has the ability to recover hard drive space by pruning spent transactions. What you have created here is a transaction, that if a single recipient decides they can't spend their dust, has to be retained on every network node's hard drive forever.

This wouldn't be the first transaction in two days that blockchain.info has sent that is doomed.

[Mitchell]

So, you are basically saying that a Faucet should increase the minimum amount before someone gets a payout to a very high value? Because if so I might just quit using transactions and just do everything using PeerBet. (Transactions get dropped after a while, right?).

Note to self: You really really really have to read the white paper and all the technical details.

[Mitchell]

Could a pool owner please include this transaction (and the other not confirmed transaction)? It would be much appreciated and I think my users would love you for it.

[RoadTrain]

You should adjust your minimum output value to 5460 satoshis.

In case this tx is treated as non-standart by miners and is not in their mempools, you can safely double-spend it after dropping dust outputs or increasing their value (to 5460 satoshis).

Or just wait, I am sure there are miners that will include your tx in a block.

[Mitchell]

You should adjust your minimum output value to 5460 satoshis.

In case this tx is treated as non-standart by miners and is not in their mempools, you can safely double-spend it after dropping dust outputs or increasing their value (to 5460 satoshis).

Or just wait, I am sure there are miners that will include your tx in a block.

Yeah, I already changed that in my script. I set a minimum of 6000. I am going to wait for now and if I really have to I will double spend it with higher values.

[RoadTrain]

Did your double-spend succeed?

[Mitchell]

Did your double-spend succeed?

I fixed my double spend problem. It also removed all the unconfirmed transaction, so I will have to find a way to reimburse all the users who didn't get a payment.