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.
Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 6. (Read 155564 times)
March 12, 2013, 09:48:34 PM
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.
March 12, 2013, 09:45:06 PM
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. 
March 12, 2013, 08:42:11 PM
Sweet summary ...
, levity is always useful at times like these too ... after all it's just bitcoin, who needs em?
March 12, 2013, 08:08:59 PM
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]
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.
March 12, 2013, 07:55:36 PM
Incredible this
March 12, 2013, 07:34:31 PM
I had to share this.
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.
March 12, 2013, 07:18:29 PM
Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!
March 12, 2013, 07:09:03 PM
March 12, 2013, 07:06:46 PM
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.
March 12, 2013, 07:04:54 PM
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?
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?
March 12, 2013, 05:56:27 PM
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.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.
March 12, 2013, 05:46:49 PM
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.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.
March 12, 2013, 05:30:30 PM
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
. 
March 12, 2013, 04:51:58 PM
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?
March 12, 2013, 04:36:35 PM
Thanks for the insight and taking care of things so swiftly.
March 12, 2013, 03:08:59 PM
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. ^^
March 12, 2013, 02:33:33 PM
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.]
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.
March 12, 2013, 02:20:20 PM
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?
March 12, 2013, 02:14:08 PM
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.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.1540252We will have to roll forward to 0.8 ASAP. There isn't any choice.
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.
March 12, 2013, 02: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?
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?
Jump to: