Bitcoin Forum
December 18, 2017, 02:21:19 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: "Required" upgrade for Bitcoin-Qt/bitcoind versions 0.7.2 and older  (Read 2493 times)
JeromeS
Jr. Member
*
Offline Offline

Activity: 55


View Profile
March 19, 2013, 08:27:58 PM
 #21

Two more problems I have with that announcment,

Quote
Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.
Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.


Quote
Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.
How ?

1MHMLCSdxzyaBEYQsQYYNPYkaBjeV1aSNZ
1513563679
Hero Member
*
Offline Offline

Posts: 1513563679

View Profile Personal Message (Offline)

Ignore
1513563679
Reply with quote  #2

1513563679
Report to moderator
1513563679
Hero Member
*
Offline Offline

Posts: 1513563679

View Profile Personal Message (Offline)

Ignore
1513563679
Reply with quote  #2

1513563679
Report to moderator
1513563679
Hero Member
*
Offline Offline

Posts: 1513563679

View Profile Personal Message (Offline)

Ignore
1513563679
Reply with quote  #2

1513563679
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513563679
Hero Member
*
Offline Offline

Posts: 1513563679

View Profile Personal Message (Offline)

Ignore
1513563679
Reply with quote  #2

1513563679
Report to moderator
1513563679
Hero Member
*
Offline Offline

Posts: 1513563679

View Profile Personal Message (Offline)

Ignore
1513563679
Reply with quote  #2

1513563679
Report to moderator
JeromeS
Jr. Member
*
Offline Offline

Activity: 55


View Profile
March 19, 2013, 08:34:37 PM
 #22

I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.

Are you saying you want 2 blockchains going?  Your wording is a little confusing there.

Yes. meant to say if/when the main bitcoin etc...

It would be better than having only one blockchain going in the wrong direction.

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

1MHMLCSdxzyaBEYQsQYYNPYkaBjeV1aSNZ
dree12
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 19, 2013, 08:39:24 PM
 #23

Two more problems I have with that announcment,

Quote
Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.
Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.


Quote
Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.
How ?

0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true.
JeromeS
Jr. Member
*
Offline Offline

Activity: 55


View Profile
March 19, 2013, 08:46:42 PM
 #24

0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true.
What does set_lk_max_locks do ? and why didn't we have this problem before people started mining on 0.8 ?

1MHMLCSdxzyaBEYQsQYYNPYkaBjeV1aSNZ
tysat
Legendary
*
Offline Offline

Activity: 966


Keep it real


View Profile
March 19, 2013, 08:54:23 PM
 #25

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?
evilpete
Member
**
Offline Offline

Activity: 77



View Profile
March 19, 2013, 08:58:36 PM
 #26

Two more problems I have with that announcment,

Quote
Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.
Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.

Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.

Quote
Quote
Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.
How ?

Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.

First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2870


View Profile
March 19, 2013, 09:04:45 PM
 #27

Also, I think our benevolent dictator dev(s?) decided the only thing they can do to push this (unnecessary) upgrade is to use stronger language without giving any reasons or details, which is comforting to me tbh.

I share Luke-Jr's view that hardforks should usually have two years of advance notice, but this hardfork is definitely necessary sooner. The behavior of old nodes is closely tied to the behavior of BDB: the limits are not on the number of transactions or bytes, but on database-specific things which aren't easy to track. Without this hardfork, all full nodes would be required to either use BDB or come up with some very complicated heuristics (which don't currently exist) to guess at what BDB would do. Even worse, old nodes don't always have consistent limits. It isn't reasonable to leave the network in this messy state for two years.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
JeromeS
Jr. Member
*
Offline Offline

Activity: 55


View Profile
March 19, 2013, 09:09:53 PM
 #28

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?
It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.


Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.
I think there's an agreement between everyone involved that the pools won't make 0.7 incompatible blocks until May 15. I was just saying that technically what the announcement said wasn't true.

Quote
Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.
Why would anyone generate such a block ?

1MHMLCSdxzyaBEYQsQYYNPYkaBjeV1aSNZ
JeromeS
Jr. Member
*
Offline Offline

Activity: 55


View Profile
March 19, 2013, 09:18:27 PM
 #29

I share Luke-Jr's view that hardforks should usually have two years of advance notice, but this hardfork is definitely necessary sooner. The behavior of old nodes is closely tied to the behavior of BDB: the limits are not on the number of transactions or bytes, but on database-specific things which aren't easy to track. Without this hardfork, all full nodes would be required to either use BDB or come up with some very complicated heuristics (which don't currently exist) to guess at what BDB would do. Even worse, old nodes don't always have consistent limits. It isn't reasonable to leave the network in this messy state for two years.
Okay, it makes more sense to me now... (still uncomfortable with the whole thing though)
anyway, thanks for explaining.

1MHMLCSdxzyaBEYQsQYYNPYkaBjeV1aSNZ
bitcool
Legendary
*
Offline Offline

Activity: 1441

Live and enjoy experiments


View Profile
March 19, 2013, 09:27:22 PM
 #30

For a voluntary, consensus-based, p2p system,  "required" change is mostly bad; luckily this time, it not a protocol change (yet).  

https://bitcointalk.org/index.php?topic=20866.0
evilpete
Member
**
Offline Offline

Activity: 77



View Profile
March 19, 2013, 09:49:21 PM
 #31

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?
It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.


Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.
I think there's an agreement between everyone involved that the pools won't make 0.7 incompatible blocks until May 15. I was just saying that technically what the announcement said wasn't true.

It's more than the pools though.  You don't have to be a pool to generate a bdb-killer block.  If you look at the 0.8.1 patch (which the big pools are running), they are rejecting blocks with more than 4500 transaction references.  This is lower than what the 0.7's could handle which was somewhere around 4800-4900.  The irony here is that if somebody makes a valid block with 0.7 that had 4700 references, it'll be rejected by > 51% of the hashpower due to the 0.8.1 may 15 restriction even though it would have worked with all existing 0.7 installations.

Remember, you don't have to be a pool to generate blocks.  I could have an avalon, or I could get lucky with my gpu miner and a tweaked bitcoind that tried to gather up as many SatoshiDice transactions as possible in order to break 4800-4900 or so.  If I could figure a financial advantage in knocking 10% of the miners off the main chain and I got lucky, then I could do it.  Anyone can do it so long as it is a valid block and meets the rules of > 51% of the hashpower.

The bigger problem is that for some clients it might be 4911, and others 4850, or it might change to 4870 after a restart.. The limit is determined by internal state of 3rd party library code, not the bitcoin code rules.  Simply running 0.7 isn't enough of a "is it valid?" test.  Suppose I wanted to knock off just the 4850 and 4870 nodes?  I could generate a block (if I was lucky with mining) that would fork off those guys and leave the 4911 nodes on the chain for a bit longer.

It is this level of non-determinism in old clients that is the problem.

The only thing that is preventing mischief right now is that the bulk of the hashpower switched to 0.8.1 already.  If they were running 0.7 or earlier, a malicious pool (or a lucky person) could generate blocks to split them up.

Quote
Quote
Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.
Why would anyone generate such a block ?

If I was a miner and wanted to knock 10-20% of my competition  off the chain so I got a bigger slice of the pie? Maybe I was USGOV trying to undermine bitcoin confidence?  Maybe somebody trying to just cause trouble..  If it can be done, somebody will do it.

Anyway, the train has already left the station.  If you want to be certain of being able to get confirmations on the main chain after may 15th, you have to do *something* before then.

First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
tysat
Legendary
*
Offline Offline

Activity: 966


Keep it real


View Profile
March 19, 2013, 09:50:02 PM
 #32

It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.

But imagine the 1% trying to figure out where to spend their bitcoins(0.7) since 99% of people will be accepting bitcoins(0.Cool.  Plus a split in theory doubles your bitcoins, but only for the existing ones, as you'd have coins in both blockchains spent independently of each other.  I think a whole different protocol (litecoin, namecoin, etc) is a lot better than having 2 bitcoin blockchains.
Eri
Sr. Member
****
Offline Offline

Activity: 265


View Profile
March 19, 2013, 10:00:45 PM
 #33

This isnt directed at anyone specific, its more a general statement.

Everyone that disagrees with this change either doesnt fully understand the situation or Doesnt fully understand bitcoin Or both.

If this wernt a good choice you can believe this, there would be allot of people who know what they are talking about complaining and pointing it out in a serious way.

the biggest problem with bitcoin is that a huge number of people dont fully understand it when they think they do and then go on to talk about 'problems' that dont exist. bitcoin has allot of traps where you think you get it, learn something else and build on what you know then realise you didnt quite get it and that a previous assumption was wrong.

im not going to explain it. but keep in mind, if you think you fully understand bitcoin and dont update. you run the risk of being left behind because you were sure you understood it. your better off being safe then sorry.


one thing i personally hope this situation drives home for people, is that they need to reasonably keep up to date.

personally, whether its 2 months or 2 years, i feel some people/businesses wont update and will be left behind. but we cant force them, and we cant stay in the past because they dont want to update. they will learn the hard way that keeping up to date is important.
Littleshop
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
March 19, 2013, 10:06:08 PM
 #34

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

Worry less about wording and more about upgrading?
+1

The language is clear.  If you don't like it, don't upgrade.  It is required because it is not a protocol change but a BUG FIX.  If you do not upgrade, the bug will be quite evident for you.  

evilpete
Member
**
Offline Offline

Activity: 77



View Profile
March 19, 2013, 10:35:30 PM
 #35

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

Worry less about wording and more about upgrading?
+1

The language is clear.  If you don't like it, don't upgrade.  It is required because it is not a protocol change but a BUG FIX.  If you do not upgrade, the bug will be quite evident for you.  

It'll work for a short while for people that don't upgrade (or apply the bug fix in their old client) but it won't take too long before transactions fail verification on the main chain and can't be confirmed.

I predict, in vague hand-wavey terms:
  • There will be a chain fork in fairly short order.  Somebody will generate a large and complex block to prove a point and split off the non-upgraded/fixed clients.
  • Some holdouts will split off on their own blockchain fork, either accidently or by refusing to go with the majority, or leftover botnet members.
  • Block generation rates will crash on the alt chain but there will be a few miners running that people have forgotten about.

By May 15th the difficulty will be huge..  blockexplorer.com predicts the next jump will be from the current 4.7 million to 6.1 million..  If the next 2016 block calculation is "close" at the time of the alt chain fork, then the difficulty won't drop much.  If it is distant enough to cause the calculation to drop then it'll take forever for the alt chain to get there.  The arrival of the asic miners is turning the dial up so high that the alt chain just won't be able to generate enough blocks to survive.

The people with the high end hardware won't be sending blocks to the alt chain, they'll be looking to get a ROI on the main chain ASAP.

First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
mb300sd
Legendary
*
Offline Offline

Activity: 1260

Drunk Posts


View Profile WWW
March 19, 2013, 10:37:27 PM
 #36

For anyone who can't figure out how to do this... simply click and run.

https://mega.co.nz/#!xpxH2D7D!PSmX-Q6aL1W5AZnptZlyxnDyUvV41sgogoow5JQ0gpg

Code:
echo set_lg_dir database > %APPDATA%\Bitcoin\DB_CONFIG
echo set_lk_max_locks 120000 >> %APPDATA%\Bitcoin\DB_CONFIG

1D7FJWRzeKa4SLmTznd3JpeNU13L1ErEco
johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
March 19, 2013, 10:48:14 PM
 #37

Always good to check the current node version distribution:

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

If this chart is correct, more than 5000 nodes runs 0.8.0, 261 nodes have upgraded to 0.8.1 ... Rest more than 6000 nodes are 0.7.2 or below. But I suppose those 0.8.0 nodes have the soft block size limit set at 250K to be compatible with 0.7.2 or before





evilpete
Member
**
Offline Offline

Activity: 77



View Profile
March 19, 2013, 10:55:06 PM
 #38

Always good to check the current node version distribution:

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

More than 5000 nodes on 0.8.0, 261 nodes upgraded to 0.8.1 ... but I suppose those 0.8.0 nodes have the block size limit set at 250K

Also keep in mind the difference between nodes and hash power.  This is also looking at version strings and can't tell whether the DB_CONFIG fixess have happened on old versions.

0.8.0 doesn't require an upgrade.  The special thing about 0.8.1 is that it has special time-limited block validation restrictions that are intended to enable the pool operators to upgrade.  After May 15th, 0.8.1 behaves the same as 0.8.0.  More than 51% of the mining hash power is applying the 0.8.1 restrictions to make sure no bdb-busters get into the chain.

First they ignore you, then they laugh at you, then they fight you, then you win.
- Mahatma Gandhi
johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
March 19, 2013, 11:09:32 PM
 #39


0.8.0 doesn't require an upgrade.  The special thing about 0.8.1 is that it has special time-limited block validation restrictions that are intended to enable the pool operators to upgrade.  After May 15th, 0.8.1 behaves the same as 0.8.0.  More than 51% of the mining hash power is applying the 0.8.1 restrictions to make sure no bdb-busters get into the chain.

As I understand, it was 0.8.0 client generated backward incompatible block last week, obviously they need to upgrade. Can you elaborate on that "time-limited block validation restriction"?

eleuthria
Legendary
*
Offline Offline

Activity: 1750



View Profile
March 19, 2013, 11:52:03 PM
 #40


0.8.0 doesn't require an upgrade.  The special thing about 0.8.1 is that it has special time-limited block validation restrictions that are intended to enable the pool operators to upgrade.  After May 15th, 0.8.1 behaves the same as 0.8.0.  More than 51% of the mining hash power is applying the 0.8.1 restrictions to make sure no bdb-busters get into the chain.

As I understand, it was 0.8.0 client generated backward incompatible block last week, obviously they need to upgrade. Can you elaborate on that "time-limited block validation restriction"?

The majority of hash power is already on 0.8.1.  It's the hash power of the network that needs to be on 0.8.1 to prevent a fork event prior to the May 15th deadline.  Regular users are fine running 0.8, because 0.8 is compatible with 0.8.1.

As long as majority hash power is on 0.8.1, there will not be a hard fork event until the May 15th deadline.  There could be a soft fork where somebody generates a 0.8.1 rule-breaking block that also breaks 0.7, but since most hash power is on 0.8.1, which will not accept blocks that break 0.7 until May 15th, it will eventually converge back into a blockchain that is compatible with all nodes, just like how the previous fork was eventually fixed when majority hash power created a chain that was longer than the incompatible fork.

RIP BTC Guild, April 2011 - June 2015
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!