Topic: Treat dust outputs as non-standard, un-hardcode TX_FEE constants - page 2. (Read 3444 times)
April 30, 2013, 10:51:14 AM
The community ought to boycott these changes.
April 30, 2013, 10:30:47 AM
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.
April 30, 2013, 09:03:57 AM
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.
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.
April 30, 2013, 04:33:41 AM
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.
Ideally, the relay rule should be based purely on tx fee paid.
April 30, 2013, 04:05:37 AM
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.
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.
April 30, 2013, 02:47:34 AM
Not to mention the bitcoin fountains that have been spamming essentially unspendable 0.00001 btc outputs...
April 30, 2013, 01:05:39 AM
I await SatoshiDice's response.
April 30, 2013, 12:07:44 AM
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
https://github.com/bitcoin/bitcoin/pull/2577
So no transactions < 54.3 uBTC?
https://gist.github.com/gavinandresen/5453840
So no transactions < 54.3 uBTC?
https://gist.github.com/gavinandresen/5453840
Jump to: