Most "faucets" are a scam to get you to click on ads and pay you nothing but unspendable dust. They are pale imitations of the original Bitcoin faucet.

I've personally put about 10000 coins in this faucet, and it still gives out coins, no strings attached: http://tpfaucet.appspot.com/

Domains get hacked often. The problem is if someone hacked the domain registrar account and transferred the domain away, it may be a bit of work to get it back. It's 7pm on a Friday in Japan, 3am in the US. It will take time through the Transfer Dispute Resolution Protocol if the receiving domain registrar doesn't immediately hand it back on the word of registrar #1.

http://explorer.dot-bit.org/n/45362

the namecoin bitcointalk.bit domain points to the wrong IP address, it was bitcointalk.org in mid 2012 https://dazzlepod.com/ip/50.97.137.52/

Whoever created that needs to not forget about updating it.

100 users and dropping, so note this IP, the DNS record was changed for bitcointalk.org away from the forum.

EDIT: site got it's domain back, no need to worry now.

You are wrong. The truth is not a myth. The higher hashrate of Bitcoin does allow it to fend off a particular attacker better than other alt-coins would fare, but then you go into falsehoods.

https://bitcointalk.org/index.php?topic=177308.msg1853377#msg1853377

If you need help, please read the satoshi paper until you understand it. If you can't understand the statistics, you shouldn't foray into starting topics where you claim to answer some question nobody was asking about.

Sorry, I forgot to actually upload the "other history" file, it's up now and includes other exchanges and currencies. Funny how nobody dropped me the 411 on the 404.

MtGox: we determined it was a bad idea to go through with giving this shady looking individual the banking credentials and passwords of non-consenting users, especially since he got into the scamcoin business.

Me: Hey coinlab, where can I serve you notice? Me and 1000 others will get default judgements against your "company" in every state of the union, even before your lawsuit with MtGox is dismissed in summary judgement.

It's not a bell curve, the probability density function of an exponential distribution looks like this:



Note that the average block time is 10 minutes (1/λ), but 50% of the blocks are less than 6.93 minutes (the median ln(2)/λ).

The reason that it makes no difference is: whether the geometric distribution (which counts individual hashes) is calculated for difficulty 1 or difficulty 10000000, the probability of a quantile (such as calculating the probability of a block taking 100 minutes) is the same within several decimal points. In fact it is already identical to the exponential (continuous) function with three digits by difficulty 1, higher difficulty just makes the density function of geometric converge to exponential with even more digits of identity.

http://math.stackexchange.com/questions/93098/how-does-a-geometric-distribution-converge-to-an-exponential-distribution

Here's a monte carlo simulation of a geometric distribution density, the red line is exponential:

See how much like the exponential it is? This example shows a 0.1 probability; Bitcoin's current probability is 0.0000000000000000231. With a lower probability,the steps disappear and the distribution converges to exponential.

So the answer is: the probability of a block taking 62 minutes (given a constant hashrate equivalent to difficulty) is 0.2029%, whether the difficulty is 1 or a billion.

Only 'technically', on a very small scale, is the variance different. In reality it is unobservable at different difficulties.

Hashing is typically modeled as an exponential distribution, a continuous series, however it is actually a geometric distribution. The probability is so low though, that the R statistics package fails to compute due to overflow errors with statistics on much more than difficulty 1.

The variance is given for a geometric distribution as:



You can see that for extremely small p (probability of one hash finding a block), the top numerator approaches 1, becoming insignificant compared to the p².

The high block times around 20000-30000 has something to do with the satoshi miner and others not making much hashes during that time, there was much less than difficulty 1 worth of mining being done. I could eliminate the first year of Bitcoin to get a better list of long blocks, long due to variance rather than low hashrate.

much harder to forge:

http://explorer.dot-bit.org/n/74491

The difficulty is actually in bits, the field in the block that contains it is called bits, which is decoded into the target.

Here's the current target, a hash has to be smaller than this number:
00000000000001AA3D0000000000000000000000000000000000000000000000

or in binary:
0000000000000000000000000000000000000000000000000000000110101010001111010000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000

The difficulty is easy to comprehend and is what is presented to users. What you are proposing is harder:

>>> math.log(2**256/int('00000000000001AA3D0000000000000000000000000000000000000000000000',16),2)
55.26448364017038

What  "bit" difficulty would be 10% harder?

>>> math.log(2**256/((int('00000000000001AA3D0000000000000000000000000000000000000000000000',16))/1.10),2)
55.40198716392032

Satoshi got it right. Not everyone uses Python as their calculator. Use a base difficulty, where 1 = 1 block find per ~4295032833.0 hashes on average, and higher difficulties are multipliers of that.

Most long blocks came early in Bitcoin, here's 212 blocks (over 100 minutes since last block timestamp)

Note that the block timestamp is based on the mining computer's time, there are more blocks than this with a negative time.

15324 1508.9  
16564 1506.5  
15     1452.6  
16592 1229.7  
20189 1003.4  
19724 785.5    
21438 637.0    
19722 625.6    
28     514.7    
16490 511.4    
20432 507.1    
20364 500.2    
20349 488.8    
21389 468.7    
19565 433.3    
15048 422.9    
19726 415.1    
74638 411.3    
21446 392.9    
21527 384.7    
21466 384.2    
16468 380.7    
26242 368.3    
21359 357.8    
21449 342.3    
21463 330.1    
21382 327.1    
21376 321.3    
21383 308.6    
23418 305.4    
21585 302.0    
23434 300.7    
20384 299.6    
16215 294.8    
15424 285.1    
23433 277.6    
21442 263.8    
16286 263.8    
21464 261.6    
22945 260.1    
22527 259.3    
20325 248.2    
21458 238.0    
21374 234.9    
19725 234.2    
21418 232.2    
21444 230.8    
28705 226.3    
21440 225.9    
21348 225.1    
1390   224.3    
11964 223.8    
169   222.4    
21462 220.2    
21403 217.6    
21331 217.3    
20435 216.1    
8231   214.7    
20439 211.4    
1398   211.2    
32647 208.9    
13889 208.9    
20190 205.3    
16271 202.3    
20187 198.4    
21361 196.8    
13898 196.4    
1917   196.1    
21340 195.0    
25788 194.1    
26237 191.6    
20405 190.9    
8211   190.7    
20357 190.7    
1296   188.3    
21385 188.2    
11966 186.9    
32629 186.3    
15228 186.1    
21393 179.2    
21459 178.8    
20344 175.6    
8226   175.2    
20008 174.9    
163   174.2    
21428 172.7    
20361 170.8    
20343 170.4    
18030 166.6    
79     165.9    
20339 163.7    
23425 163.0    
21380 162.4    
20436 161.9    
21584 161.5    
20418 160.8    
21345 160.1    
25740 158.1    
20417 157.4    
20351 157.3    
21581 156.5    
21443 155.1    
1916   155.1    
20308 155.0    
28742 154.3    
16588 154.0    
21447 150.8    
20427 150.4    
23426 148.7    
22950 147.5    
13082 146.9    
21441 146.5    
21332 146.5    
15331 146.3    
20390 145.0    
155290 144.8    
1389   143.5    
149098 141.0    
20310 140.0    
20356 137.2    
70718 135.9    
21423 134.5    
70665 133.2    
20304 132.8    
15818 132.8    
21369 132.2    
20333 132.0    
20376 129.3    
20188 128.7    
17149 127.9    
21325 127.5    
20438 126.2    
20421 124.4    
22018 123.0    
32527 122.1    
25132 122.0    
15222 121.8    
69515 121.4    
20203 121.3    
76594 121.2    
26275 121.0    
20191 120.9    
26236 120.6    
105909 120.5    
25889 120.3    
28702 120.2    
23421 120.1    
156113 119.6    
154185 119.4    
19951 117.8    
20411 116.4    
21586 116.2    
21360 115.9    
16590 115.6    
24419 115.4    
16565 115.3    
20359 115.3    
26843 114.6    
24956 114.4    
163966 114.0    
21323 113.4    
26873 113.2    
24415 112.8    
24494 112.7    
21422 112.5    
23430 112.3    
207497 112.2    
26249 112.1    
26201 112.0    
26190 111.6    
87107 111.2    
175720 110.5    
26212 110.1    
20327 109.6    
21451 109.5    
18253 109.4    
28731 108.2    
21334 108.0    
26104 107.5    
8223   107.0    
205771 106.5    
22158 106.3    
21461 106.2    
32632 105.9    
13892 105.7    
21433 105.7    
25130 105.5    
206669 105.4    
28697 105.3    
152996 104.7    
204798 104.4    
20347 104.3    
18265 104.3    
25033 104.3    
20334 104.2    
20381 103.8    
21408 103.5    
28771 103.5    
8227   103.1    
26260 102.9    
21597 102.3    
154346 102.2    
28749 102.1    
19977 102.0    
25117 101.9    
24263 101.8    
21373 101.5    
26126 101.3    
15230 101.0    
25147 100.2    
26251 100.1  

The source is actually BBC:
http://www.bbc.co.uk/news/business-22366064

The side panel says it's the #5 most watched.

If you have never done graphical interface programming before, start with making a gui like this first:

This could mean that you aren't connected to enough other nodes to obtain consensus about what the current best block is.

I can see by the "bars" icon that you have a limited number of node connections. This is expected if you are directly connecting to another one of your own computers using the --connect option. If you are connecting to the public network, you should forward port 8333 in your Internet router to the machine running Bitcoin, or enable the option "Map port using UPnP" in Bitcoin to attempt this automatically.

See the content at http://we.lovebitco.in/how-bitcoin-works/ which answers your questions with as economical a use of words as possible.

I developed that to go up at http://bitcoin.org/en/how-it-works, before the site was launched.


From the apparently one person put in editorial control:

I counter: pick a random 10th year class of students, tell them there's a new Internet money, and split the class, so half gets to read one version, and the rest read the other. Collectively ask if the money seems trust-able or reliable, and if they think they understand it. Observe the results.

Or: see how many forum noobs (and journalists) could have had their questions answered on the first Internet destination for Bitcoin.

User statistics for: zebedee
Most Popular Boards By Activity: Electrum

You don't use the full blockchain, you aren't supporting the infrastructure of the Bitcoin network, therefore you do not stand on solid ground when putting forth an argument.

This "Volume/Open Int. Multiplier" setting refers to the amount of BTC per trade (which you see when you do a volume study), not the price. It should be set to 0.01 to match the default SierraChartFeed precision of "2".

SierraChart doesn't support fractions of a trade volume like a currency would have, it apparently was designed for stocks, where the minimum trade volume is 1 stock. The Sierrachartfeed solution to this is to take trade amounts and multiply them, adding "precision" decimal places (the option at the command line), so a trade of 50.01 BTC becomes a volume of 5001 sierrachart units. Unless you you want to analyze volume with super-accuracy, this setting is adequate. The maximum display divisor in SierraChart is 0.0001 (precision 4).


edit: the raw data does have eight decimal places of accuracy (1 satoshi), see volume amounts of these trades:

bitcoincharts csv:
1367391587,133.500000000000,0.596380140000

mtgox market api json:
"vol":
{"value":"100624.73892887","value_int":"10062473892887","display":"100,624.74\u00a0BTC","display_short":"100,624.74\u00a0BTC","currency":"BTC"}

The only way to use this many decimal points in SierraChart is to set the precision option to -p8, erase all SCID data and get data again, and deal with the volumes in SierraCharts being in billions of satoshis.

Announce: Sierrachartfeed w UTC time data, improved network

Update 018:
-All times in UTC instead of local time (allows easy data file interchange with other users and comparison with other ticker sources),
  REQUIRED: remove all existing C:\SierraChart\data\*.scid files before using this new bridge version.

-properly close IP sockets (not a fix for all 502 errors, apparently)

-faster update,

-remove about 1-5MB of redundant downloading at initialization,

-cosmetic tweaks: error stats and download times on console.

note: when using the single-letter option, there is no space between the option and the parameter


Download links:
(see later post for newest version)

SCID full history files:
from first trade 2010-07-17 23:09:17, to 2013-05-26 23:59:59 (UTC, tick accurate, precision 2):
(extract to C:\SierraChart\data\ before starting SierraChart)

http://we.lovebitco.in/schart/mtgoxUSD.scid.UTC.7z (18.2MB/182MB)
http://we.lovebitco.in/schart/otherALL.scid.UTC.7z (8.2MB/86.4MB)


Original Instructions:


Optimal settings in SierraChart:

My signature address works! Although a diff/patch gives 67 chunks of procedural spaghetti code changes against git master, I've done far less work than original creator slush, and you might also thank bitcoincharts.com for providing the feed, and let them know why you donated.