tvbcof
Legendary
Offline
Activity: 4704
Merit: 1276
|
|
March 12, 2013, 05:47:57 PM |
|
So the solution is to continue to increase the block size as demand provokes this issue then? I guess.. because what else? Are you going to appeal to people to do less transactions, hoping that it would solve the problem? I don't believe you can i.e. convince satoshidice to drop down their lucrative business, just because other ppl's transactions are getting queued... Why should they care anyway, if they pay the same fees as you do? Since we don't have other solution at hand, scaling up the storage limits seems to be the only option ATM. Unless we're OK with increasing the fees? I'm totally OK with increasing fees. I thought that was, by design, the way to modulate load. If Mike is saying something like "yes, that's the way we modulate load, and yes, transactions that didn't make the cut are eventually purged, but BDB was not up to the task of processing under the currently configured garbage regime" then I'm totally down with that and feel that switching to LevelDB is an appropriate response. But I'm not sure that is what he is saying which is why I asked. I'm also saying that to me, working on the 'garbage collection' mechanism and/or tuning strikes me as a high priority line of development, and this seems like an opportune time to do it. As always, as a user I hope for the highest degree of transparency as things progress.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
romerun
Legendary
Offline
Activity: 1078
Merit: 1002
Bitcoin is new, makes sense to hodl.
|
|
March 12, 2013, 05:50:44 PM |
|
well, maybe having the concept of "block" is the root of design flaw in the first place.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
|
March 12, 2013, 05:57:02 PM |
|
So the solution is to continue to increase the block size as demand provokes this issue then? I guess.. because what else? Are you going to appeal to people to do less transactions, hoping that it would solve the problem? I don't believe you can i.e. convince satoshidice to drop down their lucrative business, just because other ppl's transactions are getting queued... Why should they care anyway, if they pay the same fees as you do? Since we don't have other solution at hand, scaling up the storage limits seems to be the only option ATM. Unless we're OK with increasing the fees? I'm totally OK with increasing fees. I would not mind it, either. Whatever the community decides, I'm fine with it, as long as it solves the issue of transactions with proper fees waiting hours for the first confirmation. The network really seems to be getting stuck already and I don't think it will just get better by itself.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
March 12, 2013, 06:00:50 PM |
|
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.
Transactions are valid on both branches of the fork. You send 1000 BTC to a merchant on v0.8 it is seen by the merchant on v0.7 so when you attempt to double spend it is rejected by the merchant and/or every relay node. The fork was on BLOCKS not transactions. All the transactions (except coinbase tx which are unspendable for 100 blocks) on the v0.8 branch are visible on v0.7 branch and vice versa.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
|
March 12, 2013, 06:10:20 PM |
|
Transactions are valid on both branches of the fork. You send 1000 BTC to a merchant on v0.8 it is seen by the merchant on v0.7 so when you attempt to double spend it is rejected by the merchant and/or every relay node. But the real world is not as perfect as it should be. It's all about statistics and chances - probability. If you have X connections from your node to the network, and you broadcast transaction A to half of them, while at the same time broadcasting transaction B (spending the same 1000 BTC) to the other half - then you have a significant chance that both; A and B will be mined in the alternate branches. And by "significant chance" I mean: significant enough to cause the panic...
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
blockbet.net
Member
Offline
Activity: 112
Merit: 10
Admin at blockbet.net
|
|
March 12, 2013, 06:19:37 PM |
|
Not sure why everyone is so panicked.
When I have a lot of money invested in Bitcoin and I get an error message and I'm not sure what it means... Well, let's just say that I got a bit worried. Not everybody knows the technical aspects that well. I'm glad they addressed the issues quickly and in a professional manner though.
|
Bitcoin Sports Betting online at www.blockbet.net, featuring NBA, NHL, UFC, football (soccer) and international competitions. Fast payouts directly to your wallet, great win odds, no need to register or deposit. Bet in just a few clicks now!
|
|
|
taltamir
|
|
March 12, 2013, 07: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?
|
|
|
|
Blowfeld
Newbie
Offline
Activity: 53
Merit: 0
|
|
March 12, 2013, 07: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. 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://bitcointalk.org/index.php?topic=145184.msg1540252#msg1540252Unless 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.
|
|
|
|
EuroTrash
|
|
March 12, 2013, 07: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?
|
<=== INSERT SMART SIGNATURE HERE ===>
|
|
|
Blowfeld
Newbie
Offline
Activity: 53
Merit: 0
|
|
March 12, 2013, 07: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.]
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.
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
|
March 12, 2013, 08:08:59 PM Last edit: March 12, 2013, 08:25:10 PM by marcus_of_augustus |
|
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 .... 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.htmlThis link is for you Mike H. ^^
|
|
|
|
The-Real-Link
|
|
March 12, 2013, 09:36:35 PM |
|
Thanks for the insight and taking care of things so swiftly.
|
Oh Loaded, who art up in Mt. Gox, hallowed be thy name! Thy dollars rain, thy will be done, on BTCUSD. Give us this day our daily 10% 30%, and forgive the bears, as we have bought their bitcoins. And lead us into quadruple digits
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
March 12, 2013, 09: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? 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.
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
March 12, 2013, 10:30:30 PM Last edit: March 13, 2013, 12:03:55 AM by notme |
|
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 .
|
|
|
|
evilpete
Member
Offline
Activity: 77
Merit: 10
|
|
March 12, 2013, 10: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. 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.
|
First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
|
March 12, 2013, 10: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. 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.
|
|
|
|
Mysticsam_3579
Newbie
Offline
Activity: 30
Merit: 0
|
|
March 13, 2013, 12:04:54 AM Last edit: March 13, 2013, 11:53:59 AM by Mysticsam_3579 |
|
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?
|
|
|
|
pwrgeek
Newbie
Offline
Activity: 13
Merit: 0
|
|
March 13, 2013, 12:06:46 AM |
|
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.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
March 13, 2013, 12:09:03 AM |
|
|
|
|
|
nebulus
|
|
March 13, 2013, 12:18:29 AM |
|
Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!
|
|
|
|
|