Pages:
Author

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

legendary
Activity: 2912
Merit: 1060
If this was a debate you don't have to follow along. You still have that power. But the majority voted. Also, this is still an infant community.

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.
Wasn't one of the advantages of Bitcoin supposed to be that you don't need anyone's permission to use it? Rather than asking someone to stop or, worse, trying to make them stop, the better path is to fix yourself so they're not hurting you.
legendary
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
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.
Wasn't one of the advantages of Bitcoin supposed to be that you don't need anyone's permission to use it? Rather than asking someone to stop or, worse, trying to make them stop, the better path is to fix yourself so they're not hurting you.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo



Sweet summary ...  Cheesy,

levity is always useful at times like these too ... after all it's just bitcoin, who needs em?
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
Also, I'm afraid it's very easy to say "just test for longer" but the reason we started generating larger blocks is that we ran out of time. We ran out of block space and transactions started stacking up and not confirming (ie, Bitcoin broke for a lot of its users). Rolling back to the smaller blocks simply puts us out of the frying pan and back into the fire.

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.

.....
 1dicegEAr   56000      0.85449 |    62398 |   52977 (0.85686) |    8850 |     571 |   77209.45 |   76593.02 |   400.54 |    616.42 |  99.202
 1diceDCd2   60000      0.91553 |    95911 |   87374 (0.91620) |    7992 |     545 |   70581.58 |   69778.98 |     0.50 |    802.59 |  98.863
 1dice9wVt   64000      0.97656 |    16558 |   15147 (0.97956) |     316 |    1095 |   23993.71 |   23581.20 |   240.19 |    412.51 |  98.281
----------------------------------------------------------------------------------------------------------------------------------------------
           small (bets < 4 BTC) |  3522656 | 1452152           | 2054095 |   16409 |  766592.38 |  752057.27 |   261.23 |  14535.10 |  98.104
            big (bets >= 4 BTC) |   114417 |   52348           |   61777 |     292 | 2635378.11 | 2579381.45 | 23628.70 |  55996.66 |  97.875
----------------------------------------------------------------------------------------------------------------------------------------------
                                |  3637073 | 1504500           | 2115872 |   16701 | 3401970.49 | 3331438.72 | 23889.93 |  70531.76 |  97.927
----------------------------------------------------------------------------------------------------------------------------------------------

SD Profit before fees:      70531.76560380 BTC (2.073%)
Cumulative Fees Paid:        2837.93797500 BTC
SD Profit after fees:       67693.82762880 BTC (1.990%)
Pending Liabilities:          -74.93245984 BTC
Final SD Profit:            67768.76008864 BTC (1.992%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 11423662  :  SatoshiDice Tx:  6698542  (58.6%)
Blockchain MB:   4904.6  :  SatoshiDice MB:   2753.4  (56.1%)[/font]


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.
newbie
Activity: 15
Merit: 0
legendary
Activity: 1190
Merit: 1004


I had to share this.  Smiley

Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!

It's only required for miners (Edit: They can use v0.8 under the default settings apparently), providing miners stick to the v0.7 compliant rules.
hero member
Activity: 490
Merit: 500
... it only gets better...
Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!
legendary
Activity: 2576
Merit: 1186
newbie
Activity: 13
Merit: 0
Not sure why everyone is so panicked.  We only orphaned 25 blocks and the only danger was that you would accept the coins minted in those blocks (all transactions using other coins would eventually end up in the other chain as well).  If we just followed the network rules and waited 100 blocks to accept minted coins then there was actually no danger at all.  What am I missing? 
You are missing the fact that it was a great opportunity to double spend any coins.
Once: you send 1000 BTC paying to merchant that uses bitcoin 0.8
Second: you pay the same 1000 BTC to another merchant who has an older client and thus is "looking" at the alternate branch, where the 1000 BTC has not been spent yet.

Anyone not waiting for multiple confirmations and not listening on the network for double spend attempts on transactions this large deserves what they get.
newbie
Activity: 30
Merit: 0
Have anyone even thought about if bitcoin was worldwide when this happened?

Good luck asking the stock exchanges in Tokyo and London to stop processing deposits and withdraws!
Or a little market in Russia to wait for making its sales.

Think if this had lasted i couple of days?
legendary
Activity: 1246
Merit: 1077
Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.
The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.
If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

It's not that simple  More than 51% of the miners were running 0.8.  One single pool with a large block size created a valid block that all 0.8's accepted.  All the 0.7 miners and users rejected it due to the lock table overflow.

I don't believe this can happen again because >51% of miners are now on 0.7.  Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on,  it will find itself automatically orphaned.

Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain.  That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork.


If no miners mined on 0.7, the users would not get any confirmations on their fork and would upgrade as soon as they noticed, without loss of money. The problem lies in how there were significant numbers of miners on older versions, and those would be exactly those that would be hard to reach and encourage to upgrade.
member
Activity: 77
Merit: 10
Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.
The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.
If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

It's not that simple  More than 51% of the miners were running 0.8.  One single pool with a large block size created a valid block that all 0.8's accepted.  All the 0.7 miners and users rejected it due to the lock table overflow.

I don't believe this can happen again because >51% of miners are now on 0.7.  Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on,  it will find itself automatically orphaned.

Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain.  That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork.
legendary
Activity: 1904
Merit: 1002
IN 3 hours the price of bitcoins will be around 14 bucks. Mark my words

Words marked.  I hope you didn't trade on your own advice Wink.
legendary
Activity: 1400
Merit: 1005
I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.

(Almost) catch 22? Or where did I get it wrong?

I would think every Bitcoin user running a full node would also have to upgrade, else they would receive errors and not be able to download/process/verify the latest blocks as well?  It's kind of a forced upgrade once the miners make the switch, since the pre-0.8.1 users wouldn't have very many (if any) new blocks generated on their fork.
hero member
Activity: 533
Merit: 500
Thanks for the insight and taking care of things so swiftly. 
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.


Pre-0.8 nodes can up their limit voluntarily via Berkeley DB config file settings, so there does not have to be this rush to upgrade, or rush for the exits ....

Quote

There just needs to be a consensus (and enforcement) on what those limits need to be set at instead of this "default" behaviour (implicit network rule).

Edit:

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

This link is for you Mike H. ^^

newbie
Activity: 53
Merit: 0
This has been interesting to read.  The problem has almost corrected itself, and may be corrected by the time I press "submit".

Users never needed to downgrade.  Miners didn't really need to downgrade either.  They needed to stop producing very large blocks.  And they needed to be poked to ignore the higher block, temporarily.  [Downgrading accomplishes both, but I doubt that most miners went to that trouble.]


Amazing. So you read this entire thread, came away with zero clue as to what happened, and decided to start preaching to the rest of us?

Maybe try reading it again.

Fact:  The official news at the top of the forum (today, 16 hours after the event) says "News: The bug appears to be resolved now. Merchants can accept transactions. Mining on 0.8 is OK, but you should not increase the target block size from the default."

I'm not sure which of my quotes, above, you believe were clueless or preachy.  Do these quotes differ materially from today's official "News".  There was a lot of FUD on this thread.  Much of it was unwarranted.  I thought this part of my post was clarifying the facts, not preaching.

hero member
Activity: 728
Merit: 500
I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.

(Almost) catch 22? Or where did I get it wrong?
newbie
Activity: 53
Merit: 0
Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.
The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.
If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

Also, I'm afraid it's very easy to say "just test for longer" but the reason we started generating larger blocks is that we ran out of time. We ran out of block space and transactions started stacking up and not confirming (ie, Bitcoin broke for a lot of its users). Rolling back to the smaller blocks simply puts us out of the frying pan and back into the fire.

We will have to roll forward to 0.8 ASAP. There isn't any choice.
The official release of 0.8.0 was just 3 weeks ago:  https://bitcointalksearch.org/topic/m.1540252

Unless you are the IT department at Citibank, you cannot possibly expect all of your branches and customers to upgrade on your schedule.  Forcing a tight upgrade schedule on customers and merchants will kill bitcoin as surely as a forked blockchain.  I think LukeJr suggested a 2 year upgrade window.  Seems more reasonable than 3 weeks.  Bitcoin isn't the same as Ubuntu, but look at their support window.
full member
Activity: 196
Merit: 100
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?
Pages:
Jump to: