My paranoid concern is that lots of thought has gone into recommending an option that is incompatible with BDB. Mike, I understand this comment is most likely bullshit, but you should understand it is legitimate. Even if bullshit, it teaches us a valuable lesson, and that is to not trust people who rush is into tweaking the system without due dilligence. That is exactly what happened, regardless of Mike's intentions.
For something as important as Bitcoin, testing is crucial. 0.8 didn't even have a second release candidate before it went live. But sometimes we have to realize that cohesion is even more important. If something is rushed in, like 0.8, we should immediately all switch to it. In fact, 0.8 didn't introduce any new bug. Instead, it revealed a bug present in all prior versions of Bitcoin. Merchants and miners should have upgraded immediately after release, rather than delay the upgrade so late. |
|
|
|
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. |
|
|
|
|
With the recent blockchain fork, people have been forced on edge. One of the earliest pools to discover the problem was the Eligius mining pool, thanks to running simultaneously 0.6 and 0.8. To help avoid these problems in the future, I propose that large merchants and miners use a "supernode" similar to Eligius's setup. They would run more than one version, and if they ever disagreed immediately shut down all mining or payment processing. These supernodes would cost marginally more than full nodes to run, and would help improve network security greatly.
|
|
|
|
By default Bitcoin will not created blocks larger than 250kb even though it could do so without a hard fork. We have now reached this limit. Transactions are stacking up in the memory pool and not getting cleared fast enough. What this means is, you need to take a decision and do one of these things: - Start your node with the -blockmaxsize flag set to something higher than 250kb, for example -blockmaxsize=1023000. This will mean you create larger blocks that confirm more transactions. You can also adjust the size of the area in your blocks that is reserved for free transactions with the -blockprioritysize flag.
- Change your nodes code to de-prioritize or ignore transactions you don't care about, for example, Luke-Jr excludes SatoshiDice transactions which makes way for other users.
- Do nothing.
If everyone does nothing, then people will start having to attach higher and higher fees to get into blocks until Bitcoin fees end up being uncompetitive with competing services like PayPal. If you mine on a pool, ask your pool operator what their policy will be on this, and if you don't like it, switch to a different pool. Ahem. How much thought and work has gone into offering the first option in this list? Don't blame this option, blame the lack of testing all Bitcoin versions have gone through. If a chain-splitting bug was present since 2009, and only resolved "by accident", you can hardly blame the advice banking on there being no such bug. |
|
|
|
0.8 is not flawed. The flaw lied in 0.7 and below. If an upgrade was hastened, the problem would not have been a problem at all.
Sadly, 0.8 is flawed— its "one job" was to faithfully follow the behavior of 0.7, "bugs" and all. It did not. Had we known about this behavior in 0.7 or had testing turned it up we would have made sure 0.8 behaved the same way. This is the nature of a distributed consensus system. The primary definition of right and wrong is "consistent" and if you aren't consistent you aren't right, no matter what. The testing should have happened with the older version of Bitcoin. I don't see how testing 0.8 would fix this issue, given that 0.8 fixes the bug. |
|
|
|
So let me get this right,
IF we'd all upgrade to .08 then the blocksize restriction would have been lifted, but because not many did we now have a fork and because the 0.7 blockchain is longer we should revert to that until a proper upgrade path to 0.8 is made available?
so is 0.8 inherently flawed, I thought there was a consensus that the blocksize should be lifted? I think this is very poor
A simple retards guide summing up key points for and against blocksize restriction or lifting should have been stickied in the forum for some time and a poll taken by everybody not just miners, devs and long time posters.
An upgrade should have been built and tested on an isolated blockchain if that is possible,
A announcement about the upcoming availability of the upgrade should have been stickied referring to the poll results and post aforementioned,
A target date and block number should have been specified and downloads of the new client should have been made available along with an "alert£"
Some time before the specified date / block another last chance alert should hav been issued, anyone not upgrading after the date / block should have been left in the dust.
0.8 did not lift the blocksize. The block being big is just a specific problem, it could have been a block too small or too strange (the problem was, however, that the block was very big—but not "too big"). The problem was 0.7 and below rejecting a block that should have been accepted. 0.8 is not flawed. The flaw lied in 0.7 and below. If an upgrade was hastened, the problem would not have been a problem at all. |
|
|
|
There's nothing magic about the number 6 - it is simply an arbitrary choice of 1 hour's worth of blocks.
If you only require 1 confirmation it's very easy to perform a Finney attack. You basically mine until you create a conflicting transaction, keep it secret, perform your spend, wait for the confirmation and then release the conflicting transaction to the network, undoing the spend. You now have at least a chance that the chain will be based on your block instead of the other one. Even a 10% success rate is enough if you have a low overhead transaction you can exploit.
With two confirmations you would have to mine two blocks in a row with your conflicting transaction before you spend. That's much more rare, but still statistically possible to do at least on very rare occasions, and might be viable for high value, very low friction transactions.
By 6 confirmations it simply won't work. The frequency that you'll just happen to mine six blocks before the rest of the network gets one is extremely low unless you have a significant double-digits percentage of global hashpower. At that point you're already close to a 51% attack.
On the other hand, 2 confirmations is usually enough for low value transactions involving nonfungible products.
False. The number of confirmations determines the probability of attack, not the time. The time is irrelevant because Bitcoin doesn't care about time. 6 confirmations is an arbitrary choice, but it is not chosen because it is 1 hour's worth of blocks. In fact, recently, this time has been closer to 50 minutes. |
|
|
|
|
Perhaps this idea has some merit. It would have prevented the brunt of our recent chain-fork.
|
|
|
|
|
Ironically, more testing on testnet would not have helped this issue. Significantly less may have, as the network would have more time to upgrade.
I think the blame rests upon miners and merchants here. Miners should always upgrade and merchants should run FAN nodes.
|
|
|
|
Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.
Yeah, through a coordinated process. Most likely it will go like this: 1) We'll pick a block number on which to switch. 2) A new .8 version will be released the switches as of that block number. 3) It will be announced that everyone must update before that block number. 4) The switch will take place automatically. what happens to users who do not upgrade? and if bitcoin requires such drastic hand holding shouldn't this be programmed into the client? some type of ksplice like update? They will be left in the dust, as it is their bug. They cannot claim that the fork is against Bitcoin's spirit. This is similar to a previous hard-fork where the old chain allowed negative transaction fees, except the initial remedy is reversed. The long-term remedy is the same. |
|
|
|
PANIC SELL!! Price has just dropped to $30... Im buying at $29  On which exchange? He's bullshitting. There really isn't a big issue. In fact, I usually don't upgrade my software until there are other versions out after the one I upgrade to, so that I can avoid any issues like this. So everyone just relax. The issue isn't with 0.8, it's with 0.7 and lower. Because people like you didn't upgrade, we had to endure this chain fork. Yep, my 600mhash is really fucking the network. If all the pools, miners, merchants, and users upgraded, this would have been a non-issue. |
|
|
|
PANIC SELL!! Price has just dropped to $30... Im buying at $29 On which exchange? He's bullshitting. There really isn't a big issue. In fact, I usually don't upgrade my software until there are other versions out after the one I upgrade to, so that I can avoid any issues like this. So everyone just relax. The issue isn't with 0.8, it's with 0.7 and lower. Because people like you didn't upgrade, we had to endure this chain fork. |
|
|
|
2 @ 6.25
There was no reason for you to increase your bid... you already had 3 at your last price of 5.5 Only 7 slots are being sold, so he had no slots at 5.5. |
|
|
|
Anyone know if 750k is ok?
750 ≤ 500? Thanks for sharing your amazing knowledge of which number is bigger. We are all enlightened. I was referring to this: When you start again in a few hours, you should set your maxblocksize to 500k or less.
Based on the text, it would seem that 750k is not OK. |
|
|
|
Anyone know if 750k is ok?
750 ≤ 500? |
|
|
|
I scammer-tagged him.
I see no reason to thank you personally, but the newbies sure will  . Good move on your part! |
|
|
|
Let's say that you lived to be 100, and each second of your life, you generate 1 trillion unique, truly random bitcoin addresses to use.
Now, let's assume that the population of the planet exploded to 100 billion people, and that they each lived to be 100 years old, and that they each also generated 1 trillion bitcoin addresses to use each second of their lives. Let's further assume that all of these addresses are unique, and truly random.
Going by the important number, the size of a bitcoin address (160 bits), what is the chance of you generating an address that collides with that of someone else on the planet?
Best I can do right now is to turn this into an analogy (I'm sure the math will be corrected, but it's close enough to make the point.)
Imagine that I tell you that I've hidden a small treasure box, one inch cubed, that I've buried under a few inches deep somewhere in the 48 contiguous United States. You have a sewing needle. You have to guess where in the U.S. the box is, with NO data, and mark the location by sticking the needle into the ground on top of where you think the box is.
Your chance of finding that box with that needle in one try is millions of times better than your chance of creating an address collision with 100 billion other people, each generating 1 trillion unique, truly random addresses a second for 100 years straight.
So long as you're generating truly random bitcoin addresses, a collision should never be a problem.
Actually, with those (albeit unrealistic) numbers you'd have generated quite a few collisions. ~3.5×10 16 to be more precise, and even more if RIPEMD is not reversible. Assuming RIPEMD-160 is a reversible function, there are 2 160 possible addresses. Therefore, the likelihood any pair of addresses is a collision is 1/2 160. Here, we are theoretically generating 10 11 (# people) × 10 12 (# addresses/s) × 60 × 60 × 24 × 365 × 100 (time) addresses. That's around (exactly, actually) 3.1536×10 32. The number of address pairs for n number of addresses is n(n-1)/2. With so many addresses, n(n-1) is virtually equal to n 2. So there are approximately 4.97259648×10 64, but this approximation is off by something very insignificant. Dividing by 2 160, we will have quite a few (i.e. too many to count) colliding pairs. 2 160 is big, but not that big. |
|
|
|
i dont think its as unlikely as these guys let on although still pretty unlikely. this is because computers are not capable of generating random numbers and all of these crazy maths rely on the assumption that we are dealing with truly random numbers. Still with that being said dont expect it to happen to you.
AFAIK Bitcoin uses a TRNG (truly random numbers) on Linux at least (/dev/random), so this should not be a concern on Linux OSes. |
|
|
|
*Sigh* So, what you're saying is that I can't sign up for an account on any website on the internet? The ToS's count as contracts.
Absolutely. if a website says you have to be older than a certain age to sign up, and you aren't, but you signup anyway - YES, you are scamming them. Oh, REALLY? I'll play along with this shit too. He didn't have a sign-up age. Also, just so you know, lying =/= scamming. Idiot. I never said any particular person/website had a sign up age. I said when you lie to a website to gain access to which you otherwise would be denied, which I'm sure you have, you are scamming them. Since profanity is a sign of a weak mind, there is no more sense in talking to you. Typical ignorant teenager.  He was not the only one that lost money. Many people, including me, have done so. Therefore, whether or not his own case is void should have no impact on the verdict. I find your attempted deflection of attention away from the scam at hand concerning. Would you mind revealing whether you have a vetted interest in this case? |
|
|
|
danieldaniel, aren't you 14? You have NO BUSINESS entering into contracts with other people, because they mean nothing in the eyes of the law.
There are three stages of consensus: 1. Negotiation. The two parties discuss the situation with each other and attempt to reach an acceptable solution. Being a minor does not affect this stage at all. 99% of disputes are resolved in this stage. 2. Mediation. The two parties discuss the situation with a third party and the third party proposes an acceptable solution the two parties ratify. Again, there is no reason why being a minor affects this stage. 0.99% of disputes are resolved in this stage. 3. Arbitration. Here, and only here, does the law come in. A third party enforces a solution upon the two parties to ensure consensus. If a minor is entering a contract, the contract may be declared void by the arbiter. 0.01% of disputes are resolved in this stage. There is no reason a 14-year-old has no business entering contracts, because the law only handles 0.01% of cases. Most cases are resolved through the cheaper methods of negotiation or mediation. |
|
|
|
|
Show Posts
