Bitcoin Forum
May 04, 2024, 12:26:09 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 »
1  Economy / Economics / Re: Paul Krugman comments on bitcoin. Fantastic blog! on: September 08, 2011, 10:54:22 PM
That blog entry only says "Deflation leads to Money Hoarding", in slightly more sentences. A topic that has been discussed over and over again in this forum for months and years.
2  Economy / Speculation / Re: Here we go again, bitcoin exchange rates have been doing just fine on: September 05, 2011, 02:36:32 AM
Log scale and long averages, pf....
3  Bitcoin / Bitcoin Discussion / Re: Live mobile bitcoin conference stream. on: August 19, 2011, 06:04:46 PM
Is it the one room only?
4  Bitcoin / Bitcoin Discussion / Re: Rate My Bitcoin Rig on: August 19, 2011, 05:58:10 PM
And get rid of the porn. Geeeeezzz.
5  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 07:15:51 PM
Quote from: joulesbeef on August 15, 2011, 06:53:14 PM
Quote
Can anyone hint me on why I am submitting shares to btlc, but not deepbit and polmine (all with mine_deepbit)?

that is what a lot of the discussion above is about. C00w is working on new methods to hop unhoppable pools. It works great for some, no so great for others. The debate above is about improving the methods. Obviously this is difficult as these pools were set up to not be hoppable. Most likely you have a worse connection to deepbit than you do for bclc. If you become concerned it is harming your rewards, then just disable the mine_deepbit pools, until the guys get the bugs worked out on the method.

Oh. I thought deepbit was working for everyone already. Especially with the IRC.
6  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 06:39:48 PM
Can anyone hint me on why I am submitting shares to btlc, but not deepbit and polmine (all with mine_deepbit)?
7  Bitcoin / Bitcoin Discussion / Re: MtGox is down, but people are still making trades? on: August 15, 2011, 03:52:54 PM
It's up for me, but down for others:

http://www.downforeveryoneorjustme.com/mtgox.com
8  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 03:01:58 PM
Quote from: ryouiki on August 15, 2011, 01:42:30 PM
My simulator uses randomly generated round shares that are generated with simple algorithm mimics block finding procedure. (poisson process) To get statistically meaningful result, I used high quallity Mersenne Twister as a base pseudo-random generator.

pseudo code:
Code:
var sparseness = RAND_MAX / BTC_DIFFICULTY;
var roundShare = 0
while (true)
{
    ++roundShare;
    if (MTrand() < sparseness) break;
}
return roundShare;

table of generated 120k round shares : http://cl.ly/8wg3

I plotted your sample:



and a sample I produced:



Please excuse the missing labels. x-axis is number of shares (in percentage of difficulty), y-axis is number of occurances (summing over windows of 10000 shares).

The results differ slightly, most significantly at around 0.
9  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 02:51:15 PM
Btw, I got the latest c00w last night and have been mining with it since. Still no share at deepbit:



?
10  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 01:39:28 PM
Quote from: organofcorti on August 15, 2011, 06:47:47 AM
You can't use anything that will provide a uniform random distribution. It has to be at least a binomially distributed random, and at best a time-distributed fractional poisson distribution.

I'm using the built in poisson distribution randomiser built into R with some jiggery pokery to make it a poisson time-distributed random(really share based) instead of the standard poisson distribution http://stat.ethz.ch/R-manual/R-patched/library/stats/html/Poisson.html. Ryouiki has a bespoke poisson randomiser built on mersenne twister as a random seeder.

The described method does not result in uniformly distributed pool shares.

Also in case you missed it, Meni replied to you here.
11  Bitcoin / Pools / Re: Pool share probability simulation on: August 15, 2011, 01:28:27 PM
Quote from: Meni Rosenfeld on August 15, 2011, 07:33:58 AM
The motivation of your post - the fact that fallback is not necessary with many proportional pools - is not new. I've said this already here (Table B.1) and before that.

The reason it's unnecessary because when there are many pools, you never get to 43.5% - there will virtually always be a pool with less than that. So you don't need any of the "random threshold selection from the range [0.5, 1.5]" nonsense.

I had only seen organofcorti's simulation and had not seen your (unfinished) paper before. I knew there was a mathematical derivation. I am just better at programming than at probability theory.

In my simulation too, there is little to no time spent at the backup pool when hopping multiple pools. For six pools however I found that there is still some time spent at pools being at > 0.43 (see this post).
12  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 02:16:25 AM
Quote from: deepceleron on August 15, 2011, 01:53:55 AM
Quote from: bb on August 15, 2011, 01:19:09 AM
Quote from: deepceleron on August 14, 2011, 08:02:41 PM
I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned.

No. I am using Meni's formula.

One situation this does not address is the bit-hopping effect itself. If 100ghash hops on and off 100ghash pools, the early shares will be go by twice as fast, meaning there will be less cheating time than predicted. All pools will spend more time in the > .43 difficulty range; lowering the chance of there being a pool to hop to with share earnings higher than backup.

This should just shift pools (and speeds) around a bit, but doesn't change the outcome.
13  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 15, 2011, 01:19:09 AM
Quote from: deepceleron on August 14, 2011, 08:02:41 PM
I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned.

No. I am using Meni's formula.

Quote from: deepceleron on August 14, 2011, 08:02:41 PM
For more interesting real-world factors to model, analysis could be biased with a 'pool hop-in' time delay (like jumping 5 minutes after block find), and a 'wrong pool hop error rate' that reflects what people are seeing with early block-detection methods, when they get incorrect blockfinding because they aren't getting info from the pool that actually found a block, and jump to a false-positive.

I am guessing all these simply reduce efficiency.
14  Bitcoin / Pools / Re: Pool share probability simulation on: August 14, 2011, 09:46:08 PM
Thanks a lot for clearing this up.

I have since used this to do a(nother) pool hopping simulation.
15  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 14, 2011, 09:37:36 PM
Quote from: ahitman on August 14, 2011, 07:16:17 PM
In your simulations can you say how much time the hopper would spend at the PPS pool (or how much time there was spent with no pool being less than 43%)? If the amount of time spent at PPS is a tiny percentage (because of all the available prop pools) then the efficiency would seem to be high but not because you hop away from a pool, but because you are always hopping TO a pool that has low shares.

I ran a simulation at threshold 1.5 using the "real world" parameters.

From a total of 2750 BTC earned, only 0.03 BTC (essentially 0) came from the fair pool. This is basically just the consequence of the probability for all six pools beeing at 1.5 * difficulty being very low.

I ran the simulation again, recording how much time was spent at pools below/above a 0.43 treshold.

below 0.43: ~ 92%
above 0.43: ~ 8%
at fair pool: < 0.1%
16  Bitcoin / Bitcoin Discussion / Re: HELP is there a Paste-down bitcoin button (UK) on: August 14, 2011, 09:18:11 PM
If Mt. Gox doesn't upgrade their server infrastructure soon they are useless for merchants.

"Sorry you can't pay right now, Mt. Gox is lagging."
17  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 14, 2011, 06:27:16 PM
Hop off thresholds revisited

A while ago @organofcorti claimed that our beloved hop off threshold of 43% does not make too much sense when hopping multiple pools.

Unsure about this claim (like so many others) I implemented (a very crude) pool hopping simulator myself and ran some simulations, the results of which I would like to share with you.

All these simulations run one miner at approximately 1 GH/s for about 1 year on what is now called the OldDefaultScheduler, meaning that the miner always jumps to the pool with the least shares. Also, there is a threshold variable (eg. t = 0.43). If there are no pools with less than t * difficulty shares, the miner hops to a fair pool.

The simulation does not use slicing. The pool speeds stay constant.


The standard case: one proportional pool

At first I ran the simulation with one proportional and one fair pool. This is the case @Raulo discussed in his original paper.

The simulated pool was running at about 500 GH/s.

The result shows the expected peak at about 0.43:




Two hoppable pools

Next I added another proportional pool.

The simulated pools were running at about 210 GH/s and 165 GH/s.

You can still see a peak somewhere around 0.40:




Real world simulation

Finally, I ran the simulation with six pools that were hopped at the time I started writing the simulation:

  • polmine, ~ 210 GH/s
  • MtRed, ~ 165 GH/s
  • triple, ~ 110 GH/s
  • ozco, ~ 55 GH/s
  • rfc, ~ 5 GH/s
  • btcmonkey, ~ 2.5 GH/s

In the result the peak is gone and between 0.40 up to at least 1.8 there is no visible drop in efficiency!




Conclusion

The results of my simulations agree with the findings of @organofcorti (and others). When using multiple pools for hopping (which is presently the common case), there is no need for a hop off threshold of 0.43. However, regarding efficiency, there does not seem to be any benefit in using a higher threshold either.

Choosing thresholds randomly when pool hopping makes it impossible for pool operators to identify you as a hopper for hopping off at 0.43. I therefore suggest implementing a random threshold selection from the range [0.5, 1.5] when there are multiple pools being hopped.
18  Bitcoin / Mining / Re: You know when you are bitcoin miner when... on: August 11, 2011, 03:21:08 AM
Quote from: Bert on August 11, 2011, 12:59:40 AM
102. If your miners go down for a day the next block difficulty will be lower.

 Grin Grin Grin Grin Grin Grin Grin Grin
19  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 11, 2011, 01:28:37 AM
Yep, bitclockers is no good right now.
20  Bitcoin / Mining software (miners) / Re: bitHopper: Python Pool Hopper Proxy on: August 10, 2011, 04:17:45 AM
We should try "Just hopping, no DDoS" for a user agent string...
Pages: [1] 2 3 4 5 6 7 8 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!