WARNING! Bitcoin will soon block small transaction outputs

[gweedo]

Good step towards lowering spammy transactions like SatoshiDice, which is idiot tax anyways. If you want to risk your coin for more coin, then look at an even odds bitcoin lottery, like http://www.satoshisploder.com

Your creating the same exact transactions as Satoshi Dice LMAOOOOOOOOOOOO What?

[1714174820]

1714174820

[1714174820]

1714174820

[1714174820]

1714174820

[1714174820]

1714174820

[1714174820]

1714174820

[1714174820]

1714174820

[marcus_of_augustus]

So link to this Gaving "IThinkImUSAPresident" Andresen guy comment.
https://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17141937

Bitcoin is not appropriate for transactions less than a penny or three.

rant scrubbed out here ...

You omitted the rest of Gavin's comment that succinctly points towards the technical reasons why this change is necessary now and timely ... (to suit your own agenda?)

Bitcoin is not appropriate for transactions less than a penny or three.

If Moore's Law continues to hold, then one day it might be.

That is all out of scope for this pull request; if we do nothing, then we are stuck with MIN_RELAY_TX_FEE=0.0005 BTC.

[Daily Anarchist]

That is for miners only not the users. So yeah guess you didn't read.

It changes the behavior all around, but if you create transactions miners won't mine you won't be too happy.

It creates changes that SOME miners won't mine, right? Nothing wrong with that. Hell, a miner could right now charge 1 BTC fee per transaction if he wants. It just means no transactions will go through on the blocks he mines. I'm okay with that.

You're okay with miners being rewarded for not confirming any transactions?

Yes. But if they do those miners won't get any fee money, which means they'll make less money than other miners, which means they'll lose in the long run.

[GoldenWings91]

The amount of misinformation is mind boggling. Currently if you want to set the minimum tx fee and minimum relay fee you have to edit the source code and compile it. This pull request will now allow you to set the fees by invoking a command (-mintxfee -minrelayfee ) without having to compile the program each time. The default value is set to 54.3uBTC witch you can change to whatever you like.

[Bitcoinm]

Can anyone estimate how this will effect the number of transactions in the future?

[🏰 TradeFortress 🏰]

Can anyone estimate how this will effect the number of transactions in the future?

It shouldn't have much effect. SD and etc will simply just send 5430 satoshis or so.

[SgtSpike]

I previously spoke out against this.  Now that I know it is simply a default, and the mintxrelay is an optional setting, I am fine with the change.

[Daily Anarchist]

I previously spoke out against this.  Now that I know it is simply a default, and the mintxrelay is an optional setting, I am fine with the change.

Hear, hear!

[JamesTaylor]

To everyone saying that this is good because it lets you do something that you had to recompile the code itself to do it before, I'll let you know that what people is complaining about is not the fact that the amount can be changed but the fact that the default value is not only arbitrary but inappropriate.

Similar to what some internet browsers used to do with the default search engine.

[justusranvier]

the default value is not only arbitrary but inappropriate

That's a significant de-escalation at least from the original hysteria at least.

The next stage of enlightenment happens when you read Gavin's posts about how having a default value at all is temporary until the code for automatically calculating one based on a market mechanism between users and miners is ready.

[Crystallas]

The next stage of enlightenment happens when you read Gavin's posts about how having a default value at all is temporary until the code for automatically calculating one based on a market mechanism between users and miners is ready.

I can't wait for the next implementations that fix the problem of decentralized market TX rates. But related, while different, the blockchain needs to smart-purge obsolete blocks(transactions that have been both max confirmed and transfered completely from the block of origin.)

I remember this annoying issue with a dust-wallet I have. Its only purpose is for dust transactions. While I try to use my own concept of minimizing dust by using a dedicated dust-wallet, everyone has to realize that many BTC users have this very same problem. Many of them are newbies who are learning the complexities of the whole BitCoin world. Newbies are an important part of growing the BitCoin adoption.



I'm going to continue collecting dust transactions, others will also continue collecting dust transactions. So lets push for better solutions than centrally planned solutions, even if temporary(and right now, the word temporary is merely a promise as of 0.8.2, not the fact of the situation.)

[SgtSpike]

The next stage of enlightenment happens when you read Gavin's posts about how having a default value at all is temporary until the code for automatically calculating one based on a market mechanism between users and miners is ready.

I can't wait for the next implementations that fix the problem of decentralized market TX rates. But related, while different, the blockchain needs to smart-purge obsolete blocks(transactions that have been both max confirmed and transfered completely from the block of origin.)

I remember this annoying issue with a dust-wallet I have. Its only purpose is for dust transactions. While I try to use my own concept of minimizing dust by using a dedicated dust-wallet, everyone has to realize that many BTC users have this very same problem. Many of them are newbies who are learning the complexities of the whole BitCoin world. Newbies are an important part of growing the BitCoin adoption.



I'm going to continue collecting dust transactions, others will also continue collecting dust transactions. So lets push for better solutions than centrally planned solutions, even if temporary(and right now, the word temporary is merely a promise as of 0.8.2, not the fact of the situation.)

The best way to purge dust is to include the dust addresses in with your normal use wallet.  I've had plenty of dust go to my mainly used address, some as small as 3 satoshis, but they've all been spent at one time or another with larger BTC outputs, automatically.  At one time, I looked at the unspent transactions, and had a dozen or two, but now, I only have 3 unspent outputs.  And I've never paid more than a 0.0005 BTC fee, either.

[Crystallas]

The best way to purge dust is to include the dust addresses in with your normal use wallet.  I've had plenty of dust go to my mainly used address, some as small as 3 satoshis, but they've all been spent at one time or another with larger BTC outputs, automatically.  At one time, I looked at the unspent transactions, and had a dozen or two, but now, I only have 3 unspent outputs.  And I've never paid more than a 0.0005 BTC fee, either.

That is one way to do it, but only for those who make enough big transactions to cover it.

[Matthew N. Wright]

Before commenting on this, I wanted to make sure I read the development discussion (the one that matters most).

Having read it, I am of the opinion that people here are brave enough to abandon working systems in the real world to hype up an experimental one with numerous flaws, yet aren't brave enough to accept compromise and would rather everyone else suffer.

Gavin admits that this is only a temporary patch and further work needs be done to uncover the true nature of the problems. His patch does seem to fix some problems, for now. When those problems are no longer problems the patch can be undone. Wait until Gavin refuses to remove the patch later when it's no longer needed before crying fork.

"ACK"

[Realpra]

This must be blocked.

Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

[Matthew N. Wright]

This must be blocked.

Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

HTML is a design protocol and is referenced client-side only. Bitcoin is a distributed transaction protocol requiring databases. In relation, HTML has never had a minimum content limit, but websites have. Look up HTTP HEADERS or TCP/IP stack and you'll understand. There are minimum requirements for data to be considered data, and maximums for all real world solutions to storage.

Would you also be against changing the TCP/IP protocol from the ground up to fix, once and for all, IP spoofing, DDoSing, etc? Change is only a bad thing when it's bad.

If IBM creates a new quantum storage drive that can hold all the information in the universe and Google makes FTTH a standard down to every village on the planet, this won't be such a problem anymore.

[gmaxwell]

This must be blocked.
Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

... Bitcoin _is_ limits, without limits it would be worthless.

[noedaRDH]

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?

And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

[gweedo]

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?

And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

Short you have no control, cause it is really a mining thing. So if the majority of miners hashing power like the change, it then sticks. The only way to break revert is to get the miners to revert.

[gmaxwell]

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?
And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

Short you have no control, cause it is really a mining thing. So if the majority of miners hashing power like the change, it then sticks. The only way to break revert is to get the miners to revert.

GAH. Will you f@#$@# stop with the constant stream of misinformation?!

No "majority of miners hashing power" comes into this at all: It's not enforced against blocks.

Miners running with the defaults won't mine transactions with outputs of 54µBTC but will happily accept blocks that do and nodes running with defaults won't relay them.  Anyone can change their own defaults and presumably would if the value of Bitcoin changed dramatically.  Likewise new versions could have different defaults.  There is no dividing bitcoin issue at all, this is just node implementation behavior not a blockchain-protocol rule, and everything remains totally compatible.