Bitcoin Forum
May 04, 2016, 01:42:46 PM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 ... 165 »
1061  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: May 03, 2013, 05:03:35 AM

SCID full history files:
from first trade 07/17/2010 23:09:17, to 04/30/2013 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)
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.
1062  Economy / Service Discussion / Re: CoinLab suing MtGox for $75 milliion? on: May 03, 2013, 03:01:19 AM
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.
1063  Bitcoin / Development & Technical Discussion / Re: 234078 Longest block to solve yet? on: May 03, 2013, 02:20:43 AM
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.
1064  Bitcoin / Development & Technical Discussion / Re: 234078 Longest block to solve yet? on: May 02, 2013, 09:39:25 PM
My stats are a little rusty, but as far as I see, it doesn't, it goes up.

Hashing is Bernoulli trial, either you beat the target or you don't. That gives mining a geometric distribution, and so the variance (in number of hashes required) is (1-p)/p2. The re-targeting algorithm tries to keep the hashrate directly proportional to 1/p, so the variance in time quadratically increases with the hashrate. Right?

I guess the phenomenon above was a much higher variance in hashrate because of people turning their computers off at night, whereas now the variance is greatly reduced due to increased numbers and because miners tend to keep the gear running 24/7.

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 p2.

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.
1065  Bitcoin / Development & Technical Discussion / Re: DNS and wallet addresses on: May 02, 2013, 02:22:05 AM
much harder to forge:

http://explorer.dot-bit.org/n/74491
1066  Bitcoin / Development & Technical Discussion / Re: why not measure difficulty in bits? on: May 02, 2013, 01:39:04 AM
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.
1067  Bitcoin / Development & Technical Discussion / Re: 234078 Longest block to solve yet? on: May 02, 2013, 12:36:21 AM
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  
1068  Bitcoin / Press / Re: 2013-05-01 Nasdaq.com - Unravelling the Mysteries of Bitcoin [VIDEO] on: May 01, 2013, 03:55:35 PM
http://www.nasdaq.com/video/unravelling-the-mysteries-of-bitcoin-517763955

For some stupid reason Nasdaq is geo-fencing this (UK - down). Please can someone post a summary (or a rip).

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

The side panel says it's the #5 most watched.
1069  Bitcoin / Development & Technical Discussion / Re: Editing the Bitcoin-QT UI on: May 01, 2013, 03:50:16 PM
If you have never done graphical interface programming before, start with making a gui like this first:
1070  Bitcoin / Technical Support / Re: Progress bar gone? on: May 01, 2013, 02:08:20 PM
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.
1071  Bitcoin / Technical Support / Re: Old blk0001.dat, 2, 3 left over from v0.7.? on: May 01, 2013, 02:02:53 PM
You can remove blk0001.dat, blk0002.dat, blk0003.dat and blkindex.dat from the root data directory after a reindex is complete and you are caught up with the blockchain (and you don't plan on going back to an older version). Only blkindex should actually be using disk space, as the old BLK000x data are moved upon upgrade, and the blk000x.dat files you see there are hardlinks (shortcuts) on any filesystem that supports hardlinking.
The new database for v0.8.0+ is stored in two subdirectories, "blocks" (block data, with block id database in "blocks/index"), and "chainstate" (unspent output database). Do not mess with files in these subdirectories.
1072  Bitcoin / Development & Technical Discussion / Re: What ownership proof does Bitcoin client send to network when spending coins? on: May 01, 2013, 05:50:09 AM
There has been something that doesn't make sense to me....

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:
Nice work. Though I think we can't make this the default starting point. This is a known rule when creating website : if we fail to explain things to the user within a few seconds, then we just lose these visitors. Period. (etc)

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.
1073  Bitcoin / Mining / Re: Soft block size limit reached, action required by YOU on: May 01, 2013, 01:46:15 AM
They are scaling the transactions over sustainable levels paying a fee that doesn't make mining worth it on its own, and forcing to grow the block size if we want to continue allowing free transactions.

Call that whatever you want, that's basically playing the social engineering card.

Simple fact is, if you allow them to pay such low fees, they are growing over what BTC can currently support.
You're saying the miners are including SD transactions and accepting them because the fee they're paying is too low and is killing those same miners?  Huh?

You guys justifying a block size limit, or even believing it solves a problem, never cease to amaze me with the supporting "logic".
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.
1074  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: April 30, 2013, 11:28:04 PM
Quote
Go into Menu -> Tools -> Chart Settings. Go to "Advanced Settings 2" tab and change "Volume/Open Int. Multiplier" to "0.01". Press Apply
i used to have 0,0001 for 4 digit precision
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.
1075  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: April 30, 2013, 10:30:01 PM
Right now I'm working through fixing the first obstacle I found... - putting all times in UTC/GMT.

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.

Code:
Usage: sierrachartfeed.py [options]

Options:
  -h, --help            show this help message and exit
  -d DATADIR, --datadir=DATADIR
                        Data directory of SierraChart software
  -y, --disable-history
                        Disable downloads from bitcoincharts.com
  -p PRECISION, --volume-precision=PRECISION
                        Change decimal precision for market volume.
  -s SYMBOLS, --symbols=SYMBOLS
                        Charts to watch, comma separated. Use * for streaming
                        all markets.
  -l HISTORY, --history=HISTORY
                        Number of days of history to retrieve (default = 7).
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:
How to start
  • 1. Download and install SierraChart software (use default settings and data directory)
  • 2. Download SierraChart feed for bitcoin markets.
  • 3. Start feed in a console. No parameters required list of all parameters: sierrachartfeed.exe --help
  • 4. Start SierraChart software
  • 5. Go to File->New/Open Intraday Chart and select (for example) mtgoxUSD.scid
  • 6. Customize your view using F5 (chart settings) and F6 (analysis/studies) menus
  • 7. Enjoy real time charting!


Optimal settings in SierraChart:
Set price ticks correctly per exchange:
Go into Menu -> Tools -> Chart Settings. Pick "Edit Global Symbol Settings". Choose Service "SC Historical Data", and press New. Then edit on the "General" Tab:
-Symbol: mtgoxUSD
-Price Display Format: .00001
-Tick Size: 0.0000100
-Currency Value Per Tick: 0.0000100

Now in Menu -> Tools -> Chart Settings, "Price Display Format" and "Tick Size" is auto set to  ".00001"

Fix volume display until next SierraChart Launch:
Go into Menu -> Tools -> Chart Settings. Go to "Advanced Settings 2" tab and change "Volume/Open Int. Multiplier" to "0.01". Press Apply

See volume:
Menu -> Analysis -> Studies. select "Volume" and press "Add>>", and OK.

Bar analysis
Go into Menu -> Tools -> Chart Settings.
Set Bar Period to "Number Of Ticks", "Range Of Ticks", set the number, and do whatever analysis you want.

Is there any particular address you'd like me to send some donations to (I assume the one in your signature is fine)?
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.
1076  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: April 29, 2013, 01:41:10 PM

What do you think about p2p rt datafeed solution? Is it possible or not?

Right now I'm working through fixing the first obstacle I found in trying to produce shareable data (such as importable txt files or other people's SCID files) - putting all times in UTC/GMT. The bridge has a design problem, it converts all times to local times, which is wrong according to SierraChart docs, and it even messes up the data during the switch to daylight savings time or moving the computer between timezones, so basically all of you have somewhat erroneous history. The data should be UTC, and import/export should also be in UTC.

Fixing this will mean a new program version, and users must wipe all SCIDs and old history before using it. Since API is so slow, I'll probably include a feature to get the full csv history direct-download daily-generated files when appropriate and/or might throw up my own importable files you can use before starting bridge.

Peer to peer is not an awesome idea, bad peers could feed you bogus info or exploit your open port.
1077  Bitcoin / Technical Support / Re: Running programs written in Python on: April 29, 2013, 10:44:21 AM
Man none of this stuff is working for me, I installed python33 and it keeps giving me errors. Can someone ELI5 how to pull data from btc-e. Willing to tip for your efforts.

I didn't link to python 3.3 above, so "none of this stuff is working" would not be stuff I posted. Most python programming is still done on 2.7, because libraries for 3+ are limited.
1078  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: April 29, 2013, 09:39:33 AM
For some reason, this "fix" fails to download anything past the last week or so of trade data.  Is there any way to download data farther back?  My mtgoxUSD.scid file is missing historical trade data from April 19, 20, 21, and 22 Sad

Code:
Usage: sierrachartfeed.py [options]
...

  -l HISTORY, --history=HISTORY
                        Number of days of history to retrieve (**default=7**).


Update 017: refine rate adaptation, enforce max history when catching up scid, give a user-agent

Because of how poor the API has performed, with about 10% gateway errors and noticeable random long requests (and the fact that we are already abusing the "one API request per 15 minute"), I put in enforcement of the number of days downloaded when catching up an old SCID also, so that if you haven't used the program for six months or if your SCID ends with 2011 data from previous fail versions, it doesn't go crazy and hammer the server, unless you specifically tell it to get more history at the command line.

If you have already created an SCID with a gap, the program can't go back and fill it in, as data is expected chronologically.

Besides the method two posts above to remove data after a gap (my version of Sierrachart doesn't have that exact option), from the edit menu you can also "export and edit to txt", cut lines off the end, and then "import and load".

The file format is 54 bytes of header + 40 bytes per record, so you can also use a utility like GNU split to experimentally cut off extra new data from the tail of the SCID file if you have received bad data at the end, from the original version failing, or from not seeing my change.
1079  Bitcoin / Technical Support / Re: Address and transaction confusion on: April 28, 2013, 02:02:40 PM
The first alert is "bought private keys". What? Some things like paper wallets or casascius coins have their value stored in a single private key, but you should not be "buying" them as standard practice - people should send payments to your wallet.

I will document the behavior of Bitcoin-qt, which is what you should get accustomed to using if you have more than a passing interest in Bitcoin.

If you want a payment to seem to be coming from one address, you will want to first import those private keys into your wallet, and then send the entire balance of your wallet to a new address of yours that you create in "receive coins". Then the next payment that you send will appear to come from that new address.
1080  Bitcoin / Bitcoin Discussion / Re: Aged Coins and Fee free after 3 days? on: April 28, 2013, 06:05:58 AM
The age of the coins and the amount you are sending will determine whether you can send for free. Sending without the minimum fee when it is required will cause you headaches later, and the Bitcoin client won't let you do it.

First, recognize that a transaction is made of:
- inputs - the funding source(s), the individual payments you previously received, and
- outputs - the amount(s) you are sending to different addresses. Typically only one or two outputs, but you can send to many people in one transaction if you want.

The baseline calculation for "when it becomes free" is 1 BTC after one day. If the input of your transaction is a single 1 BTC payment you received over a day ago (144 confirmations), then Bitcoin-qt won't require a fee, even if you are only sending .1 BTC to someone else (the other .9 is also sent, but it's sent back to your wallet as another output). Likewise, if your balance is from a single 0.1 BTC, a transaction using that payment would be free to send after 10 days of confirmations.

The above examples are when your transaction is made of one input. Often a transaction will be made of many smaller previous payments to you, put together by Bitcoin in whatever way it calculates will minimize the change that needs to be sent back to you. Therefore, it can be harder to know if you will need a fee without actually attempting to send the transaction. No "warning, requires a fee" message? That means a fee was not required, and only your optional fee (if set above 0) will be included.

If any output of your transaction is less than 0.01 BTC, a minimum fee is required regardless, to keep people from cheaply spamming the blockchain by sending the same money over and over.


A transaction sending 0.4 BTC with 100 confirmations is not high enough priority to send with no fee.

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

((0.4 * 100,000,000) * 100) / 258 = 15,503,875

Transactions need to have a priority above 57,600,000 to avoid the enforced limit. I would recommend ANY payment include a fee even if it would qualify to be free, as "free transaction" space in blocks is limited, and profit-motivated miners have no incentive to include free transactions over those with fees.
Pages: « 1 ... 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 [54] 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 ... 165 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!