[PATCH] increase block size limit

[ArticMine]

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

Satoshi Dice is currently paying 0.001 BTC in fees per transaction which translates into 0.03 USD per transaction. I would not call this "dust spam". What we have here is exponential growth pushing against a hard limit. This is a prescription for disaster. Arguing whether the disaster happens in four months or sixteen months is beside the point.

[jgarzik]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

[Technomage]

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

[markm]

Okay how about making max block size a configuration file / commandline variable?

From then on, no hard fork of the code would be required to change it, only, potentially, a hard fork of the blockchain?

Shops can have signs on their doors warning customers about the actual setting that shop uses for max block size, and customers can choose higher size supporting shops if they feel confident risking their money in blockchain branches they think might end up with less hashing power behind them than forks adopting a more traditional / more conservative limit?

Customers would maybe prefer merchants whose limit is set so high only a few miners world wide can handle it thus that have lower hash power, plus their coins will still be safe back on the original size branch because no higher size block can ever move any original sized block chain's coins anywhere at all.

Merchants wanting to actually be able to receive real original coins on the real original chain will set their clients to not approve blocks larger than those of the original chain, the chain which established the damn things have any value at all in the first place.

Maybe we should make two forks right away, a double sized block and a half sized blocks chain, and see which chain's coins best retain or gain value?

The config file setting method of setting the max will at least get rid of all the "we have to fork the code" excuses / arguments, reducing it to each node's choice what value to put in its config file. Thus putting the power with the nodes, not with the developers. (Which might be a really really really crappy idea. "Eat shit! Half a million houseflies can't be wrong!")

-MarkM-

[nikkisnowe]

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

[misterbigg]

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

They aren't ridiculous or indecipherable at all. In fact they are a very polite way of mocking many of the clueless opinions from non-technical folks.

[Peter Todd]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

Speaking of, you made a "dust-spam non-standard" patch right? Where is it?

[dacoinminster]

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

A tiny fraction of a bitcoin might represent an ounce of gold (for instance), and so it should NOT be assumed useless or disallowed by the protocol!

I think prioritizing transactions by fees is better than trying to rule out transactions which don't have an immediately obvious purpose.

[Peter Todd]

This comment concerns me very much. Dust spam may not have economic value when denominated in bitcoin, but such "spam" can be representative of much larger transactions if the dust is representative (such as with "colored" bitcoins).

Sane "colored coin" or "smartcoin" protocols don't depend on some fixed "1 satoshi = 1 share" ratio. Rather for each transaction moving an asset around they calculate what fraction of the asset was assigned to what transaction output, which means you can divide the asset indefinitely without requiring the actual amount of Bitcoins to change. If the asset represented by a txout is worth less than the minimum transaction fee, it's still dust that doesn't make sense to spend.

It's unfortunate that the first smartcoin-type protocols weren't written that way; on the other hand none of them have actually been used in practice. I've written a protocol that does this correctly as apart of my fidelity bonds protocol, see here although I haven't written code to implement it yet.

[mp420]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees. If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

[markm]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees.

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.

If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

[ArticMine]

I think I'm drifting toward the opinion that we should postpone this discussion until after we have actually hit the limit and until the spam transactions have been weeded out by rising fees.

Excellent! Hopefully we will succeed in convincing the "something must be done" crowd that actually that isn't really the case yet, but nonethess have the discussion anyway so that when it is the case the discussion will be behind us so we'll know exactly what to do.

If/When fees get to $10/transaction level I think more people will agree that keeping the 1M limit forever is not going to be sustainable. Okay, that might actually never happen, since I think even $1/transaction mandatory fees will drive many users away from Bitcoin.

There would be more money available then for upgrading infrastructure, although I continue to hope that by then exchange rates will be so much higher again than they are now that sheer increase in the buying-power of bitcoins will cause no one who is mining them now and not stupid enough to dump them to have any hesitation* upgrading their infrastructure if they planned to continue mining. Those who just mine to dump are basically "shorting" bitcoins against fiat anyway so if they quit that might be a net good for us rather than any loss at all. (Bulls might be able to pick up their gear even.)

I've become more and more pessimistic over time about Bitcoin's future prospects. It's not well suited for e-commerce, transactions are inherently expensive (they need huge amounts of storage capacity and bandwidth) and the anonymity aspect is debatable.

It is well suited to final settlement. Most e-commerce actually wants, maybe even "needs", to delay finality of settlement for quite some time, That might not be a trivial factor in what differentiates final settlement systems from consumer retail sales/purchase systems. Heck from time to time there is even talk of eliminating or deprecating cash even in meatspace, especially for decent-sized transactions. Come to think of it its not just talk lately, isn't cash being outlawed even in some places? It might be appropriate to get more and more pessimistic over time about cash's future - and, already, present - prospects. So I guess I can to an extent feel for you on this one but more so really re cash than re bitcoins, since bitcoins might help get us out from the crunch/attack cash is being subjected to.

* Other than "spend them while they are skyrocketing in value!?!?! Woe is me!"

-MarkM-

How does this address a critical part of Satoshi's post namely that this be implemented "... in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete"?

[Technomage]

I just checked. We're currently at 0.7 transactions per second. If it can scale to 7 transactions per second, well, we still have a long way to go before we even start to have truly crowded blocks.

As important as this issue will eventually be, it's not worth it to get too heated about it at this point. Even when the blocks start getting crowded it's not an immediate issue, fees will simply go up a bit which is not a big deal since the transactions are currently almost free.

[markm]

How does this address a critical part of Satoshi's post namely that this be implemented "... in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete"?

We immediately put in a block number at which max block size will be read from the config file instead of being hard-coded into the code.

Then sit back and yack until what actual number to put in that spot in the config file becomes clear.

-MarkM-

[iCEBREAKER]

It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.

I don't see the urgency, so it's more like a snooze button than a wakeup call.

[ArticMine]

I just checked. We're currently at 0.7 transactions per second. If it can scale to 7 transactions per second, well, we still have a long way to go before we even start to have truly crowded blocks.

As important as this issue will eventually be, it's not worth it to get too heated about it at this point. Even when the blocks start getting crowded it's not an immediate issue, fees will simply go up a bit which is not a big deal since the transactions are currently almost free.

Based on the 10x growth of the number of Bitcoin transactions over the last year that places the issue under a year away. The problem is that it can take a year to do a hard fork properly.

[Technomage]

True. I think that a plan must be figured out within the next 6 months if we don't want to rush the hard fork when it's time. And hard fork is such a thing that we don't want to rush it.

It's not that bad though. They can simply put rules in place for the nodes so that the fork only happens when a sufficient number (maybe 90%) has upgraded. Then it's up to the users how fast the hard fork happens. It can happen quickly if the fees become a problem, simply spread the word.

[ArticMine]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

[johnyj]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

About half maybe

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124682

[ArticMine]

A good question here is what percentage of nodes are currently running versions of Bitcoin software that are a year old? Six months old?

About half maybe

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124682

Thanks. CVE-2012-4682 is dated 14-Sep-2012.  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4682. That is less than six months ago. This means that six months is the barest of minimums if at all. A much more reasonable time frame is 12-18 months or even longer.