I've adjusted the prices for inflation, as well as what has been sold. The value goes up every day, so I'm trying to keep the prices fair to those that want to buy. Sorry to those that bought when the price was higher, that's just the way the market goes.  |
|
|
|
How about a compromise, have it show the current "difficulty" in either a number or scale function. People love visual stuff. When the scale is lower, expect it to rain, when the scale is high (or higher number) don't get your hopes up.  |
|
|
|
It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.
The difficulty can adjust down as well as up.
The network should be generating close to 6 blocks per hour now.
Yeah, I've noticed the "10 second blocks" are gone, replaced with 419 and 741 second block generation with no more in the last 20 minutes. That should keep those server farms on hold for a while  Now, correct me if I'm wrong, but now that block generation is taking a lot longer, doesn't that mean that the lucky person who got the block is going to take a lot longer to be verified by the network that he/she was the winner before they could ever spend it? |
|
|
|
|
Anyone notice, that for Windows Clients anyway, when you connect a bunch of other clients to it manually (through the -connect option) that if you go over 8, the windows client ends up cutting out the "outside world" connections and stick with the original 8 or more internal machines thinking that it's the entire network?
I never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just "internal clients" only.
When this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from "the network" and all the other clients all think that they are the entire network now. If I do a "netstat -a -n" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)
It's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.
|
|
|
|
The proof-of-work difficulty is currently 45.38. (see http://www.alloscomp.com/bitcoin/calculator.php) It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54. The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase. Holy.... Satoshi, what happens if the rush dries up for a bit; some of the slashdotters or whoever get tired? Does the difficulty ever go back down? If I'm reading the source code correctly, it should go up and down based on how much CPU is being thrown at it. So if someone rented a super computer to drive up the difficulty for a week, then it vanished, the difficulty should float back down. |
|
|
|
|
I think at this point, raw CPU power is being surged over by luck. There is a topic here where a guy wrote a website script to display stats on how fast blocks are being generated. Most of them are being built in as little as 2 or 3 minutes, sometimes 10 to 30 seconds. I've noticed lot of a my old PCs are winning blocks now (these machines can barely muster 90 khash/s)
|
|
|
|
It's like they always say, "To make a billion dollars, you have to start with 4 billion dollars first"  |
|
|
|
That's cool, but is the time right on block discovery? My PC army discovered 2 of the last 10 blocks and it took them a lot longer than a few seconds? [edit] Seems right now, I missed the block by 1 when counting backwards. So cool, blocks are discovered pretty fast. So people don't need mega-fast multi-core systems to win the discovery lotto  |
|
|
|
That's why I'm glad we have people like you here to participate in the discussion as well. A room full of "yes men" is a dangerous thing. |
|
|
|
The market is reporting the last trade at 1.8USD/BC. What is going on?
Some joker probably put in a bid for 1000BTC for 10000USD, looks like it's already been removed, last I checked 0.0365USD to BTC It would have had to be accepted by someone in order to be shown as "last" though, right? The person making the offer and the person accepting could have been the same person all along to try and inflate the value. |
|
|
|
I'm not certain that accounts for the very slow startup.
I set up bitcoin on a new (relatively fast) computer, connected by gigabit ethernet to another running machine, and -connect= to send it directly to that node.
It still took a really long time to bring the blocks over. It would pause for a long time at 501, 1001, etc. Every 500 blocks would have a long pause before starting again.
I'm just questioning whether it's all disk and CPU bandwidth constraints, or if there's something in the system that injects pauses or timeouts.
It's Disk related for sure. I had a server that was about 5 years old, but had one of those 10,000RPM SCSI arrays in it. CPU wise, it was about close to a PIV @ 2GHz (single core) with low FSB speed, etc. But when it started to download blocks, it was getting them faster than any PC I had seen before. The disk array was lit up like a Christmas display and it finished off 65k blocks in under a minute. So I knew then it was not so much the CPU or RAM, but the disk speed (or caching perhaps?) that seems to make the difference in that "first time" block download. |
|
|
|
|
Agreed, I had a 933MHz PIII generate (2) blocks when I have other machines running multiple cores that don't generate anything. It's mainly luck of the draw with those that have faster systems having a bit better luck.
I setup a new system for the farm a few hours ago and it got a block within the first hour, I was stunned, it wasn't even that fast, like 135 khash/s old PC.
|
|
|
|
For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000
No. SHA512 and Whirlpool exist, are well defined, well supported, well analyzed, and they exist for a reason. I'm sure the same was said back when 40, 64, 128, and 256 bit encryption was coming out. SHA512 is part of SHA2, I remember when everyone was talking about how insecure SHA1 was with that significant *flaw* and how we all need to move to SHA2 because it was well defined, well supported, and well analyzed; sound familiar? There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it,
Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations. You are basically betting the entire economy (if you believe bitcoins will succeed anyway) on no one developing a means to halve the effective bit length as has been done with e.g. AES. It's careless. I'm not betting anything for the simple fact that unless you can see into the future, we work with what we have in front of us. We can debate all day that in the future computers will be a million times faster or that some math genius is going to discover a flaw in the system that would bring everything down. I'm well aware of many peer reviewed papers and tech journals, even blogs about encryption. Not everything in existence, as I don't have the time for all of it, but enough practical experience to be able to visualize what it would really take to do what you propose. are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?
Ten years, assuming only minor flaws in SHA256. If there is a major flaw (again, see the push for SHA-3) there is a much more serious problem. There does not appear to be a clear mechanism for handling a compromise of the basic algorithm, and there should be. 10 years is a good a guess as my 1 million years. SHA1 still has not been broken, but you can brute force/exploit flaws on a super-computer in under 60 hours if you have $35 million to throw at it. Overall, I hear what you say and if BitCoin jumped in the SHA3 realm, I would sleep just as well at night as I did with it using the older SHA2 realm of technology. I'm not trying to nitpick your post, just offering up my opinion and I certainly respect yours. I think we can both agree that if the encryption is bumped up another notch in the future, it would be a good thing for the system and community as a whole. |
|
|
|
I'm not particularly sold on the technical soundness of this program, honestly. Why use SHA256 rather than Whirlpool or SHA512?
For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000 There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it, are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years? When they can crack SHA256 in under 10 minutes, I'll be worried, but until then, time is on your side. |
|
|
|
The market is reporting the last trade at 1.8USD/BC. What is going on?
Some joker probably put in a bid for 1000BTC for 10000USD, looks like it's already been removed, last I checked 0.0365USD to BTC |
|
|
|
|
Yeah, you are right, works just fine. *smacks forehead for not counting cores ahead of time*, so scrap the prioirty bug then, I'll go back and edit my post. Works just fine on Windows 2000, XP, Vista, and 7
|
|
|
|
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty. I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it. Do you have dual-proc? Are you sure you weren't running a single processor hog? LOL, I think you are right. I've got waaaayy too many PCs around me and it's difficult to keep track of which is single core, dual core, quad, 8 core, etc. I'll test it again on the single proc PC and see what happens. |
|
|
|
Is anyone willing to offer a better rate than the market on 100-500BC? I'd jump at 3cents/BC. I have PayPal available immediately.
What is the most that you would want to buy at once? |
|
|
|
|
You mean the confirmation column on the very left? Screen shot of mine for reference. I already have 1848 confirmations for the one at the bottom if that's what you mean?
|
|
|
|
On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons). But, the priority of the threads all seem to be "nice" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive. [knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin
1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13682 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687 0 9 82 2 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70 9 99 19 - 113704 - 14:52 pts/1 00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71 9 99 19 - 113704 - 14:53 pts/1 00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75 9 99 19 - 113704 - 14:53 pts/1 00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76 9 99 19 - 113704 - 14:53 pts/1 00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77 9 99 19 - 113704 - 14:53 pts/1 00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79 9 99 19 - 113704 - 14:53 pts/1 00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81 9 99 19 - 113704 - 14:53 pts/1 00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84 9 99 19 - 113704 - 14:53 pts/1 00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86 9 99 19 - 113704 - 14:53 pts/1 00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87 9 99 19 - 113704 - 14:53 pts/1 00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89 9 99 19 - 113704 - 14:53 pts/1 00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90 9 99 19 - 113704 - 14:53 pts/1 00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
I'm not exactly sure what the "Start BitCoin on window system startup" is suppose to do? On library errors, you get a /usr/lib/libstdc++.so.6 'GLIBCXX_3.4.11' not found on older linux clients (one was only a year old). I checked the file, it's just linked to libstdc++.so.10 but I don't know if that's a high enough version or not. |
|
|
|
|
Show Posts
