So, I got sick of MySQL's buggy time zone handling and made an improvement to my script. For this to work, you need to add apc_port as an INTEGER DEFAULT 0 column to the worker table. Set the port to toggle when reboot is requested, or leave at zero to ignore that worker. #!/bin/php
<?php
$threshold=15*60;
$con=mysql_connect("__DB_HOST__","__DB_USER__","__DB_PASS__");
mysql_select_db("__DATABASE__",$con);
$restarts=array();
$q="SELECT * FROM worker WHERE apc_port!=0";
$r=mysql_query($q);
while($row=mysql_fetch_assoc($r)){
$restarts[$row['id']]=$row['apc_port'];
}
reset($restarts);
while(list($key,$val)=each($restarts)){
$q="SELECT * FROM work_data WHERE worker_id=".$key." ORDER BY time_requested DESC LIMIT 1";
$r=mysql_query($q);
if(0!=mysql_num_rows($r)){
$row=mysql_fetch_assoc($r);
$lastts=strtotime($row['time_requested']." GMT");
if((time()-$lastts)>$threshold){
$url="http://__CGI_HOST__/cgi-bin/apc_restart.cgi?".$val;
$junk=file($url);
}
}
}
?>
|
|
|
|
|
Coins can be divided far beyond two decimals. Currently, they can go to .00000001, and we can change the protocol to go deeper if necessary in the future (unlikely to be necessary in my lifetime).
Difficulty is adjusted by agreement on the network. Every 2016 blocks, each node computes a new difficulty for the next 2016 blocks based on the timestamps from the previous blocks.
There is no single place to bomb to stop bitcoin. You would have to stop essentially the whole internet.
|
|
|
|
I hear you... it's just that this logic also sells pyramid schemes. What's the difference between me selling BTC versus a 32-dollar bottle of wongo juice whose intrinsic value is maybe 50 cents? (I live in Utah which has got to be the "wongo juice scam" capital of the world).
 What is this intrinsic value you speak of? |
|
|
|
Because bitcoin solutions arise from such a fantastically large number of fantastically unlikely events— giving a fairly high overall rate, the confidence bounds are fairly small even for a single example.
Rubbish. The only thing that you can tell from a single sample is how unlikely it would be for you to repeat it in the same amount of time. You can tell absolutely nothing at all about the amount of work actually done. Say I get a block, and returned the result to you in a nanosecond. What is more likely? Option A) I got really lucky. Option B) I have more hashing power at my disposal than the theoretical hashing power of the entire solar system, should it ever be converted into a computer. |
|
|
|
Just start a new blockchain with massive hashing power thrown at it right from the start so no-one can complain that it started off ridiculously easy. Yes they can. The computing power necessary to secure the blockchain will always increase, thus at some arbitrary point in the future, the difficulty of currently generated coins will be "too low". If the reward (50BTC) were not an arbitrary constant, but pegged logarithmically to the difficulty, that would even this disparity out some even more...a proposal I have suggested in the past and seemed relatively palatable (at least compared to the strong sentiment against "don't mess with our block chain") The reward (per miner) is pegged linearly to the difficulty right now. Why would logarithmically be better? |
|
|
|
I'll give 5 BTC to anyone who can provide an economic definition of "hoarding" which does not rely on personal preference and is demonstrably different than "saving".
In our current system, saving almost always means "deposit in a bank". Bank deposits are still in circulation, since the banks use the deposited funds for lending. (That isn't really true. In reality, banks make loans, and then seek deposits to meet reserve requirements.) By contrast, stuffing currency under your mattress could be seen as hoarding. That money is prevented from circulating by being under your mattress. That meets the second part of your criteria, but there is no way to meet the first criteria. All asset allocation is a matter of personal preference. Bank account, mattress, gold bars, fancy cars, all preferences. But only one of them actually keeps cash out of action. |
|
|
|
|
Running a node (needed for solo mining) talks to the world constantly, but at a very low rate.
|
|
|
|
|
It is not yet an equilibrium system. But it will be if it catches on. And if it doesn't catch on, then who cares about hoards of coins?
|
|
|
|
|
Never seen a webserver go down before? Sometimes it takes more than a couple of hours to get them back up.
|
|
|
|
|
Ok. Here is the thing about the bitcoin hoarding arguments.
If people are sitting on bitcoins instead of spending them, then the amount in circulation will fall, and prices (of everything) will fall too. These low prices will provide an incentive for "hoarders" to spend their coins while prices are low. Which means that the amount in circulation will go up, which will cause prices (of everything) to go up. Which will cause people to hold onto their coins instead of spending them. Which will cause prices (of everything) to fall. These low prices will provide an incentive for "hoarders" to spend their coins while prices are low. Which means that the amount in circulation will go up, which will cause prices (of everything) to go up. Which will cause people to hold onto their coins instead of spending them. Which will cause prices (of everything) to fall. These low prices will provide an incentive for "hoarders" to spend...
Get it?
The one thing that I wish that everyone understood when they got out of high school is the concept of the dynamic equilibrium.
|
|
|
|
Afterburner, I suggest you start your own block chain with your superior ruleset. I'm sure everyone will see how awesome it is and drop Bitcoin like a hot bowl of semen!
Unfortunately, bitcoin has other severe design damages. It's code should be completely rewritten from scratch, preferably in Haskell programming language. Because bitcoin algorithms has business with huge amount of money, they must be formally verified, like seL4 microkernel. So, that is HUGE amount of work, I can not do it myself alone. I may just write 'boundary' design conditions: - mining amount of BTC, per unit time, should be proportional to CPU/GPU power, but in degree LESS than 1, till 90% BTC will be mined, algorithm must prohibit any parallelisation like ATI GPU does with current bitcoin algorithm - distributed system should reject any possibility to group miners or peers in pools by design: they should be completely independent forever - mining difficulty should be normalized to attract at least 1 000 000 miners world-wide, being on-line each day, on average - transaction propagation should work in 'soft' real time conditions: we must guaranty that ANY transaction should be completed in 10 minutes, without paying fee, and if fee is 1% of transaction volume, we must guaranty that ANY transaction should be completed in 10 seconds - if client wish, he could able to get possibility to de-anonymize, and to attract third-party that can roll back a transaction, if second-party is unhonest Awesome! Please, please, please, please don't post here again until you are done writing it and have formal verification and proof of correctness in triplicate. |
|
|
|
|
Any idea why my one Diablo miner occasionally goes idle when using the proxy? Seems to happen at random, sometimes a few minutes, sometimes many hours.
|
|
|
|
Kuji, let us example a hypothetical scenario. Let's say I am flipping a fair coin several thousand times. Do you believe it is impossible for me to calculate the odds of getting ten heads in a row because "You can speak with statistical certainty about it in bulk, but not at small scales"? Because it is, in fact, possible to calculate exactly the odds of that happening, as any introductory Statistics student could tell you.
This is no different than Bitcoin. In fact, the distribution of measurements is exactly the same between the two scenarios (results of coin-flipping and results of hashing to find improbable hashes); both fit a Poisson distribution.
I will refer you to the earlier chapters of a typical college-level Statistics book, especially the parts on calculating probabilities.
Who the hell is Kuji? And your example is nothing at all like bitcoin. You can calculate the odds of getting 10 in a row out of X thousands of flips. And then if you do X thousands flips repeatedly, say Y times, the number of 10-in-a-row events in reality will approach your calculation as Y grows larger. Better example. You have a billion sided die, and you throw it and it comes up showing "1". Should I infer from that event that you had actually thrown the die 500 million times? If you are looking for a good book on statistics, I suggest Savage's Foundations of Statistics. Slog your way through that and you'll have a MUCH better understanding of what statistics can, and cannot, do. Oh, and a drinking problem. |
|
|
|
|
Then again, if all the miners shut down, I think the lack of new blocks would be the least of our concerns.
|
|
|
|
I am just wondering how far bitcoin needs to be entrenched in world adoption before similar competing systems start changing the game.
It needs about 127,809 blocks worth of entrenchment. Ah, crap. Too late, but so close. |
|
|
|
|
Is it still doing quadruple payments?
|
|
|
|
|
That doesn't really prove much. JackRabiit could have just read what you said you were going to say, and then said it.
|
|
|
|
|
It is complicated. In purely technical terms, and I apologize if this is too detailed for people without a solid understanding of computers and networking, they should feel free to skip it: "It got fucked up".
Should be back soonish.
|
|
|
|
Search, and ye shall find. http://forum.bitcoin.org/index.php?topic=9945.0You need to edit (or more likely create) a bitcoin.conf file to set a username and password that your node will allow to connect. It goes in %APPDATA%\bitcoin\ (on XP, this is C:\Documents and Settings\YOUR USERNAME HERE\Application Data\bitcoin\ ). server=1
rpcuser=USERNAME
rpcpassword=PASSWORD
rpcallowip=*
rpcport=8332
That should get you started. If you aren't behind a NAT box on private IPs, change rpcallow to the one IP that you are connecting from, or the subnet. You then use that info as the parameters to your miners, either as discrete arguments, or by packing them into a URL. Details will vary by miner. |
|
|
|
No, they are not measurements. There is no way to measure how much work went into finding any given hash, unless you are actually monitoring each and every miner involved.
I think you don't actually know what a measurement is. If you ask everyone coming into the emergency room complaining of stomach pains "Did you eat cucumber in the last 24 hours?" is that not a measurement? Even though the results will be be contaminated by noise and biases? If the census randomly selects 100,000 houses out of a million to get demographics from, is this not a measurement? In this case we know the hashrate by virtue of the network reporting when it finds a block.No. The only thing you know at this point is the time (roughly) that this block was found. This is a measurement of _well_ defined process with explicable behavior and we can speak with certainty about it.
Yes, well defined, but non-deterministic. You can speak with statistical certainty about it in bulk, but not at small scales. Think radioactive decay. I can give you a very accurate estimate of how long it will take for a mole of U-235 to decay halfway, but I can't tell you anything at all about how long it will be until the next hit on your geiger counter. Unlike my silly examples its not subject to much in the way surprising biases or unknown sources of noise. (Because, e.g. if broken clients diminish our hash rate— thats not a random effect we'd wish to exclude) about all there is to worry about is how you time the blocks: If you time from the blocktimes you're subject to node timestamp stupidity if you measure locally you will be subject to a small amount of network propagation noise. But bitcoin propagation time is miniscule compared to the average time between blocks.
Regardless, If the expected solution rate is r then the proportion of times in which a block will take longer than x is e^(-1/r*x).
Moreover, the particular process at play here has its maximum likelihood value at the mean. So you don't have to do any fancier math than taking an average to reach the most accurate measurement possible given the available data.
So, e.g. if we see long gaps then we can say with very high confidence that the _measurement_ being performed by the network is telling us that the hashrate is almost certainly low.
As far as the timestamps go— yes, bitcoin network time can be wonky. So don't pay any attention to it. If you have a node with good visibility you'll observe the blocks directly.
Gah. You understand the statistics, but you can't seem to accept the implications. I'll say it again. The time to find one block tells you nothing about the amount of work that went into finding it. When you start talking about large numbers of blocks, you can start saying things like "the probability is very high that the network hashing rate was X over this long interval". This is not the language of measurements. It is the language of estimation. |
|
|
|
|
Show Posts
