My solution:
Open up a pre–order list from Monday till mid–july, then close it.
This will give everyone ample time to order
Make an inventory of what has been ordered and start producing exactly that amount
When all the pre–Orders have been produced, pack them and ship them off at the same day in october, be it jalapenos, singles or rigs.
That way everone will receive their products around the same time
This is the most fair proposal I've heard. +1. Announcing a preorder a day before you do it and not even posting the announcement on your website is a little.. weird. +2. Fair for everyone. +3 this is a fair solution. +4 BFL please read this and change your plans. +5 Sounds good to me. ++ +7 Aaannd.... Thread. +8. ITS A + PYRAMID! + 9 I will put in an order if you do this. +10 +11 ...... because I like the pyramid +12 |
|
|
|
|
fwiw, dreamwatcher is right to be concerned about ESD protocol. ESD is not a "boogeyman."
I fried my HDD 2 years ago due to ESD.
|
|
|
|
It does not. Your logic is flawed. There is no guarantee of a solution in 2^52 operations or even 1 trillion * 2^52 operations. QC doesn't allow for improved chances. It always will find a solution or won't. That isn't possible in your imaginary 2^52 scenario.
The keyspace is 256 bit. There just happens to be (currently) 2.1568E+61 independent solutions.
Analogy:
You find a password file with 2.1568E+61 independently created (and unique) passwords. All the passwords are hashed SHA-256. You need to break into one account. You don't care which. How many quantum operation will it take to brute force the password file. You won't find a single computer science professor, academic, or cryptographer anywhere who would say anything other than 2^128.
Well, I am a CS academic and I say the answer is 2^195 classically and 2^(195/2) quantumly. If you have 2^61 hashes, each 256 bits in length, then a random password matches one of your hashes with probability 2^(61)/2^(256) = 2^(-195). So after 2^195 trials, you're probably good. Applying Grover reduces the 195 by two. The miner would be flawed.
1) The zeroed hash wouldn't be valid.
2) A 52 bit hash WILL ALWAYS BE SOLVEABLE in 2^52 operations. It is mathematically impossible to NOT FIND A SOLUTION in 2^52 operations. Routinely the bitcoin network takes much longer than 2^52 operations to find a solution. The reason is the KEYSPACE IS NOT 52 bit. It is 256 bit AND there just happens to be multiple solutions.
You misunderstood because the point is it is the same. As far as mining is concerned, bitcoin might as well be truncating the output of SHA256 beyond the first 64 bits or so, because that is all that is used to determine if a block is valid (you can tell from the first 64 high-order bits of the hash if it is below target or not). It might be easier to, instead of thinking about numbers of solutions and some finite search space, think about the probability of solutions and then the size of the search space doesn't matter. So I have a function f(x) where x is anything, and I have a distribution s.t. the probability f(x) = 1 is p. Then classically, I can find such an x in time roughly 1/p by repeatedly guessing random x. (e.g. if you have a coin which comes up heads 1/10 of the time, you should see heads after 10 trials roughly). A natural extension of Grover's algorithm says you can find such an x in time 1/sqrt(p). 2.1568E+61 does not equal 2^61 |
|
|
|
Besides the fact that a higher difficulty will make a 51% attack that much harder, yeah. No really.
A 51% attack happens when blocks are being found way faster than the difficulty allows. Raise the difficulty, and bang - 51% is out of commission, at least until he can get his speed up again.
Huh? A 51% attack could also be called a 51% takeover, and happens when 1 person owns 51% of the hashing power, and takes control of the entire network (rewrites the blockchain). The larger the network is, the harder for 1 person to own 51%. It's a LOT harder to gain 51% of a 200TH/s network than it is a 2TH/s network, for example. A larger network is inherently more resilient to a 51% takeover, you see? A larger difficulty is just a side effect of that larger network. The difficulty of that 200TH/s network will be 100x that of the 2TH/s network, right? The difficulty itself doesn't actually protect against an attack (or takeover), but the factors that caused the difficulty to raise are what protect us. Exactly, that's what I was saying. no, its not what you were saying. what i said is completely true. difficulty has nothing to do with the 51% takeover. raising or lowering the difficulty would have 0 effect on the 51% takeover. bottom line is that you need 51% of the network's total hashing power. |
|
|
|
From what I understand, the difficulty adjusts based on network speed, and the whole point of difficulty is to stop a single node from having too much power over the network ?
Question: Will the ASIC still work once all coins have been generated ?
the whole point of difficulty is to make sure the time it takes to find a block is consistent. it has nothing to do with the 51% attack. |
|
|
|
|
not if you're someone like me that thinks the price of bitcoins is going to skyrocket some day.
|
|
|
|
are there any plans to add the option to cpu mine with windows?
I don't want to make it too easy for botnets to abuse BFGMiner. Is there a legitimate need for CPU mining for people who don't know how to compile themselves? yes, my friend says he gets 30mh/s with his cpu. every little extra bit helps imo. |
|
|
|
|
are there any plans to add the option to cpu mine with windows?
|
|
|
|
In all honesty I'm sorry to see this, and long term I envision these projects will diverge too much for there to be code going to and from each of them. It may well be that cgminer becomes the dead project and I'll stop maintaining it. Good luck.
plz don't stop maintaining cgminer. i love it. the only thing i would change about it is to add the option to mine with cpu. |
|
|
|
ckolivas! please put the option to use CPU mining back in cgminer! I will donate all my coins! Many of my friends and I REALLY need this option.
One of the main reasons I stopped including it was the lack of adequate donations. I have earned about .2BTC from people donating for CPU mining, and approximately 1000 times that for GPU mining development. How much are you offering? I doubt you'll be able to offer me enough to make me interested, but if you do, sure, I'll build you a binary and make it available for everyone to download (I don't do things in secrecy). 2btc? |
|
|
|
|
ckolivas! please put the option to use CPU mining back in cgminer! I will donate all my coins! Many of my friends and I REALLY need this option.
|
|
|
|
Q: What happened to CPU mining?
A: Being increasingly irrelevant for most users, and a maintenance issue, it is
no longer under active development and will not be supported unless someone
steps up to help maintain it. No binary builds supporting CPU mining will be
released but CPU mining can be built into cgminer when it is compiled.
FOUND IT!
anyways. how can i compile cpu mining into cgminer??? |
|
|
|
|
Q: What happened to CPU mining?
A: Being increasingly irrelevant for most users, and a maintenance issue, it is
no longer under active development and will not be supported unless someone
steps up to help maintain it. No binary builds supporting CPU mining will be
released but CPU mining can be built into cgminer when it is compiled.
FOUND IT!
|
|
|
|
when i try to enable cpu mining i always get this error "[2012-04-17 12:47:23] 2 9: -C: unrecognized option" same thing happens when i try the --enable-cpu param. Any suggestions?
Read the included README carefully and with great attention... I just did. Can you give me a hint? a quote maybe? sorry for my noobiness  i just can't figure this out |
|
|
|
|
when i try to enable cpu mining i always get this error "[2012-04-17 12:47:23] 2 9: -C: unrecognized option" same thing happens when i try the --enable-cpu param. Any suggestions?
|
|
|
|
|
thats nuts....... can this effect any other processes?
|
|
|
|
|
my p2pool log says Local: 300mh/s but i'm not getting any shares or btc or anything. cgminer is definitely mining but p2pool is only picking up my hashrate and not showing any shares.
what am i doing wrong?
for some reason i can't copy the text in p2pool.
also. i can't seem to get the graphs page to work. it tells me to install python-rrdtool. I installed python 2.7 and zope interface, but when i tried to install rrdtool when i run install.cmd i get this error:
RRD module for activestate perl 5.8.x
-------------------------------------
The system cannot find the path specified.
'ppm' is not recognized as an internal or external command,
operable program or batch file.
Press any key to continue . . .
also, when i try using my IP address instead of 127.0.0.1 it doesn't work. and i have ports 9332 and 9333 forwarded.
any suggestions?
|
|
|
|
awesome update. the new kernel gives me a +2% increase in mh/s.
i have a suggestion.
i like how you can set the intensity to d and it changes the intensity to maintain desktop interactivity. but its just a little bit too intense for me in windows but is perfect while playing world of tanks (weird, i thought gaming would be more intense) so i keep having to change the intensity depending on what i'm doing.
my suggestion is that you make an option to set the intensity to d -2 or d -1 or something. so the intensity is still dynamic but is 1 or 2 less (or more) than d.
some people might want to use d +1 or d +2. who knows? for me, intensity of d -1 would be perfect.
Read what it says at startup when you run dynamic intensity... sigh. --gpu-dyninterval <arg> Set the refresh interval in ms for GPUs using dynamic intensity i've been playing with this and i guess i just don't understand how it works. when i set it to 20 it stays at 4 intensity and when i set it to 1 it goes back and forth between 3 and 4 intensity. so there is a difference between --gpu-dyninterval 1 and --gpu-dyninterval 20 but its barely even noticeable and you can't use negative numbers. i have a radeon 4850 btw It's a fairly sensitive tuning tool. The difference between the default 7 and 1 should be quite significant to the interface. Don't get too hung up on what the intensity setting reported is since that's done once every 5 seconds but at dyninterval of 1 the value is updated 1000 times per second. 1 is very interactive desktop with lower hashrate, 1000 for example is higher hashrate less dynamic dekstop. hmm, my friend with a 5870 is saying that --gpu-dyninterval does effect his intensity. but for me, it seems to do nothing at all. with gpu-dyninterval 1 i still have lag in windows but if i use intensity -2 the lag goes away and i only lose about 5mh/s. i guess ill stick to just using static intensity for now |
|
|
|
awesome update. the new kernel gives me a +2% increase in mh/s.
i have a suggestion.
i like how you can set the intensity to d and it changes the intensity to maintain desktop interactivity. but its just a little bit too intense for me in windows but is perfect while playing world of tanks (weird, i thought gaming would be more intense) so i keep having to change the intensity depending on what i'm doing.
my suggestion is that you make an option to set the intensity to d -2 or d -1 or something. so the intensity is still dynamic but is 1 or 2 less (or more) than d.
some people might want to use d +1 or d +2. who knows? for me, intensity of d -1 would be perfect.
Read what it says at startup when you run dynamic intensity... sigh. --gpu-dyninterval <arg> Set the refresh interval in ms for GPUs using dynamic intensity i've been playing with this and i guess i just don't understand how it works. when i set it to 20 it stays at 4 intensity and when i set it to 1 it goes back and forth between 3 and 4 intensity. so there is a difference between --gpu-dyninterval 1 and --gpu-dyninterval 20 but its barely even noticeable and you can't use negative numbers. i have a radeon 4850 btw |
|
|
|
|
Show Posts
