Watching.
Seems BDB's MAX_LOCK needs to be taken into account also, for backward compatibility.
Yes. All miners should be migrating to v0.8 as soon as possible (while maintaining default limits), so that the above is no longer a factor. Edit 0.7 until 0.8.1 is available.General question. Is Deepbit too conservative for its own good? They are refusing to upgrade from version 0.3. Deepbit, please prove me wrong! |
|
|
|
50% of this thread is unlearning what we should already know! 1) Perhaps in the future devs should abstain from using words like EMERGENCY... URGENT... and so on. This is one of those times when less is more. A simple message saying users don't move your coins for a little while, miners revert to 0.7 until the blockchain catches up would have been enough.
Wrong. In Bitcoin we call it as it is! If there is an emergency then we want to quickly see notices from Pieter Wuille telling the truth. (Thanks Pieter!) Spin is for slimy politicians, big corporate apologists. 2) The chain can fork, by accident, and things can go back to normal in a matter of hours. I still think that's a win.
+1 Absolutely. 3) MtGox doesn't give a rat's ass about Bitcoin... or at least not as much as it does about its own fees. I won't touch them again with a ten foot pole.
Wrong. Mt.Gox behaved exactly as it should have done. They deserve praise by keeping their internal market open and allowing the market to give a verdict during events. To argue otherwise is to join the stone-throwers here: http://www.guardian.co.uk/business/2008/jul/17/pakistan.protest.shares4) The rolling out of new versions, in the future, should be done differently (but we knew that, didn't we?)
+1. This is a priority. There needs to be a plan where discussions are held with pool operators to ask/negotiate an upgrade timetable for each new version. It seems too informal. Such plans could be posted on the forum so everyone knows what is expected. |
|
|
|
Before I thought that's the most troublesome topic in bitcoin, but now this bug in BDB opened a window to lift that limit, Gavin you are so lucky!  Would you propose to your fiance while standing in an elevator? Because this thread is showing similar impeccable skills at timing. Anyone reading my posts will know that I have been all for raising the 1Mb limit at the right time, and in the right way. However, after today's events, that time is further away than previously imagined. A lot of reflection and thoughtful planning needs to go into any future change of this nature. More than we might have guessed 24 hours ago. The first lesson of today is how to get people to accept the necessity of an upgrade path. Then how to get people to use it in a reasonable timeframe. Bitcoin can't reach its full potential being backwards compatible with every ancient version previously released. This is a real challenge. |
|
|
|
I am coming to the conclusion that this business is like herding cats |
|
|
|
Any speculation to why people are rushing to sell their bitcoins now?
Because the market is smarter than anyone and knows that if this problem happens once it can happen again and worse. Black day for Bitcoin, but time will heal. The market will regain confidence once it figures out how awesome it is to be able to really aware of the problem, if it were a bank the investors would have no knowledge until it stinks. and also how quickly it was fixed. pretty damn amazing. Yep. And if the fx rate stabilizes and begins its normal behavior from $45 then it would seem to have taken only a 5% hit from this experience or $25m off the "market cap". Not too bad... |
|
|
|
In any case, an fx rate of $200 will mean that all utxo since the change will be spendable. This is not a permanent problem then...
They were always spendable, apart from to those who wished to make a mountain out of a molehill. I believe you! I need to learn more about bitcoin tx minutiae before I can begin to argue this  |
|
|
|
Any speculation to why people are rushing to sell their bitcoins now?
Because the market is smarter than anyone and knows that if this problem happens once it can happen again and worse. Black day for Bitcoin, but time will heal. |
|
|
|
|
it's done. more fireworks now...
|
|
|
|
If they did that, all 0.7 clients would have been left dead in the water, unable to rejoin the main chain and forcing end users to upgrade on the spot. 0.8 clients can rejoin the 0.7 chain so this was why it was preferred.
In hindsight I bet it will turn out that sticking with 0.8 would have resulted in a more rapid resolution. 0.8 already had a majority of hashing power, and now that some of the miners have downgraded it looks like the 0.7 chain is ahead but just barely. We spent several hours in the worst case of a near 50/50 split in hashing power and it's taking a long time for the new branch to pull ahead. Maybe, but a fork has been averted, just a reorg event now. This is a victory in itself. More importantly, this is a real lesson for what happens if Bitcoin comes racing up to the 1Mb block size limit and has to do an emergency change. It will be a train wreck indeed. It clearly requires a seriously long parallel-run period, with a hand-holding "help-desk" using a LOT of cajoling and encouragement to get absolutely as many nodes, of all types, upgrading before the 1st 1Mb block gets mined. |
|
|
|
Too bad v0.7 was incompatible with v0.8 then right? Developers should have just recommend pushing ahead and fuck those who hadn't upgraded. You are aware that v0.8 had the majority of the hashing power right?
No. I was not aware of the split in hashing power. Personally, I agree 100% that they should have pressed on with v0.8, with that knowledge. However, as I am not involved in the dev sphere, then I am going to defer to their collective judgement on the best course of action, which was to revert. |
|
|
|
incompatibility between versions should be called (at least) an issue imho...
My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about. Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7 Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested. Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for. What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site. The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen? A block rejected by all nodes is by definition invalid. Someone wil produce a new valid one, and the building will continue as normal. Is there any evidence that all nodes would reject it? It looks like, according to Pieter's preliminary statement, that certain configurations will (correctly) accept the blocks. Immediate solution is upgrading to 0.8, or manually setting the number of
lock objects higher in your database. I'll follow up with more concrete
instructions.
It only takes 51% of the hashing power to decide which is the next valid block. So the "certain configurations" above can find themselves in the minority; too bad for them. This is the way it has to work. |
|
|
|
incompatibility between versions should be called (at least) an issue imho...
My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about. Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7 Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested. Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for. What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site. The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen? A block rejected by all nodes is by definition invalid. Someone will produce a new valid one, and the building will continue as normal. |
|
|
|
This has never happened before right? A fork in the chain?
The chain forks many times a day. 1 block gets orphaned each time. Today 11 blocks got orphaned at once. THIS HAPPENShttp://www.youtube.com/watch?v=-zvCUmeoHpw |
|
|
|
Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).
What the hell are the devs thinking? What is the testnet for? Testnet is not only to test userland code, but it is a fine place to test mining code too damnit!
Now know that from now on, you should ALWAYS test stuff like this on Testnet first.
Core Dev are always having to maintain the engines on a jet aeroplane flying at 35,000 feet. I don't notice any oil on your hands! |
|
|
|
Memo. When the chain fork is resolved and post-mortem out the way, ask gmaxwell how many dead puppies are in block 225430 on the 0.8 chain. And now a more elaborate explanation:
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.
|
|
|
|
isn't 0.01 btc closer to 50c?
5 cents actually. But even this amount is unnecessary (if it wasn't for the transaction flooding situation we are seeing) because the 25 BTC block reward is very high in US$ terms and will stay that way for years. Hell, now you can even buy a whole new computer for solving 1 block, unimaginable in 2010. It would be nice to see Bitcoin savage the payment processing marketplace with negligible cost transactions. That is, fees rising gently in the medium-term. Unless apps which use Bitcoin as a messaging system are controlled then it won't happen smoothly, and nuclear options become closer to implementation. Redo your math. It is 1/100th of BTC/USD, so about $0.44 at current rate.
Edit: indeed, about 44c of course! |
|
|
|
Actually, that would be perfect as it would cap SD flow at 3%*MaxBlockSize/AvgBlockSize of Bitcoin's capacity leaving the rest for everyone else. Nice.
Right. There is no easy way around it for SD; they have to pay someone more. Not only this, but if SD has tons of spam transactions like they do now, they'll never fit into 6 blocks per day and will have to start overflowing into the next block, leaving users for days without any confirmation of unsuccessful gambling. Now, tacotime, please let me explain why you have found the nuclear option, but I do think we need to consider softer options as well. The nuclear option will produce a high amount of fees, but, because the block reward is so high in dollar terms ($1150 at present) Bitcoin does not need a fees arms race when it is trying to gain wider acceptance on the internet and bricks and mortar shops. https://bitcointalk.org/index.php?topic=149577.msg1595451#msg1595451Also, I do think that zero fees have their place too:
Okay, here we go.
So as I promised, I created the "NFTF" (short of No Forced TX Fee) section on Github.
This isn't going to be anything big & professional, just few lines of code changed comparing to the standard client.
I did it, because i was unsatisfied with standard client forcing people to pay fees, even when they are not necessary at all.
I wrote many complaints about this on multiple topics on this forum, and for unknown reasons the main developers do not want either to remove this broken algorithm, or to improve it. Mining cartel ? CIA-related conspiracy ? Who knows & Who cares. I don't know and I don't care so I am going my own way.
|
|
|
|
OK, I get it now. They always paid 0.5% for a losing bet, but they used to subtract the transaction fee of 0.0005 (50k satoshis) from that, often leaving less than 0, so they'd send you a token 1 satoshi. Now they don't subtract the transaction fee, so the min bet (0.01) pays out the full 0.5% when you lose, which is 0.00005000 BTC, or 5k satoshis. That will result in less dust spam, or at least more easily spendable dust spam. Aha. The mist clears in this jungle. |
|
|
|
My solution for the Satoshi Dice spam is here:
1) Pools or big solo miners remove all transactions from blocks they mine that don't have at least a 0.01 BTC fee attached to them
or
2) which don't have at least 0.01 BTC per each output. So SatoshiDICE could respond by paying a miner which controls just 3% of all hashing strength to include all of SatoshiDICE transactions. On average this operator with 3% of capacity will would get a block four times a day (once every six hours). Actually, that would be perfect as it would cap SD flow at 3%*MaxBlockSize/AvgBlockSize of Bitcoin's capacity leaving the rest for everyone else. Nice. |
|
|
|
retep, that patch sounds like great progress. Regarding SD. the minimum bet is 0.01 BTC, so the minimum payout is 5,000 satoshi as it always returns at least 0.5% Ok. I just checked on github and based on the latest revision dust is considered < 100,000 satoshi However, the fx rate is 3 times higher since that was decided, so 33,000 is a reasonable comparison now. So any SatoshiDice bet above 0.07 will not leave a dust amount for a loss. https://github.com/bitcoin/bitcoin/pull/2100Since then I sampled a few thousand recent bets and found that 54% are 0.06 or less. |
|
|
|
|
Show Posts
