Treat dust outputs as non-standard, un-hardcode TX_FEE constants

[keystroke]

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

So no transactions < 54.3 uBTC?

https://gist.github.com/gavinandresen/5453840

[1715459387]

1715459387

[lophie]

54.3 uBTC are the new Satoshi. Says the devs. What is next..... Link the fees to $0.01 and let the foundation pick the exchange rates for us?

[keystroke]

54.3 uBTC are the new Satoshi. Says the devs. What is next..... Link the fees to $0.01 and let the foundation pick the exchange rates for us?

It looks that way. I think it is a good idea compared to what we have now. But I have not seen it discussed here so I was surprised. However I guess github and the dev mailing list are the places where the real action happens these days.

[lophie]

So basically we can't say "there are plenty of liquidity! BTC are divideable to 8 decimal places!" anymore. Says the devs. Thank you for fornicating without creating a fork.

[lophie]

How about if all those are changed to just options in the clients? you know inside teh freaking bitcoin.conf. Then the devs could SUGGEST and not IMPOSE.

Just to add, Code being opensource does not make what they committed a "suggestion". They still can make them options to be added to bitcoin.conf without requiring whoever disagrees to patch and compile from source.

[gmaxwell]

How about if all those are changed to just options in the clients? you know inside teh freaking bitcoin.conf. Then the devs could SUGGEST and not IMPOSE.

Your ignorance is showing. Will you be apologetic when you realize that you look foolish here? Sadly, I expect not.

[lophie]

Lets discuss the amount a little shall we. Now assume a Bitcoin is now worth a million dollars. How come 54.3 uBTC would be now "acceptable to propagate"?

When Bitcoin started wasn't mining just lost power? You know before the pizza and stuff? Why didn't you hard code the limit to be 10kBTC then?

The scarcity of coins, block size, etc are all essential. Finding a way around one that does not cause a fork does not make it right if it solves a "current" problem.

I am pissed off because I am working on something called "colored addresses" which might be used as "pseudo identity verification" for any service paid with Bitcoin.

I really wish that my lack of enough information doesn't make me see how wise this magic lower limit is. But I don't think there is something justified this being hard coded and not a suggested added option.

[lophie]

How about if all those are changed to just options in the clients? you know inside teh freaking bitcoin.conf. Then the devs could SUGGEST and not IMPOSE.

Your ignorance is showing. Will you be apologetic when you realize that you look foolish here? Sadly, I expect not.

If I apologized for the ignorance would you get off your high heels and point the ignorance out?

[Peter Todd]

I am pissed off because I am working on something called "colored addresses" which might be used as "pseudo identity verification" for any service paid with Bitcoin.

Read this: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md#contract-blockchain-transactions

Note the section on 'contract value accounting' - coloured coin implementations with a fixed ratio of satoshi's to asset are a bad idea. Additionally, if your asset is worth less than the fees required to move it, don't bloat up the block chain with it.

[lophie]

I am pissed off because I am working on something called "colored addresses" which might be used as "pseudo identity verification" for any service paid with Bitcoin.

Read this: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md#contract-blockchain-transactions

Note the section on 'contract value accounting' - coloured coin implementations with a fixed ratio of satoshi's to asset are a bad idea. Additionally, if your asset is worth less than the fees required to move it, don't bloat up the block chain with it.

Thank you very much. I would be doing some reading.

[calian]

I await SatoshiDice's response.

[evilpete]

Not to mention the bitcoin fountains that have been spamming essentially unspendable 0.00001 btc outputs...

[TierNolan]

What about adding a way to poll nodes that will accept a given relay fee.

This would allow clients to poll all the nodes they are connected to, and try to find the lowest one.

This would (help) prevent nodes ending up surrounded by high relay nodes, even if there are enough nodes supporting a lower relay rule.

[TierNolan]

Also, doesn't  this kill coloured coins?  They would require a separate relay network.

Ideally, the relay rule should be based purely on tx fee paid.

[Gavin Andresen]

Y'all read the pull request, yes?

So: if you have a better suggestion for fixing the problem of new users wasting lots of time gathering tiny drips and drabs of bitcoins, and then getting upset when they can't spend them (because it costs more in fees that they are worth), I'm open to suggestions.

RE: "what about when bitcoins are worth a million dollars apiece"

Umm, that's what the "un-hardcode TX_FEE constants" part is all about?

RE: trolling about Foundation setting the fee:

Go back under your rock, please. This pull request is the first step towards a market between miners (who want higher fees) and merchants/users (who want lower fees, but also want their transactions confirmed). Miners can already control what fees they accept, this pull lets users control (very clumsily, improvements on the road map) the fee they are willing to pay.

[TierNolan]

So: if you have a better suggestion for fixing the problem of new users wasting lots of time gathering tiny drips and drabs of bitcoins, and then getting upset when they can't spend them (because it costs more in fees that they are worth), I'm open to suggestions.

Ideally, people would pay for the costs they impose.  At the moment, the 2 costs are UTXO set size and storage in the blockchain.

These aren't actually miner costs.  With a maximum block size, they would inherently charge per MB, but that isn't because MBs cost them.  It is an artificial market to encourage mining.  The actual cost of mining large blocks falls on the network as a whole (miners and verification nodes alike).

For people who are willing to trust that all blocks more than X deep are secure, then all they need to store on their hard drive is the UTXO set.

I would suggest that as long as a transaction has a large enough transaction fee per kb and has at least as many inputs as it has outputs, it should be relayed.  This transaction will either shrink the UTXO set or keep it the same.

Coinbase transactions that have more than 1 output could be penalized, if it is critical to keep the UTXO set low.  Maybe they are only relayed/count if they meet 0.9 times the standard threshold.

[Come-from-Beyond]

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

The community ought to boycott these changes.

[Mike Hearn]

The changes make sense. Right now Bitcoin has a large variety of what we call "magic numbers". They're just arbitrary choices that may have made sense at some point but aren't guaranteed to make sense in future. For the case of fees, Gavin's change is the first step towards removing these magic numbers and making them more dynamic.

Because the work is complex this change is only the first of several. It reduces the fee charged from the current level to reflect the higher exchange rate, and tweaks some other rules to be more internally consistent.

Eventually the goal is to have no hard-coded magic fee levels at all, so manual adjustments to reflect big exchange rate swings aren't needed any more. But we're not there yet.

[Peter Todd]

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

The community ought to boycott these changes.

You don't have to boycott the changes. Just ask mining pools to keep using the existing rules and setup some relay nodes that don't use them. A profit-driven miner has every reason to accept transactions based purely on what fee per KB they pay; UTXO costs per miner per transaction are tiny even if the overall cost to the network is large.

Mike Hearn suggested changing the protocol version as part of the pull-request. What you can do is setup a DNS seed that uses that change to find nodes that still use the existing rules to make it easy to find peers to relay your dusty transactions. Adding a new service bit would work even better. I run the testnet seed - ask me if you need any help.

edit: Added a suggestion to the pull request for a NODE_RELAYCOST service bit so nodes can advertise the minimum "cost" required to relay a transaction through them.

[gmaxwell]

How about if all those are changed to just options in the clients? you know inside teh freaking bitcoin.conf. Then the devs could SUGGEST and not IMPOSE.

Your ignorance is showing. Will you be apologetic when you realize that you look foolish here? Sadly, I expect not.

If I apologized for the ignorance would you get off your high heels and point the ignorance out?

You've got yourself a deal!   The base fee that this is set based on is configurable in bitcoin.conf, just as you were demanding.  The option won't be promoted at least initially because its relatively important that the network have roughly consistent settings (or transactions will get stuck when they get poor propagation due to being right on the boundary) and changing it on your own system won't change miners or your peers, but it's absolutely settable in order to avoid forcing everyone to update (or recompile) should people start selling cars for 1 BTC.