Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks

[notme]

Some of this profit can be fairly spent RIGHT NOW on improvements to internalize transaction flow, or it should be blocked until it does. This is the real choice.

Sounds like extortion, doesn't it?

Yes.

Huh? Him exercising his freedom to spam and me exercising my freedom not to include his spam in blocks I create, or even not to pass them along to me neighbors, is extortion?

-MarkM-

That's different from solex dictating that they "should be" blocked.  You are free to do what you want, but not to tell me what to do.

[markm]

He is telling us what we should, in his opinion, do.

We don't have to do it.

-MarkM-

[Come-from-Beyond]

Huh? Him exercising his freedom to spam and me exercising my freedom not to include his spam in blocks I create, or even not to pass them along to my neighbors, is extortion?

Or him extorting from me, by spamming, the coding-minutes it'd take to filter him out is extortion?

-MarkM-

It's arguable if it's extortion or not, I just imagined headlines that we could see soon:

A Bitcoin venture is blocked due to very high income!

[notme]

He is telling us what we should, in his opinion, do.

We don't have to do it.

-MarkM-

It was the suggestion that SD spend their money how he wants or he will block them that made it sound like extortion to me.  Looking at the dictionary definition, it probably doesn't exactly fit, but his tone is certainly coming across to me as hostile.  For example, he ends with "This is the real choice", as if his two options are the only options.  Maybe I'm just too sleepy  .

[Smoovious]

He is telling us what we should, in his opinion, do.

We don't have to do it.

-MarkM-

We've long-passed that point months ago...

That whole camp is now up to badgering and harassment... full-on FUD mode...

-- Smoov

[solex]

Some of this profit can be fairly spent RIGHT NOW on improvements to internalize transaction flow, or it should be blocked until it does. This is the real choice.

Sounds like extortion, doesn't it?

The Story of Bit City and its Transport System

Bit City has a privately run train system. Its shareholder's capital is being pumped into it at a regular pace until passenger volumes increase to make it self-funding and then profitable. In order to encourage passenger numbers Bit City Trains (BCT) are offering family tickets at a rock-bottom rate, hoping to attract groups instead of just individual commuters, some of whom pay well for a seat already, yet overall commuter revenue is not high.

Bit City has a bus company called Efficient Coach Interchange (ECI) owned by Mr Dihsotas, which has some ticket revenue, but, by itself is not profitable. Lo and behold there is an opportunity.  BCT has a network which goes to all suburbs and even neighboring towns. If the ECI buses went to all those places he would make a good profit on all the customers which would flock in.

Mr Dihsotas decides to park his buses at all the stations and sells tickets to all destinations. The clever part is that every passenger who buys a bus ticket automatically gets adopted into Mr Dihsotas' family, so they get to use the train network during their bus journey for a low price. This is so popular that soon there are thousands of passengers crowding BCT's trains, forcing extra rolling stock to be used. The trains are often full, but BCT shareholders are not making a profit yet, even though family tickets are making more money than all the commuter tickets combined. There is also a steady stream of complaints from regular commuters about lack of seating, long queues, platforms too short for the extra carriages, it goes on.

Bit City Trains has the illusion of success but something is just not right. The share price is high, but for how long? At the AGM one of the shareholders heckles the board saying that Mr Dihsotas should not get the family discount tickets anymore....

[Smoovious]

The Story of Bob, The Bitcoin Miner

Bob mines bitcoins. He has a lot of other miners he works with. His job is to process transactions. For this, he gets paid.

Some of Bob's fellow miners make a big show of working hard, but at the end of the day, they didn't have any transactions in their blocks, but they still get paid the base rate.

Unfortunately, this leaves more work for Bob, who has to pick up the slack for the other miners who don't bother to process their transactions.

Bob doesn't feel this is fair, so one day, he decides he's not going to work so hard for the extra pay anymore, and just do the bare minimum, since other miners get away with it too.

The people sending in transactions, however, notice that Bob isn't keeping up like he used to, and is even ignoring their transactions. Those people, however, are his mine's biggest customers.

Since Bob's numbers have plummetted, Bob gets fired. His fellow miners who never processed transactions in the first place, however, keep their jobs, never having been noticed since they never did any actual work in the first place, and keep collecting their paychecks.

Pretty soon, more and more miners refuse to process more and more transactions, bringing the mine to a standstill, and the mine closes.

---

Moral of the story? A MINER'S JOB IS TO PROCESS TRANSACTIONS... that is the whole purpose of your existence in the bitcoin community. If you're not processing the transactions in front of you, you aren't doing your job, and you don't need to be here. Go whine somewhere else, or quit bitching about how much work you're getting paid to do and do your goddamned job.

-- Smoov

[caveden]

We are only in this situation because ONE source application is flooding the network with low fee transactions. That source application is abusing the Bitcoin network as a messaging system because it helps their business model run just slightly more conveniently for them.

Will you people just stop this bullshit?

If you feel SatoshiDice is "abusing you" somehow (pure nonsense, but anyway), run a custom client that doesn't relay its transactions. Run a solo miner or mining pool that doesn't include them. Do whatever, but just please stop bitching.

[tytus]

We are running an older version of the client than 0.7 but had problem with the database (on Debian) long time ago:
https://bitcointalk.org/index.php?topic=80439.msg890951#msg890951

We had to modify default db parameters by adding the DB_CONFIG file
___@___:~/.bitcoin$ cat DB_CONFIG
mutex_set_max 100000

I am not sure how the last problem is related to this. In any case,
How can we check in what way the client was affected by the fork, ... which of the branches was chosen by the client (if it is older than 0.7).
[what do we look for in the logs?]

[deepceleron]

Could someone link to "old" 225430 which caused hard-forking or post data, for analysis and historical reasons? Thanks in advance.

https://blockchain.info/block-index/357948/000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023

So you are quoting yourself to show that you found your answer earlier in this thread?:

Zee blockchain killer 225430 (slush / 1MB):
http://blockchain.info/block/000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023

Does anyone have a full copy of the 225453 height blockchain fork or a novel way to recreate it? I should have been clever and made a copy of my datadir while this was going on. For testing, one can --connect any clients to an isolated node using this fork at that height, although I think any inconsistencies between versions/build environments (why were some <0.7 ok with the fork?) will come down to platform BerkeleyDB defaults.

[Syke]

Cumulative Fees Paid:        2837.93797500 BTC

What's wrong with the fees paid? Those all went to miners.

           small (bets < 4 BTC) |  3522656

What's wrong is they're spamming the chain with microtransactions with minimal fees causing a lot of dust that will bloat the chain. It's not healthy.

"minimal" fees, which just so happens to follow the rules when it comes to transactions and the inclusion of fees... if you don't like the "minimal" fees on small transactions, then lobby to get the fees changed on small transactions... _ALL_ small transactions... don't just go targetting SD specifically. They are just following the system in place.

Yup. I'm not targetting SD specifically. Anyone creating that sort of dust needs to be de-prioritized.

[taltamir]

So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...

But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...

Are there plans for a 0.8.1 which resolves this or what?

Anyone knows the answer?

[justusranvier]

So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...

But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...

Are there plans for a 0.8.1 which resolves this or what?

Anyone knows the answer?

Miners can still use 0.8 as long as they don't create problematic blocks. People running p2pool can stay on 0.8 as long as the don't increase the soft block size limit too high.

[taltamir]

Miners can still use 0.8 as long as they don't create problematic blocks. People running p2pool can stay on 0.8 as long as the don't increase the soft block size limit too high.

Is there a way to configure 0.8 to not increase the block size over the limit?

Because the bug (can't handle blocks over a certain size limit) isn't in 0.8 its in 0.7, and the bug cannot be resolved unless the entire network abandons 0.7 and earlier.
The solving of the fork by going back to the bugged version is a serious problem.

[justusranvier]

Is there a way to configure 0.8 to not increase the block size over the limit?

The default settings won't produce problematic bugs. Probably.

Because the bug (can't handle blocks over a certain size limit) isn't in 0.8 its in 0.7, and the bug cannot be resolved unless the entire network abandons 0.7 and earlier.

The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.

It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.

[taltamir]

The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.

It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.

And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork.
How can you migrate off of the buggy version when attempting to migrate off of it causes a fork?

The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine.

Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-?

[cypherdoc]

The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.

It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.

And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork.
How can you migrate off of the buggy version when attempting to migrate off of it causes a fork?

The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine.

Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-?

i think i read that the simple solution was to keep them below 500KB.

[taltamir]

The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.

It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.

And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork.
How can you migrate off of the buggy version when attempting to migrate off of it causes a fork?

The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine.

Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-?

i think i read that the simple solution was to keep them below 500KB.

Is there a command line argument I can use to do that?

[cypherdoc]

The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running.

It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process.

And yet the current solution is "everyone use 0.7 not 0.8". BTC and all other mining guilds switched back to 0.7 to prevent a hard fork.
How can you migrate off of the buggy version when attempting to migrate off of it causes a fork?

The most obvious solution is if 0.8+ could be configured to make blocks that are going to be accepted as valid by both 0.7- and 0.8+. Also that is the safest way to mine.

Hence my question, how do I configure my 0.8 to only make blocks that are readable by 0.7-?

i think i read that the simple solution was to keep them below 500KB.

Is there a command line argument I can use to do that?

its in one of these threads, if not this one.

[cypherdoc]

So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...

But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...

Are there plans for a 0.8.1 which resolves this or what?

Anyone knows the answer?

keep in mind that the tx that caused the fork was "specially made" by the miner.  it wasn't constructed by default.  so in that sense i don't think you need to worry.