WARNING! Bitcoin will soon block small transaction outputs

[Daily Anarchist]

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.

I don't think this is true. If miners refuse to upgrade it won't cause a fork. It just means that if somebody DOES send a 1 satoshi transaction that it won't get into the blockchain until a miner who allows it mines a block. I don't think this is a winner take all scenario.

Don't get me wrong, I think it's a terrible idea to raise the minimum tx amount, but that's strictly a miner's choice. It's not either/or, it's both.

[gweedo]

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.

I basically said the same thing, I don't know where my mis-information is?

I don't think this is true. If miners refuse to upgrade it won't cause a fork. It just means that if somebody DOES send a 1 satoshi transaction that it won't get into the blockchain until a miner who allows it mines a block. I don't think this is a winner take all scenario.

I didn't say it would cause a fork

[gmaxwell]

I basically said the same thing, I don't know where my mis-information is?

So if the majority of miners hashing power like the change, it then sticks.

^ right there.

Has nothing to do with a majority of hashing power. If, for example, 10% of hashing power were under the old rules (or some alternative anti-spam rules that still allowed very small outputs under some conditions) then you'd expect 1:10 blocks to include transactions paying the small amounts.

[gweedo]

I basically said the same thing, I don't know where my mis-information is?

So if the majority of miners hashing power like the change, it then sticks.

^ right there.

Has nothing to do with a majority of hashing power. If, for example, 10% of hashing power were under the old rules (or some alternative anti-spam rules that still allowed very small outputs under some conditions) then you'd expect 1:10 blocks to include transactions paying the small amounts.

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

[jgarzik]

1) I note the distinct lack of discussion surrounding https://bitcointalk.org/index.php?topic=130450.0 and its pull request.

2) This issue certainly deserves better communication, but think the trolling (reddit/bitcointalk) by @johndillon was premature and exaggerated, because there is still plenty of time and opportunity in the release cycle for comments.  Usually the time prior to -rc1 release is used to write the communications that appear in -rc1.  The -rc1 release announcement then describes the changes, including rationale and impact.

-rc1 release initiates a phase of public testing and comment.  If the community really dislikes a particular change, this testing phase is yet another opportunity to make that known.

3) Most importantly...

The vast majority of remote workers (miners) do not seem to care at all about mining policies, in practice.  Pools' mining policies are incredibly opaque, few miners show deep interest in mining policy, and few pool operators show much interest in deep thinking about mining policies, transaction selection, and various economic incentives.  Even a lot of smart, engaged pool operators wind up preferring unmodified (or close to it) bitcoind for reasons of reduced complexity.

Therefore, just wanting -- quite rationally -- to get paid for mining, it is the sad reality that the block subsidy (currently 25.0 BTC) reduces transaction fees to the economic equivalent of statistical noise.  The long term cost of generating and storing economically worthless transaction outputs is simply not transmitted to users or miners.  Nor, really, is the short term cost.  The economic signalling of the block subsidy drowns the rest out.

The cost is currently borne entirely by "the cloud", the all-volunteer P2P network of full nodes.  The only modicum of behavior signalling we see there is a decreasing number of full nodes, and an increasing amount of P2P traffic.

What does all this add up to?  The answer is lies in the free market.  Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners.

These hardcoded anti-spam limits have existed for years, originally starting out at 0.01 BTC.  Transactions have always been filtered.  Anything outside a small set of "standard" transactions are deemed "non-standard", and will be filtered (not relayed).  Again, policy has been in place for years.

The fee limits were lowered over time, but still hardcoded.  This latest change makes this limit configurable, moving one step closer to the goal of users being able to react rapidly to changes in miner policy or bitcoin value.  One step closer to a freer market.

Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it.  This rule self-adjusts over time, as the "tx fee required to send" changes over time.  In a dynamic fee market, it might change a lot.

It is unavoidable that tiny transactions worth fractions-of-a-penny may be easily abused for data transmission and storage.  We have already been burdened with megabytes worth of wikileaks data, GPG encrypted data, and the PGP fingerprint strong set, so this is not a theoretical problem.  These files are stored as bitcoin transactions with values around 0.00000001.

[fluffypony]

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!

No, but HTTPds always implement limits. My nginx config has size limits on the request header and size limits on the body. There are security concerns around unmitigated data - why should my HTTPd accept a 256kb GET? HTML is not a communications methodology, it's merely a way of syntactically representing something visual. Limits would never be inherent in the HTML language constructs, but rather in the communications protocol. Incidentally, HTML does have many implied limits in the DOM - nesting levels and maximum JavaScript stack sizes and so on - based on the average user running with only a few hundred MB of free RAM and a relatively slow processor. Just because a poorly designed website with overly complex markup works on your core i7 with 16gb of RAM doesn't mean it'll work on my grandmother's Celeron with 2gb of RAM.

tl;dr - your analogy is flawed

[Dougie]

I don't understand this. This could ruin bitcoin for a lot of people.

[gmaxwell]

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

HUH?  Let me try to break this down:

> If a big mining pool

OKAY, I follow.

> changes to that

0.8.2 with this change, I assume, okay

> and starts getting a lot of blocks

Okay, well finding blocks is just a product of hash power and luck

> then obvious there

Where?!

> choosing to use that method of blocking dust

HUH?! Running this code has nothing to do with finding blocks.  I understand the words you are using but the way you are stringing them together is virtuoso rutabaga.

[gmaxwell]

I don't understand this. This could ruin bitcoin for a lot of people.

Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

[gweedo]

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

HUH?  Let me try to break this down:

> If a big mining pool

OKAY, I follow.

> changes to that

0.8.2 with this change, I assume, okay

> and starts getting a lot of blocks

Okay, well finding blocks is just a product of hash power and luck

> then obvious there

Where?!

> choosing to use that method of blocking dust

HUH?! Running this code has nothing to do with finding blocks.  I understand the words you are using but the way you are stringing them together is virtuoso rutabaga.

if you understand that is it, that is all I care, I am sorry my public schooling education has failed you.

[caveden]

By reading the description on GitHub I get the impression that every transaction with a single output below 54.3µBTC will be treated as non-standard, even if it carries other larger outputs, or if it carries lots of fees.

Is this correct?
Because it doesn't seem to make sense to me. Why should miners reject a transaction with 1 satoshi output which carry, say, 10mBTC as fee, but still accept transactions with no fees at all?

[gmaxwell]

if you understand that is it, that is all I care, I am sorry my public schooling education has failed you.

I think it's fantastic that you care deeply about Bitcoin, but I also think you're confused about whats going on— and as a result you're attacking other people who care deeply about Bitcoin and do a lot to protect it as well as attacking a beneficial change which will protect Bitcoin to the extent that it does anything at all.

I'm trying to decode what you're saying and I didn't respond that way with the intention of insulting you. I think if we were able to achieve productive communication you'd agree with me and wouldn't worry about this.

[gmaxwell]

By reading the description on GitHub I get the impression that every transaction with a single output below 54.3µBTC will be treated as non-standard, even if it carries other larger outputs, or if it carries lots of fees.
Is this correct?
Because it doesn't seem to make sense to me. Why should miners reject a transaction with 1 satoshi output which carry, say, 10mBTC as fee, but still accept transactions with no fees at all?

Correct. It's already the case that zero fee transactions can't have any outputs less than 0.01 BTC. The transactions intended to force-bitcoin-users-to-store-arbitrary-data typically have one large output (their change) and pay a single 0.0005 fee and then have many 1e-8 outputs each packing another 160 bits of storage data which can never be pruned.  The data storage transactions are distinguished from normal transactions in that their outputs are actually unspendable (though this can't be detected) so all funds send to them are lost forever (effectively donations to all Bitcoin users in the form of increase scarcity). Just increasing the fees on transactions would harm regular transaction users and the data-stuffers alike— while penalizing tiny output sizes has a special cost for data stuffing, since that value can't benefit the stuffer.

Miners accept transactions with no fees at all for the same reasons they always have: They aren't irrational, if they engaged in maximize-income-at-all-costs behavior and denyed all free transactions or processed anything with fees regardless of the impact on Bitcoin then the coins they're mining wouldn't be worth as much. The long term health and usability of Bitcoin is in their interests.

[gweedo]

if you understand that is it, that is all I care, I am sorry my public schooling education has failed you.

I think it's fantastic that you care deeply about Bitcoin, but I also think you're confused about whats going on— and as a result you're attacking other people who care deeply about Bitcoin and do a lot to protect it as well as attacking a beneficial change which will protect Bitcoin to the extent that it does anything at all.

I'm trying to decode what you're saying and I didn't respond that way with the intention of insulting you. I think if we were able to achieve productive communication you'd agree with me and wouldn't worry about this.

First off you didn't insult me, I can't structure sentences well at all, so I agree with you there. I feel on this board we are all here for bitcoin otherwise you would not be here as a bitcoin dev. So I don't feel I attacked anyone I would call that critiquing. Honestly some miners will move forward and upgrade some will not or who knows. I will agree with you on one thing we just have to wait for to play out... I still think it is censorship in some form.

[caveden]

By reading the description on GitHub I get the impression that every transaction with a single output below 54.3µBTC will be treated as non-standard, even if it carries other larger outputs, or if it carries lots of fees.
Is this correct?
Because it doesn't seem to make sense to me. Why should miners reject a transaction with 1 satoshi output which carry, say, 10mBTC as fee, but still accept transactions with no fees at all?

Correct. It's already the case that zero fee transactions can't have any outputs less than 0.01 BTC.

It doesn't make sense.
A 1 satoshi tx paying enough fees is certainly more interesting than a 1.000 BTC tx not paying anything.

The transactions intended to force-bitcoin-users-to-store-arbitrary-data

Great. First you set up a biased "press center", now you embed arbitrary judgement of value in the default client behavior. This is degenerating fast.

In case you don't get it - and you likely don't - it should not be up to you, or any developer, to decide how Bitcoin transactions should be used, or what purpose they fill. You're basically inserting a rule in the reference implementation whose motivation to be is an attempt to censor certain use cases of the protocol, simply because you believe the protocol should not be used for such. That's just not right. Of course that the mining activity must remain profitable, and fees to block spam are thus something reasonable. But censoring any output below X no matter how much fees it carries is not reasonable. It doesn't make sense. If somebody is paying fees to store arbitrary data in the blockchain, just let him be.


Will bitcoind also disconnect from nodes that don't respect this policy, à la FATCA style?

[Come-from-Beyond]

...
...
...

OVER THROW THE DEV TEAM, THEY CAN"T HANDLE THE POWER THEY HAVE!

Even with caps, Quote worthy. I thought exactly the same and was not sure how to express it. Who gave them the power? Are they even proved as good enough programmers? This should not be allowed with the main client the vast majority is using. Not at all. Community raise.

Here is the answer (https://github.com/bitcoin/bitcoin/pull/2577):

Qt and RPC both now tell the user why CreateTransaction fails, if it fails; Qt error reporting is a little wonky (try to send one satoshi, and you get two modal dialog boxes, one after the other; I don't care enough to try to fix that).

[muyuu]

I don't understand this. This could ruin bitcoin for a lot of people.

Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

Maybe gamblers (SD and similar) and small miners.

[🏰 TradeFortress 🏰]

I don't understand this. This could ruin bitcoin for a lot of people.

Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

Maybe gamblers (SD and similar) and small miners.

It would not ruin gamblers and small miners. It only really ruins colored coins somewhat.

[Come-from-Beyond]

If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue.

This is not a protocol change.

This is a client change.

There is no such thing as a protocol in Bitcoin. It's defined by all changes in Satoshi client.

[🏰 TradeFortress 🏰]

If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue.

This is not a protocol change.

This is a client change.

There is no such thing as a protocol in Bitcoin. It's defined by all changes in Satoshi client.

Yes there is. It is defined by changes in the reference client, but not all reference client code dictates the protocol. Please grasp that protocol and policy are different things.