Topic: WARNING! Bitcoin will soon block small transaction outputs - page 17. (Read 58538 times)

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.

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.

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.

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?

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

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

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.

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

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

1) I note the distinct lack of discussion surrounding https://bitcointalksearch.org/topic/rfc-updating-dust-output-definition-and-default-fees-130450 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.

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.

^ 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.

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


I didn't say it would cause a fork

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.

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.

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 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?

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

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.

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!