He'd probably be day trading in myrrh futures contracts.

Making realistic data for a dozen pools for each block with valid getwork timestamps is a higher barrier to entry than the current attack, which would be simply sending "Best Guess: {bitclockers} with 1 of 1 votes" over 9000 times. It's open source, so unless you want to only accept signed messages from a public key list of known-good users, there is always an attack.

If you want extreme time logging that is easier to process, replace instances of

print time.strftime("[%H:%M:%S] ")

in bithopper.py with:

print str(time.clock()) + ": "

Then you get:

258.662399982: LP Call http://ozco.in:8332/LP
260.253839675: LP Call http://eu1.triplemining.com:8344/LP
261.29642532: LP Call http://pool.bitclockers.com:8332/LP

or you can save to a log file if the message is "LP Call", etc.

I kinda gave up on it for a while. As you saw from my post like five pages back, I put in the delays to the results I had already gotten and analyzed that. The conclusion was that even after inputting (or auto-learning) and even hand-tuning the average delay for each pool, the current 'first pool wins' method is suboptimal. A better algorithm, that in my limited sample gave no false positives, is to take the average delay of all pools after correction, and then analyze each pool against this average to determine if one stands out above the standard deviation expected if no polled pools were the finding pool. This improves results, since you aren't merely comparing the winning pool against the second-fastest, you are averaging out the LP delay capriciousness of your baseline over 15 pools.

Secondly, I propose a better p2p-IRC result sharing format, where all pool new block LP receive times (and the getwork timestamp) are published raw to IRC by each miner, perhaps after gathering LPs for a 10 second period after the first response. This would be better than the current "I think this pool won" publishing method, as then similar averaging can be done by the bithopper software independently, but with everybody's data, which, if we continue with the premise that the block-finding pool responds faster, should make identification clear.

This also will only last as long as pools don't take countermeasures, such as modifying bitcoind to randomly delay the RPC change to a new block if the local bitcoin found it, or by simply disabling long polling, like slush's pool.

As I would have to learn python, some database libs, and the current codebase before making improvements (and since improving hopping software was labeled as equivalent to "making poison gas for the Nazis" by hoppers themselves), I will leave it to someone else to implement this.

Since he is not claiming that #4 is false like other hoppers, I will just have to concede that this learned poster is too cunning to be understood.

That's not the way Bitcoin statistics work. Either you find a block or you don't - there is no 'work' done that gets you any closer to solving a block. You still have the same 50% chance of finding a block in another 1.88m shares (the difficulty) as you did when you started the round. If the current round was 10 million shares, I'd be predicting a block find at 11.88 million.

That's also why there is no reason for the literate to be mad at any payment scheme a pool has decided on; any reward system for hash submissions to a pool is arbitrary, because the only one that actually did any work is the person who found the block, everyone else did nothing, and gets a reward for just trying. When you solo mine, any hashing you did in the past that doesn't solve a block immediately "decays" and you don't get rewarded for it. Pool payment systems also decay or discard the consideration of old submissions by miners, just less so, whether it be after a block is found, after a certain number of shares or amount of time, or using a formula. For the illiterate - well, they get mad irrationally because they can't accept blaming themselves.

Also, there is no reason to feel guilt shutting down a pool mid round - nobody found a block, so nobody gets paid. That's as simple as it gets.

LOLWUT? Is that the new plan, disinformation, claiming people won't get paid on pools that switched to a hop-proof system? You are acting like your mommy put the candy bar back on the shelf and slapped your hand.

You say "full-time miners have to remember" - that shows we are discussing the interests of full-time miners, not the pool operator, so "pool" defines "miners pooling their resources". This thread's topic also shows we are discussing benefits to bitcoin miners and their concerns; this is not a guide for pool ops to maximize their profits by getting more block solves and fees by green-lighting hopping. The reply sounds revisionist.

Marking valid shares as stale or bad accounting, or not reporting a block find to pool members, are not the the likeliest attack vectors of an unscrupulous pool op. The least transparent (although it will still show over time as lowered luck) is for the pool op to add nonexistant mining shares into the pool rounds, getting paid for mining work not done.

This is untrue. This is like those disseminating anti-global warming or anti-evolution information, there is little doubt in the scientific community, but it serves to create a perception that there is even another side besides the one based on fact-finding.

I will post pretty pictures for those who need it. These were done by forum user (and poclbm-autohop creator) Aexoden (not me, conspiracy theorists), who has run simulations here of different payout systems for full-time miners, on a 200ghash pool vs. a 200ghash pool + 100ghash of hoppers. Blue line is what you make.





(edit: I do see something I don't like in these graphs, rounds longer than 1/2 difficulty should be shorter by a .14 difficulty factor, since we assume the first dif*.43 of a round had 50% more hashrate. If the X coordinate is time (not shares), that should result in a subtle skew to the left. Perhaps I will do my own Mathematica simulation, since I know how to generate an accurate "hashes before blockfind" distribution, but then again I don't care that much..)


(edit again: I guess the expected skew is there, in the "with pool hoppers" example, the pool has solved two more blocks by the end.)

Why, I even asked Google  :

I am squarely on the side that is not full of nonsense!

You are seeing typical pool hopper vitriol here. I responded to such a nonsensical rant here. Lulz abound as they reply with the same rehashed talking points to justify hopping to themselves.

They come up with stupid mistruths they say to each other, like "pool hoppers help pools", "this pool sucked until we added it", "xxx is hopper-friendly and now they don't suck", "nobody was making any money until pool hoppers came along anyway", "we are smarter than other lazy pool miners", "it's not our fault they use an unfair system", "xxx pool is a bunch of unethical jerkoffs for blocking hoppers", or as above "we don't even matter to your pool". Well, it's right there ready to go in the config file of bithopper, all you have to do is put in your credentials and wait for a new block, as clearly some had.

The truth is: whether a proportional pool has a high or low hashrate, it makes the miner exactly the expected amount over time, until pool-hoppers start jumping on and exploiting it, what Raolo aptly titles "pool cheating" in his initial publication of the exploit (one that was quickly apparent to me when I started mining too, and then I searched and found the long-ignored threads and didn't bump the topic.)

Even if a pool was just Vlad mining by himself, that only amplifies the need for counter-measures or an unhoppable payout system. Imagine he just got done mining on a long block, and says to himself, "well, it's just variance, at least I'll make it up on the short rounds". Then a new round comes and a whole shitload of people pile on the pool and it turns out to be a 30 minute round that he hardly had time to submit shares into. Now he doesn't get squat for the short round. Same thing goes on every other pool, the expected mining revenue is reduced directly as a ratio of regular miners to pool hoppers.

That's not a "hell block" at 7.5m shares, unless you have a pittance hashrate on long rounds (the flip side of "hopper friendly"); mineco.in is working on a 10.5m share round right now, and just had a 9.5m too. Eclipse at 7.9m and Eligius at 7.7m are also currently in longer rounds that triple.

It looks like the promise of giving "someone" a video card if 10 blocks were solved in three hours didn't help much, as 0 blocks were solved in 326 hours.

Same problem here on 0.17 binary / Win7 32 bit / 5770 / Catalyst 11.6/2.4 - it just searches without returning an address find, even with something simple like oclvanitygen.exe -d 0 1111. Safe mode does the same thing. 0.16 has the same problem, only it crashes compiling if you don't use safe mode.

The problem with this position is that the shorter address is random happenstance, not the goal or the defined problem. By that position I could say that my generated address 1CoinsLoLBY6o9khnW95MkbW2eEZQaxTRa beats it, by having eight characters that mean something, although that was also randomness and not something that was searched for. Or I could change my forum nick to 6o9, and say it has 13 digits.

If vanitygen had an option for finding only short addresses with a vanity phrase, then it would really be something to find a 25 character address with a word you searched for in it.

Slush's probability graph is full of math fail. Let me re-twat a previous post of mine (note the probability below was from a lower difficulty):


Note that also you cannot directly compute using shares or just multiply shares*difficulty, because the chance of finding a share (a difficulty 1 block solve) is also random with binomial distribution, and what is important is the complete number of individual hash attempts in the full difficulty problem.

The VECTORS command line = VECTORS2 processing, two hashes processed per iteration.
There is no parsing of a "VECTORS2" command line, if you are typing that, then both vectors options are disabled.

    VECTORS = KernelOption(
        'VECTORS', bool, default=False, advanced=True,
        help='Enable vector support in the kernel?')
    VECTORS4 = KernelOption(
        'VECTORS4', bool, default=False, advanced=True,
        help='Enable vector uint4 support in the kernel?')

That is an invalid bitcoin address, it is longer than 34 characters, and includes non-base58 characters "0" and "l"

static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

While functional vanity addresses can be generated, it becomes computationally infeasable to generate more than a seven or eight letter vanity phrase. If you don't care about being able to receive or re-send the bitcoins, a longer valid address can be created without a matching private key with address format "1" + 18-28 valid base 58 characters + checksum.

I am a pool hopper? Find one post where I've said that. Studying lockpicking doesn't make me a thief; studying American history doesn't make me want to own slaves. Bithopper software reveals itself as rather clever and canonical, having other uses, such as the potential to find "who solves the block" from LPs, make an IRC block solve annouce bot, or to spread shares across several pools for backup/failover/variance reduction, etc. I'd post a screen shot with all my pools set to info and backup, but my python install got messed up earlier this week and I haven't bothered fixing it.

However, pool hopping on those pools that have decided it is OK, to the detriment of their other users, would just be defending yourself against others who thought it was cool to bring a gun to a knife fight.

By the way, why would someone be "bitter" if they decided to stop pool hopping? hrm.

I think the reasons are 1. That would take some effort, 2. Math fail (such as the below-mentioned pool op not believing that pool hoppers reduce earnings, and me being unable to communicate with him in the language of integral calculus and binomial statistics, since he's working at a hosting company at the age I was studying engineering), 3. User resistance (typical PPLNS conversion discussion: "I don't like the idea of my shares expiring..."), and 4. Greed - hopping doesn't reduce the earnings of pool ops, just the users, and more block solves = more fees they get to keep.


I am referring to the instability and extra work that hoppers create for pool operators and their users. I happen to know several network problems at bitcoins.lc were from pool hoppers, specifically from hundreds of connections a second being opened by the multipool op and other unknown actors, essentially DDOSing the pool. Jine had to implement firewall caching because of the load the constant stat-refreshing was causing, and had to switch over to to a VM environment with load distribution between six different servers, because proxied and aggregated connections were not re-using TCP sessions properly and would run pushpoold out of TCP/IP ports and crash the pool for all the users. That I might be bitter about, along with having to switch my higher aggression mining tasks to a PPLNS pool instead of my first choice, to avoid earning measurably less.

I do somewhat agree that the game is flawed if you have to kick out the card counters. However, you aren't taking from the house, you are taking from other miners in a situation where the ideal would be that we pool our resources for the good of all. My response is to the self-justifying posts every few pages of this thread that "pools should be glad, we help them solve blocks", or "xxx pool is unscrupulous a-holes because they are taking measures against pool hopping".

And the assigned seating chart can finally be revealed...