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

evilpete

member

Activity: 77

Merit: 10

Quote from: taltamir on March 13, 2013, 11:41:41 AM

Quote from: justusranvier on March 13, 2013, 11:37:21 AM

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?

No, not true.

What we need is:
1) end users to get off 0.7/below and need to upgrade.
2) merchants to get off 0.7/below and need to upgrade.
3) when people run a miner program as part of a 3rd party pool, still need to upgrade. Their pool runs 0.7, not the person running the miner.
4) a couple of large pools stay on 0.7 to buy time for #1/#2/#3 to happen.

"Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above. The DB_CONFIG changes will fix the problems *that we know about* in 0.7 and earlier. Naturally there's still potentially more problems in 0.7 lurking.

However, those pools running this 0.7 bitcoind cannot "fix" the DB_CONFIG settings - if they did they might as well just run 0.8.

Once the vast majority of nodes are "fixed" (there's only 10,000 of them), then the big pools can go back to 0.8. (nodes: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html)

The reason 0.8 can't be taught to reject valid blocks that will break 0.7 and earlier is that there's no exact number. It's an internal artifact that depends on the run-time state of an individual node. For example, it has been observed by some folks that simply stopping/starting bitcoind 0.7 will cause it to validate and accept the block their copy had previously crashed on.

The "pools on 0.7" thing is just a tactic to by time for people to upgrade. It is not a solution, and it won't last.

Prediction: the moment sufficient hashpower switches over, somebody will generate another BDB-buster. It probably won't be a big pool, but somebody who wants the transaction fees will do it.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: gyverlb on March 13, 2013, 03:25:59 PM

I think I'll post a detailed guide about p2pool in the following days in order to promote it's adoption.

Btw, If most of the miners were on p2pool using 0.8, would it be possible to resolve 0.8->0.7 issue?

gyverlb

hero member

Activity: 896

Merit: 1000

I think I'll post a detailed guide about p2pool in the following days in order to promote it's adoption (my configuration is giving me satisfaction and I see many people who don't get as good results as mine).

There are some things hard to find by searching the forums and some urban legend to address too. There are cases where p2pool isn't a good solution that should be clearly reminded (BFL singles, some network setups, ...) so that people don't waste time with it when they'll clearly lose income instead of gaining some vs ordinary pools.

taltamir

full member

Activity: 196

Merit: 100

Quote from: gyverlb on March 13, 2013, 01:33:35 PM

Quote from: taltamir on March 13, 2013, 10:44:47 AM

Quote from: taltamir on March 12, 2013, 03:08:42 PM

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?

Edit your bitcoin.conf:

Code:

#Maximum size, in bytes, of blocks you create, large blocks can be rejected by the standard bitcoin node 0.7 and maybe earlier:
# 250000 is standard and safe for the network, 100000 lowers the latency of getblocktemplate calls which is good for p2pool's efficiency
blockmaxsize=100000

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=20000

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=10000

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.0005

Edit: oh, and restart your bitcoind process to apply changes.

Thank you very much.
This should be stickied

GideonGono

hero member

Activity: 1988

Merit: 501

★Bitvest.io★ Play Plinko or Invest!

Quote from: GideonGono on March 12, 2013, 03:23:22 AM

How can we prevent this from happening in the future and is there any other way the average user can contribute to the robustness of bitcoin?

I remember reading somewhere Gavin Andresen saying that they need more "test nodes" or something like that? How can I set this up and donate my resources to the network?

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: taltamir on March 13, 2013, 10:44:47 AM

Quote from: taltamir on March 12, 2013, 03:08:42 PM

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?

Edit your bitcoin.conf:

Code:

#Maximum size, in bytes, of blocks you create, large blocks can be rejected by the standard bitcoin node 0.7 and maybe earlier:
# 250000 is standard and safe for the network, 100000 lowers the latency of getblocktemplate calls which is good for p2pool's efficiency
blockmaxsize=100000

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=20000

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=10000

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.0005

Edit: oh, and restart your bitcoind process to apply changes.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: taltamir on March 13, 2013, 10:44:47 AM

Quote from: taltamir on March 12, 2013, 03:08:42 PM

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.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: taltamir on March 13, 2013, 11:49:23 AM

Quote from: cypherdoc on March 13, 2013, 11:46:59 AM

Quote from: taltamir on March 13, 2013, 11:41:41 AM

Quote from: justusranvier on March 13, 2013, 11:37:21 AM

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.

taltamir

full member

Activity: 196

Merit: 100

Quote from: cypherdoc on March 13, 2013, 11:46:59 AM

Quote from: taltamir on March 13, 2013, 11:41:41 AM

Quote from: justusranvier on March 13, 2013, 11:37:21 AM

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

legendary

Activity: 1764

Merit: 1002

Quote from: taltamir on March 13, 2013, 11:41:41 AM

Quote from: justusranvier on March 13, 2013, 11:37:21 AM

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

full member

Activity: 196

Merit: 100

Quote from: justusranvier on March 13, 2013, 11:37:21 AM

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

justusranvier

legendary

Activity: 1400

Merit: 1009

Quote from: taltamir on March 13, 2013, 11:31:08 AM

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.

Quote from: taltamir on March 13, 2013, 11:31:08 AM

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

full member

Activity: 196

Merit: 100

Quote from: justusranvier on March 13, 2013, 10:51:10 AM

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

legendary

Activity: 1400

Merit: 1009

Quote from: taltamir on March 13, 2013, 10:44:47 AM

Quote from: taltamir on March 12, 2013, 03:08:42 PM

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

full member

Activity: 196

Merit: 100

Quote from: taltamir on March 12, 2013, 03:08:42 PM

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?

Syke

legendary

Activity: 3878

Merit: 1193

Quote from: Smoovious on March 13, 2013, 01:33:53 AM

Quote from: Syke on March 13, 2013, 01:28:48 AM

Quote from: Dabs on March 13, 2013, 12:49:20 AM

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.

deepceleron

legendary

Activity: 1512

Merit: 1028

Quote from: ?? on ??

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

Quote from: deepceleron on March 12, 2013, 12:19:00 AM

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.

tytus

sr. member

Activity: 250

Merit: 250

We are running an older version of the client than 0.7 but had problem with the database (on Debian) long time ago:
https://bitcointalksearch.org/topic/m.890951

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

caveden

legendary

Activity: 1106

Merit: 1004

Quote from: solex on March 12, 2013, 09:08:59 PM

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.

Smoovious

hero member

Activity: 504

Merit: 500

Scattering my bits around the net since 1980

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

Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 4. (Read 155474 times)