Soft block size limit reached, action required by YOU

[Mike Hearn]

By default Bitcoin will not created blocks larger than 250kb even though it could do so without a hard fork. We have now reached this limit. Transactions are stacking up in the memory pool and not getting cleared fast enough.

What this means is, you need to take a decision and do one of these things:

• Start your node with the -blockmaxsize flag set to something higher than 250kb, for example -blockmaxsize=1023000. This will mean you create larger blocks that confirm more transactions. You can also adjust the size of the area in your blocks that is reserved for free transactions with the -blockprioritysize flag.
• Change your nodes code to de-prioritize or ignore transactions you don't care about, for example, Luke-Jr excludes SatoshiDice transactions which makes way for other users.
• Do nothing.

If everyone does nothing, then people will start having to attach higher and higher fees to get into blocks until Bitcoin fees end up being uncompetitive with competing services like PayPal.

If you mine on a pool, ask your pool operator what their policy will be on this, and if you don't like it, switch to a different pool.

[1714982177]

1714982177

[1714982177]

1714982177

[1714982177]

1714982177

[playtin]

Mike, you forgot to mention that this will not fork the block chain - otherwise your posting could result in even more threads about a hard fork by someone uninformed

[Mike Hearn]

Good point, fixed.

[cedivad]

Where is the foundation during the only moment we need it?

[Akka]

Well, I'm curious to see how this works out. Hopefully the most pools will not increase their Blocksize limit so we get a good simulation of how the Bitcoin environment behaves when we bump against a limit.

[Mike Hearn]

We are already bumping up against a limit. No simulation needed. We have reality instead ...

[Akka]

We are already bumping up against a limit. No simulation needed. We have reality instead ...

OK, wrong word. Still I hope that most pools will not immediately lift / increase their limit. So we know what will happen when we reach the hard limit, which can't be changed so easily.

So let us bump against this for a few month. And lift it only if it really damages Bitcoin.

[Luke-Jr]

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.

[[Coins!]]

Mike, have you contacted mining pool operators individually ?

[Mike Hearn]

No. I don't have their contact details, and even if I did, this is the wrong way to solve such issues.

Miners (all miners) need to understand what they're doing. The time when people could just click "Generate coins" and be done with it are long gone. It's very important that miners monitor the health of the network and understand what their software is doing.

For pools, the operators need to state what their block construction policies are, and the people with the hardware need to understand those policies and find pools with good ones.

That's far more than I or anyone else can do alone. Miners need to hold their pools accountable.

[MPOE-PR]

Change your nodes code to de-prioritize or ignore transactions you don't care about, for example, Luke-Jr excludes SatoshiDice transactions which makes way for other users.

Actually the right way to solve such issues is to post this sort of bullshit drama here so that we can see that Mike Hearn is the sort of irrelevant muppet nobody cares about.

It's one thing if I just say it, it's another if he says it and time proves it.

[deepceleron]

Add an additional .001 optional fee in your client and your transaction will be in the next block. The blockchain flooders are cheapskates. Transactions are not supposed to be cheap enough that you can blast hundreds of them out an hour with your gambling bot.

[eleuthria]

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

[420]

by a node this means a miner right?

ALSO: what if satoshidice just switched all their internal transactions to LTC network?

would this be possible and help

just a thought

[Smoovious]

What is the hard limit for block size anyways?

-- Smoov

[pyra-proxy]

Way I see it is if satoshi dice is such a problem then they need to shutdown and come up with a new idea or the community should boycott them if they prefer a functioning financial system over an entertainment site...  alternatively bit coin could solve its block chain bloat problem... of which very many very sound ideas have been proposed but it seems as if the powers at be won't care until its too late... but whatever let's just enjoy the ride while it lasts right? :-)

[grue]

how about no? because I don't want encourage some gambling website to fill up my hard drive with their bets.

[scintill]

how about no? because I don't want encourage some gambling website to fill up my hard drive with their bets.

Then don't let sdice transactions into your solved blocks, and encourage others to do the same.  Mike didn't say you have to increase the soft limit.  Luke-Jr posted about your other options.

Personally, banning sdice outright seems like the kind of scummy meddling bitcoin is supposed to solve.  I would rather make them pay transaction fees somewhat proportional to the cost they incur on the network.  If they pay them, miners get more money for their trouble, if not, they stop spamming the chain.

[disclaimer201]

I lost a lot of money today because of this shit. And I don't care for satoshi dice. Let them move to litecoin or ban them from spamming the network and my harddrives.

[pyra-proxy]

how about no? because I don't want encourage some gambling website to fill up my hard drive with their bets.

Then don't let sdice transactions into your solved blocks, and encourage others to do the same.  Mike didn't say you have to increase the soft limit.  Luke-Jr posted about your other options.

Personally, banning sdice outright seems like the kind of scummy meddling bitcoin is supposed to solve.  I would rather make them pay transaction fees somewhat proportional to the cost they incur on the network.  If they pay them, miners get more money for their trouble, if not, they stop spamming the chain.

Free market to do something also incurs the the possibility that others may not want to assist or be accomplice ... ie. While I may allow any transaction that offers minimum+ fees, I can't fault others for using blacklists preventing them from being forced to process transactions relating to things they don't agree with.  In reality I'd kind of like to start using a black list regarding known silk road processors and mixing services myself because they IMHO relate (semi-)directly to human injustices not just free market... s.dice I'd consider including only because the implementation they have currently is detrimental to the health and viability of bit coin at least until block chain bloat solutions are tested and implemented.