You're completely ignoring the 13 inbred Terrorist European Bloodlines of the Terrorist organization illuminati. I'm not sure exactly how it works, but it's pretty clear that they've been responsible for every historical incident in the history of history.
Ah, so you are not familiar with how the Elites caused the American Civil War? Well, consider the history of this nation from the very beginning and you will easily see the pattern: Actor_Tom_Truong has made it clear that the 13 inbred Terrorist European Bloodlines of the Terrorist organization illuminati are actually the European Union. So, what I'm not familiar with is how the European Union caused the American Civil War. However, I'm an avid reader of this thread, and am slowly learning. I expect the answer to be something to do with FTL spaceships and timewarping devices. |
|
|
|
The Northern part of America wanted to get rid of slavery, because they believed it was immoral and unfair, while the Southern part of America didn't want to give up their slaves. So arguments were ongoing between the two, resulting in the Civil war, with the North winning, and slavery became illegal. The North and Southern part of America at the time were an opposite direction which caused for civil war.
You're completely ignoring the 13 inbred Terrorist European Bloodlines of the Terrorist organization illuminati. I'm not sure exactly how it works, but it's pretty clear that they've been responsible for every historical incident in the history of history. So please just sit back down, tuck in to some popcorn and let Actor_Tom_Truong get on with what he does best. |
|
|
|
As is noted in the thread, the timestamps are inaccurate. Trying to make timestamps accurate requires the assumption that blocks are generated a particular way - but this is what you're testing, so you can't do that.
I have a source for more accurate "timestamps" (actually the first time a block has been recorded by a well connected monitor), but this doesn't fix the problem.
The problem is that blocks appear wrt to time as a non-homogenous Poisson process rather than a homogenous (usual type) Poisson process. They are only a homogenous Poisson process with respect to hashes.
This is not usually an issue unless considered over many days, but if there are sudden changes in hashrate the block rate will be affected in a significantly non-homogenous way. For example, I've noticed that block durations aren't actually exponentially distributed even if you try to normalise the data to account for the non-homogenous nature of the process. I *think* this has something to do with miner hashrate changes at the start of a block, but it's hard to prove.
I don't doubt that some of what you see is the effect of the generation process being non-homogenous. However, it might be that in the relatively small sample you took which look non-Poisson might actually be ok. You could use R package dgof to do some discrete goodness of fit tests, or you could find the confidence intervals for the histogram bins and see if the bins are either under or overfilled, or within the expected range (if bins are the same size they should have a binomial distribution where p = 1/ number of bins)
Great post. I found that quite interesting. What is your thinking on the hash rate at the "start of a block". Do you mean the "orphaned hash rate" due to miners working on the old headers before learning of a new block? Is it homogenous w.r.t. the hashes? I'm assuming the hash rate is continuously changing? I think yes to both questions, but that's opinion based on old data. It seemed to be the case before stratum, not sure if it's a significant effect now.I hope to get time to look at that again soon. I also had a look at your site. Great work b.t.w. If you don't mind answering here, or is there a thread on your site, but your CI for the forecast appears narrower than the CI of the the hash rate estimate.
Thanks for the kind words  They're about the same, but one is offset wrt the other. It's annoying and I think it's because the forecast method makes assumptions about residuals for the forecast that is not the case. I'm not sure how to fix that. |
|
|
|
Thus eventually the middle class either breaks out and joins the elite, or it gets impoverished. Socialism will make everyone equal, equally poor I mean  Quick point: "Poor" is a term of comparison. If everyone has the same amount of money, they can't be "equally poor", they just all have the same amount of money. You might as well say"equally rich". |
|
|
|
|
As is noted in the thread, the timestamps are inaccurate. Trying to make timestamps accurate requires the assumption that blocks are generated a particular way - but this is what you're testing, so you can't do that.
I have a source for more accurate "timestamps" (actually the first time a block has been recorded by a well connected monitor), but this doesn't fix the problem.
The problem is that blocks appear wrt to time as a non-homogenous Poisson process rather than a homogenous (usual type) Poisson process. They are only a homogenous Poisson process with respect to hashes.
This is not usually an issue unless considered over many days, but if there are sudden changes in hashrate the block rate will be affected in a significantly non-homogenous way. For example, I've noticed that block durations aren't actually exponentially distributed even if you try to normalise the data to account for the non-homogenous nature of the process. I *think* this has something to do with miner hashrate changes at the start of a block, but it's hard to prove.
I don't doubt that some of what you see is the effect of the generation process being non-homogenous. However, it might be that in the relatively small sample you took which look non-Poisson might actually be ok. You could use R package dgof to do some discrete goodness of fit tests, or you could find the confidence intervals for the histogram bins and see if the bins are either under or overfilled, or within the expected range (if bins are the same size they should have a binomial distribution where p = 1/ number of bins)
|
|
|
|
The fact that the description of the pool (advertising) are out of date since 2011 is this normal?
It turns out in this forum, give false information ....
If you let me know which pools are out of date, I'll fix them. No need to be rude about it. |
|
|
|
The fact that the description of the pool (advertising) are out of date since 2011 is this normal?
It turns out in this forum, give false information .... For 4 years a lot could change
I think you'll need to point out which information is wrong. It lists Eclipse. Does it still exist ? Yes. Website and json feeds still work, and blocks they claim (with their coinbase sig and gen address) are uncontested by other sources. |
|
|
|
Is Sha-256 merged mining with UNO only on the BitcoinXT pool? Or is it also merge mined on the standard BTC Pool???
Wrong 'Multipool' thread. This is for the pool hopping 'Multipool' which died in 2011. |
|
|
|
As I understand there are shown only the POOL that say about themselves or about which said users on this forum?  Pools are only listed if the pool op requests it. All information needs to be provided in the request post. |
|
|
|
Bitcoin pool running Bitcoin XT v0.11a.
This list should not only not-add yours, but should probably also remove Slush's and any other pools that have ceased to provide Bitcoin pooled mining. Miasma, Multipool.us is already listed for bitcoin proxy p2pool mining. As for bitcoin xt mining pools, I haven't changed my position on non-bitcoin mining pools - they will need a thread of their own. |
|
|
|
Who is 1DXRoTT67mCbhdHHL1it4J1xsSZHHnFxYR ?
Telco 214I know who they're thought to be, but I don't have any proof yet. |
|
|
|
No it isn't.
His fee is higher and his long term luck is lower ...........
You really have to keep up if you are going to insist on being pig-headed .... there's no fee on slush. i think he is talking about f2pool, or i missed something. There has always been a 2% mining fee on Slush - is that what you're talking about? from https://mining.bitcoin.cz/terms-of-serviceTransaction Fees and Payouts
* Pool fee is 2% (calculated from block reward and transaction fees).
* Fees from bitcoin transactions are paid to miners that use Stratum interface.
* Orphaned (invalid) blocks are not paid. It helps to keep pool fee low.
* Pool is not an e-wallet or a bitcoin bank. We are not responsible for loss of your bitcoins which are stored in the pool account. All your mined coins have to be regularly paid out to your secured wallet.
|
|
|
|
where American Patriot Militia Groups destroy the 13 inbred Terrorist European Bloodlines. |
|
|
|
Who is 1DXRoTT67mCbhdHHL1it4J1xsSZHHnFxYR ?
Not sure yet. |
|
|
|
Please add this pool! Pool: BitClubPool Website: http://www.bitclubpool.comProxy: NO Generation address: 155fzsEBHy9Ri2bMQ8uuuR3tv1YzcDywd4 Coinbase signature: BitClub Network Payout method: PPLNS Fee: 0% Pay Tx Reward: NO Vardiff: Automatic (18 20 SPM) Local Work: Stratum Pay Orphans: NO (We would love to but we can't afford it...) Min Withdrawal: 0.002 BTC (We will try to push out as much Dust Payment as possible but this be the promissed minimum) Merge Mining: No Merged Mining at the moment. *New Pool Promo! $100 USD Bonus given to the Block Finder. To qualify for the Bonus, the found block has to be odd number block. (Example #367439) Super Bonus, if you hit a block right at 7%, $1,000 USD worth of BTC or 1 economy round trip ticket to Iceland for the Mining Farm Tuor stratum mining and it is pool.bitclubpool.com:3333 for US members, us.bitclubpool.com:3333 for EU members, eu.bitclubpool.com:3333 Done. |
|
|
|
where telephone companies destroy telephones
where dentists destroy teeth
where teeth destroy dentists
where faith destroys knowledge.
where clocks destroy time where food destroys health where Bitcoins destroy money where Actor_Tom_Truong destroys reality where handkerchiefs destroy noses where flowers destroy tanks |
|
|
|
|
where telephone companies destroy telephones
where dentists destroy teeth
where teeth destroy dentists
where faith destroys knowledge.
|
|
|
|
|
where grandparents destroy grandchildren
where pad thai destroys tastebuds
where martial artists destroy other martial artists
|
|
|
|
|
This is fun! Here's another one:
where giraffes destroy acacia bushes
|
|
|
|
|
... where freethinkers destroy free thought ...
|
|
|
|
|
Show Posts
