WARNING! Bitcoin will soon block small transaction outputs

[Bitcoin Oz]

When you have a communal asset like the blockchain it can lead to a tragedy of the commons situation unless you make services cover the cost of their transactions. Otherwise its like building roads and infrastructure funded by the taxpayer but the housing developers take all the profits.

tldr a land tax is a fair way to do things.

[dutt]

I guess this might have to happen if you want to keep the blockchain from getting spammed with useless transactions.
If the limit can be raised it can also be lowered, right?

[mollison]

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Actually, an improvement on the last suggestion.

Determine an acceptable (given technology) rate of growth of the total set of unspent outputs. Every 2 weeks, adjust the number of (new unspent outputs created - previous unspent outputs spent) allowed per block, based on how closely the maximum rate of growth is being tracked.

This makes the size of all unspent outputs a resource that is subject to an economic feedback loop, just as we already have (in theory) with the total size of each block. That minimizes transaction fees without ruling out legitimate transactions that look like dust (micropayments).

Miners could pay users to spend lots of dust outputs, since it allows them to include more unspent outputs (which they can charge for) in their block.

[jonytk]

People, i have a solution should look something like this:

Forbid transaction that includes output less than x for a output address with an actuall amount of less than y.

Where x is 100 times less than the transaction fee and y 100 times more than the transaction fee.
And,
the transaction fee IS the average of the transaction fee included in the last 4380 blocks.(1 month)
with a minimum hardcoded that will change, but could be 0.0001 for transactions of less than 0.01 btc amount (at the moment, but that last number could be 0.01% of the average transaction size, rounded downwards. according to blockchain.info average transaction size is 13.4btc; so you will have to pay a 0.000134 min fee for any transaction of less than 0.00134 / or for every output of less than 0.00134)

so for example if the currently average transaction is fee is 0.00054
you cannot send less than 0.0000054 to an address with less than 0.054 (it will bounce back as change?)

this will:
1- Encourage the consolidation of addresses for people that have little amounts of coins and many addreses.
2- Not prevent people from making satoshi-transactions (they will pay a fee but they will have to have some balance in the receiving address)
3- Not bloat the blockchain
4- Help in the eventually cleanup of the blockchain: then after an x period, we can cleanup all addresses with less than 100 times the transaction fee safely.(i'm not sure if this last one is possible, but we could alow the sending for free of this satoshis to a address with a minimum balance)

That should deal with the bloated blockchain problem...
people with small amounts of satoshis, and that care enought, can still recover them by sending some btc (over 0.01) to the address and then send it it back or by  alowing the sending for free of satoshis only if they leave the address with 0 balane and are send to a address with a minimum balance.

TL,DR:
Encourage consolidation of addreses, forbid sending satoshis to an empty address, allow sending satoshis (if paying fee) to an address with balance, helping cleanup of blockchain (addresess with 0 balance should be pruned)

And for the people complaining about the size of the blockchain, a miner/pool making 100$ a day cannot spend 100$ on a 1tb harddisk per year?

[wolverine.ks]

how is the any different than all miners using the standard client changing the minimum transaction size accepted to 5430 satoshis?

if it's identical, why haven't they done it already? why would a patch be necessary to implement the change? why not make a forum post with the suggestion?

[caveden]

It is not a data storage service. Bitcoin would be a very bad design for a storage service

That's your - and mine too - opinion.
Some people apparently see the blockchain as useful for data storage, or for message sending, whatever. Simply trying to censor them is dumb. It's the typical bureaucratic response to a perceived "problem": ban it!

The clever response is to imagine how could Bitcoin profit from it. And I can see no better way than to make them pay for such unconventional usage.

As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

Don't be ridiculous (or troll harder). There's consent in Bitcoin usage. Apart from botnets and alike, nobody forces you to install Bitcoin in your computer.

The costs of data storage are not just borne by the single miner that accepts the transaction and has arguably been paid for their trouble they are imposed on the entire network— all current and future users of Bitcoin— for all time.

They're not "imposed".

And yeah, that's part of the "game": the remuneration is diluted in this lottery-like thing popularly called mining. That's known in advance. You know you'll only get the fees of a transaction if you get to produce the block that contains it. As long as the remuneration you collect (inflation + fee) pays for the overall effort and costs you need to bear, you should be fine.
Although in general I'm for the internationalization of costs, you shouldn't get overly paranoid there. Sometimes it's more expensive to internalize a cost than to bear the free-rider. For example, have you ever seen a residential building trying to charge its inhabitants according to the amount of times they took the elevator?
(By the way, if UTXO ever becomes so huge that smaller miners can't bear to store it entirely - I honestly doubt it - they can choose to drop some transactions that they believe will never be spent. At the worst, some of these transactions get spent and these miners won't be able to fully validate the block in which they get included - if they get included by someone-, pretty much like SPV nodes. But they'll still be able to validate and mine all others, more "interesting" transactions. Another alternative would be to store these txs in slower and cheaper media, since they don't expect to access it. Anyway, I really doubt UTXO will ever get that big so this is likely a non-issue)

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

No, nodes relaying non-standard transactions are not disconnected. That would make it infeasible to have inconsistencies in policy. Part of the point of policy vs protocol rules is that policy isn't required to be completely consistent for correct operation.

Great, at least people can safely opt-out. I still think it should be an opt-in though.

I agree with you, but it's still sad to see biased behavior being embedded in the reference implementation. It's like bitcoin.org. Not a monopoly, but still, the "reference". I'd very much prefer if it remained the most unbiased possible.

Biased how?

By deciding which use cases are desirable and which are not, and attempting to censor those considered undesirable. That's a judgement of value.

I insist: banning like this is dumb. Charging for it is more reasonable, and much more use-case-neutral.

Discouraging the creation of transaction outputs that yield fewer Bitcoins than they cost to spend is pretty "value neutral".

I wouldn't call that "discouraging", I'd call that censoring them on bitcoind. Discouraging would be to make them pay.

As far as I'm aware a policy to restrict them doesn't discriminate against any kind of usage other than the "usage" of forcing hundreds of thousands of machines to archive non-bitcoin data against their operators consent.

It is not against their consent (botnets excluded, of course).

[boonies4u]

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.

This only changes the default behavior of pools so they block dust transactions. Some pools already block dust transactions and will continue to do so. Others haven't been blocking dust transactions and will accept them.

But others will just do whatever default behavior the devs set.

[centove]

After reading all 15 pages of this stuff.. It basically boils down to this.

There was a magic number in the code for the transaction fees, so if a user of the bitcoind software wanted to change this, one had to get the source, edit main.h find the magic constant, change it, compile, install and use the newly compiled binary.

Sooo rather then that.

It was made an run time configurable thing. A NEW magic number was chosen. OMG! You're censoring transactions!! Nazi! Fork the code!!

I mean see for yourself:

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

(hint the red lines are removed and the green lines are added)

For example:
---
-    // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
+    // To limit dust spam, require base fee if any output is less than 0.01
---

Notice the change from a CONSTANT to a variable?

Geeze...

[jonytk]

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Actually, an improvement on the last suggestion.

Determine an acceptable (given technology) rate of growth of the total set of unspent outputs. Every 2 weeks, adjust the number of (new unspent outputs created - previous unspent outputs spent) allowed per block, based on how closely the maximum rate of growth is being tracked.

This makes the size of all unspent outputs a resource that is subject to an economic feedback loop, just as we already have (in theory) with the total size of each block. That minimizes transaction fees without ruling out legitimate transactions that look like dust (micropayments).

Miners could pay users to spend lots of dust outputs, since it allows them to include more unspent outputs (which they can charge for) in their block.

Yes and No, Yes there should be a high limit to prevent spam,
 but also there should be a lower limit on the amount of satoshis you could send to a EMPTY address,
 a spammer can use have infinite number of empty addresses to bloat the blockchain with 1 satoshi transactions
 but he can only have so many addresses with a balance in it!

thus forbid transactions that send less than x satoshis to a address with 0 satoshis.

If this transactions have multiple outputs, just look the one's that are empty and send the amount back as change.
This will make everyone want to have at least x btc in his/her address and not spamming the address space with almost empty addreses.

[caveden]

As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

Don't be ridiculous (or troll harder). There's consent in Bitcoin usage. Apart from botnets and alike, nobody forces you to install Bitcoin in your computer.

This is plain disrespectful.

OK. And comparing it with drilling holes in people's heads was totally coherent, relevant and "respectful".

In the end of the day if you are not a significant miner you have no say whatsoever in how much to charge for any transaction and whether it is better to patch and recompile bitcoind to get what you want or to use some command line switches. All you can decide on is whether you prefer a higher fee for quicker transaction or not. This is so by design. It always was so. It always will be so.

I hope you're right on the last phrase.
And yes, in the end of the day significant miners get to tell what's accepted or not. So why embedding this particular policy in the default behavior anyway? (the particular dust-non-standard one, not the config options, which are obviously welcome)

[jgarzik]

In the end of the day if you are not a significant miner you have no say whatsoever in how much to charge for any transaction and whether it is better to patch and recompile bitcoind to get what you want or to use some command line switches. All you can decide on is whether you prefer a higher fee for quicker transaction or not. This is so by design. It always was so. It always will be so. If you are not happy with it go and create a fork where users decide how much miners are to charge for finding blocks.

Close.

It is true that miners choose which transactions get into blocks.

However, every client chooses what to relay, or not.

[gmaxwell]

It is not a data storage service. Bitcoin would be a very bad design for a storage service

That's your - and mine too - opinion.
Some people apparently see the blockchain as useful for data storage, or for message sending, whatever.

It's isn't just an opinion— it's what people signed up for.  Satoshi didn't advertise Bitcoin as "p2p storage for uncle fester's preteen porn collection", he advertised it as a currency.

The clever response is to imagine how could Bitcoin profit from it. And I can see no better way than to make them pay for such unconventional usage.

As I explained, making the txouts have greater value makes them pay all Bitcoin users for it— it still doesn't make it good: Someone who takes from you isn't freed of their wrongdoing simply because they leave a few bucks behind, but it's better— especially because it should discourage some of the abusive behavior in total.

As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

Don't be ridiculous (or troll harder). There's consent in Bitcoin usage. Apart from botnets and alike, nobody forces you to install Bitcoin in your computer.

The comment there isn't about the force— though thats an issue too— it was a response to you saying "they paid for it".  I install Bitcoin to participate in a distributed currency, I didn't consent to storing whatever garbage you can trick the system into storing.   You can't say you paid me for my trouble and I accepted— you didn't you paid some random third parties who aren't me, I might not even be mining at all— but I support Bitcoin and run a full node because a p2p decentralized currency is important to me, and making it stay inflation free is very important.  Thus my silly analogy about paying your neighbor for permission to drill holes in your head.

And yeah, that's part of the "game": the remuneration is diluted in this lottery-like thing popularly called mining. That's known in advance. You know you'll only get the fees of a transaction if you get to produce the block that contains it. As long as the remuneration you collect (inflation + fee) pays for the overall effort and costs you need to bear, you should be fine.

Except that mining, necessarily, has nothing to do with the cost of validation. To be decenteralized its important that as many _non miners_ fully validate as possible, otherwise there is nothing to keep the miners honest as a group.

and these miners won't be able to fully validate the block in which they get included - if they get included by someone-, pretty much like SPV nodes. But they'll still be able to validate and mine all others, more "interesting" transactions.

Awesome, so I just make up a transaction that never existed with an output of a billion bitcoins— and split it between myself and a couple other parties that I know have complete records and mine that. Whos to be the wiser? Obviously that example is a bit silly— but the point remains, validation isn't useful unless its done completely. If someone can predict how you won't validate they can create inflation producing, thieving transactions which meet that criteria.

Anyway, I really doubt UTXO will ever get that big so this is likely a non-issue)

I guess you haven't looked at the rate of utxo growth?

Great, at least people can safely opt-out. I still think it should be an opt-in though.

As has been written dozens of times here by a dozen people. I'm glad you took the time to inform yourself on the subject before posting.

I insist: banning like this is dumb. Charging for it is more reasonable, and much more use-case-neutral.

Uh. If you're such a fan of charging for things then you should realize that thats exactly what this does. It charges for it by making you increase the size of your outputs.  The clever thing about charging for it this way is that is that it focuses the charge on the specific usage that adds the expensive perpetually unprunable data to the blockchain (because that creates outputs which cannot be redeemed).

I wouldn't call that "discouraging", I'd call that censoring them on bitcoind. Discouraging would be to make them pay.

Bitcoind will still happily accept blocks with these transactions. There are many kinds of non-standard transactions which are rejected in the same way. For example, transactions which create 0 value outputs, or ones which create outputs less than 0.01 without a fee, or ones that use random opcodes, or have more than a couple parties in a multisig.

[molecular]

Not a file sharing, but distributed DHT-like database HASH=BLOCK

What you're looking for is Freenet. Aside from the anonymity (which is neither needed or maybe even desired for blockchain storage) Freenet is a large operating content-addressed, redundant distributed filesystem with some unique properties such as good resistance to data loss even under the condition of nodes coming and going randomly, with no explicit coordination or configuration. The Freenet developers are aware of Bitcoin and are aware of how Freenet and the potential synergy between the two projects, and I think they only thing that's missing is interest for some type of collaboration to happen is some programmers on the Bitcoin side to take an interest in them.

best talk to da2ce7 and/or xelister. They have been thinking about "bitcoin over freenet" 2 years ago. xelister actually started an implementation, but progress seemed slow. I've tried myself but got stuck. It's not as straight-forward as one might first think but I think this kind of thing is important going forward.

[evoorhees]

This discussion would be much more productive and pleasant if people would stop with the personal attacks. Gavin and other developers are making this change because they think it is intelligent to do so, and they've given reasoning for this. If you disagree, then discuss your reasoning and engage in a professional dialogue.

If you care about Bitcoin, and about how it develops, then allowing your commentary to devolve into personal insults and hyperbolic rhetoric is counterproductive - you sabotage your own goals, unless your goal is just to be mean or cause superficial uproar.

The merit of your argument is diminished to the extent it is wrapped in anger. A wise person, confident in his ideas, needn't resort to shouting.

[jgarzik]

Not a file sharing, but distributed DHT-like database HASH=BLOCK

This "DHT" call comes up frequently.  This is fine for experiments, and as a backup method akin to the recent blockchain-over-twitter project.  But it is woefully less secure and resilient than the current scheme.

Bitcoin uses a "D1HT"... a fancy term for "everybody has a copy of the database."  Currently the entire blockchain is massively replicated, perhaps 20,000+ times or more.  This is larger than all but the largest torrent swarms.

Benefits:  More secure and resilient.  Far more decentralized.  Better chance of useful work, if one honest peer is found.  100% provable for any node; no "holes" in the history.   Costs:  Network and disk resources required to store the blockchain, and provide it to others for download.

Going from that, a DHT is quite a step down, quite a bit less secure.  DHTs are vulnerable to hot spots -- where the whole world queries just a few nodes -- and sybil attacks[1].  On sybil attacks, bitcoin's current peer finding mechanism does a better job of intentionally spreading itself widely across networks; a DHT tends to concentrate on a few nodes.

It becomes much easier to attack a portion of the blockchain, if it were stored as (hash,block) key-value pairs as commonly suggested.  If an attacker may DoS even a single (hash,block) pair, you prevent the entire world from downloading or verifying the entire bitcoin blockchain, because the chain is thus broken.  The time spent looking up each hash across a worldwide DHT would be quite slow; that is the equivalent of downloading 234,831 different torrents, not one big torrent.

Storage via DHT is a fun toy idea, but it's stupid, slow and insecure as a primary method.  Massive replication is far more secure and decentralized.

Hard drive technology has no problems keeping up with blockchain growth.  Network technology is probably the same, though I think there will be some amount of balancing on-chain versus off-chain transactions.

It is also thought that the nodes bearing the brunt of the blockchain downloads in the future will be a few professional and volunteer "archive nodes", that store the entire blockchain.  And certainly the blockchain torrent will continue to exist as an alternate method.




[1] Remains an active area of DHT research, and several mitigation mechanisms are deployed in the field.  Even with these new techniques, the DoS-a-block, DoS-all-of-bitcoin implications make DHTs an inferior solution.

[Peter Todd]

Hard drive technology has no problems keeping up with blockchain growth.  Network technology is probably the same, though I think there will be some amount of balancing on-chain versus off-chain transactions.

Anonymous network technology is just barely good enough to support mining anonymously with 1MB blocks. (not hashing! I mean being a mining pool, solo-mining, or running p2pool) That isn't going to get better quickly, and could easily get worse if we see attacks on the Tor and I2P networks.

[jgarzik]

Hard drive technology has no problems keeping up with blockchain growth.  Network technology is probably the same, though I think there will be some amount of balancing on-chain versus off-chain transactions.

Anonymous network technology is just barely good enough to support mining anonymously with 1MB blocks. (not hashing! I mean being a mining pool, solo-mining, or running p2pool) That isn't going to get better quickly, and could easily get worse if we see attacks on the Tor and I2P networks.

Indeed.

The more people who run a full node, the greater the decentralization[1][2].

Using the chain as data storage, rather than currency, costs everybody, because it increases the rate at which people are discouraged from running full nodes.  It increases the costs of that dataset that cannot be pruned, and must be carried for eternity: the unspent transaction output set (UTXO), the list of coins available for spending.

Right now, it remains within the realm of a hobbyist to run a full node, especially with the recent memory usage improvements in bitcoind.  But one day, that will not be the case.

By pushing back on data spam, we reduce the rate-of-increase on blockchain resource costs, and reduce the disincentive to run a full node.  We push back the day at which there are just a handful of archive nodes with a copy of the full block chain.



[1] Probably.
[2] Though "decentralized" does not necessarily imply "private", as your message indicates.

[Daily Anarchist]

If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue. If we ( and I include myself in this) don't like it, then it should incentivize us to create competing bitcoin clients.

I agree with you, but it's still sad to see biased behavior being embedded in the reference implementation. It's like bitcoin.org. Not a monopoly, but still, the "reference". I'd very much prefer if it remained the most unbiased possible.

I agree. But like I said earlier, perhaps this is Gavin and team's way of pissing us off enough to create alternate full node clients.

[Daily Anarchist]

I think Gavin has alluded to possibly rewarding those who run full nodes, which I think is the way to go. I don't see any reason why miners should get rewarded, yet those who run full nodes and eat the bandwidth/disk space get nothing.

[gmaxwell]

I think Gavin has alluded to possibly rewarding those who run full nodes, which I think is the way to go. I don't see any reason why miners should get rewarded, yet those who run full nodes and eat the bandwidth/disk space get nothing.

You get the reward of having a secure, inflation proof, interference resistant, decentralized currency _actually existing_. I can't think of any better reward than that.

It would certainly be great if Bitcoin could distinguish participants based on independent people-ness. But alas... no one has discovered a way to make that workable. Keep in mind that it's the same fundamental underlying problem that had people saying that something like Bitcoin was impossible all those years. Satoshi's dodge was to replace independent-peopleness with computational-scarcity which makes the whole thing workable, but doesn't result in a way to directly reward decentralization.