Topic: [SUGGESTION] "Reseller" Bitcoin Pools? (Read 1072 times)

It could be useful for pools to be able to pick and choose what to mine aka where to get work from, and to be able to abstract the work they are actually doing from the rewards they pay to client miners.

I am thinking of mining as a kind of spot market, or at least a market. Anyone might come up with a new blockchain they would like to have some hashing (mining) power applied to, but miners might have no interest in whatever application or commodity/currency the new blockchain implements or is used for.

So it could be nice if miners could basically just straight out sell their hashing power, and blockchain operators could buy that hashing power.

One of the effects would hopefully be more-efficient marketing of hashing power, another effect hopefully would be relieving individual miners of some of the complexities of arbitrage. At the least it should help make it easier for the hard parts of arbitrage to be quite mobile in the sense that responsibility for doing arbitrage could be shared or could be focussed at different points.

By focussed at different points I mean use cases such as a professional miner pooling a number of mining rigs via an in-house arbitraging pool system that finds them the best price per megahash based on the currency/commodity in which they wish to be paid for their megahashes or a pool that basically serves as a way of outsourcing that functionality.

I have seen various works in progress for use by miners to try to make sure all their rigs are getting work, falling back to different pools / sources-of-work and so on; I am thinking that pools themselves could also do something similar but what they would be picking and choosing among would be various blockchains offering various rewards for doing work.

Spot markets for hashing/mining could of course serve an attacker who wishes to buy up enough hashing power to perform some particular attack against some particular blockchain, but they should also be able to serve defenders who wish to quickly round up enough power to fend off an attack.

Maybe "responsible" providers, market-makers or market-operators would arrange with various blockchain operators some means of guessing whether a proposed purchase of power seems to threaten to be an attack or seems to possibly be a rallying of defense, but maybe that simply is not possible due to attack and defense being rather relative terms? (Is it an attacker defending their attack from a defender or a defener atttacking an attacker's dubious fork of a blockchain?)

-MarkM-

You're both right. A simple clan cannot do this easily, if at all.
But at the same time, if you had a service hosting multiple "clan pools" but in reality having a single master pool, then having the separate outlets gives more competition to services and perks while sharing a single goal and bitcoin pool.
If this works the way I envision it, there's little chance of failure.

If I had the code to do this, I could literally have it up within around a week to maybe as much as a month.
I'm currently working on a server for a bitcoin pool with a friend and old co-worker. If I get what I need to run this, it'll basically be a single bitcoin pool with the ability for "pool operators" to bear the face of a community while assisting us in our goal and doing all marketing and scripting for us. Basically, we get our service out and the "consumer" is the presumed "pool operator" while we get the traffic and take a small margin off the profits. Perhaps I'll write out the entire specs of how the envisioned system will work and it'll make more sense? 

This is where Clancoin enters the picture...

-MarkM- (How many Martian Botcoins would you charge to host a Martian Botcoin pool? )

You're forgetting the amount of hash power currently needed to solve a block in reasonable time...
We're at ~400Gh currently, and the long blocks still takes about 6-12h to solve...

That's nothing a "little" clan could be possible to put together...

Assuming both the service host and the pool host only give 1%, this could be beneficial for local pools, clan pools, etc...
I would join the pool myself if I could either have one for my bitcoin friends or just one to manage in general.
2% isn't a large amount and even if it was shrunk smaller, it would still be a nice idea to attempt.
With proper APIs, server information and the etcetera, someone could easily improve and customize a website for their pool and keep the pool healthy and busy.
You just gotta have enough smarts to do it, hehe...

In fact, the project could go as a large pool with separate "outlets" in which users join.
That means Pool Site A has 352 users, Pool Site B has 128 users, Pool Site C has 412 users, but the service host's pool as a total of 892 users. (A + B +C)
This could benefit both the pool operators and the service operator, and it will well over-run regular pools because some people are zealots for administrators of things like pools. I, for one, am a zealot of a leader. 

So you'd like to pay 2% to 4% to participate in a pool?

Why would you pay it to one of these pools that you propose rather than to some already existing pool that already charges 2 to 4 percent?

-MarkM-

Okay, so I just hatched an idea that I think might be good...
It would require one or more VPS' and has potential to definitely draw a crowd.
"Reseller" Bitcoin Pools.
Basically a main site runs the VPS' and offers a service for others to start a Bitcoin pool of their own through the service. That service might charge 1-2% per client per pool but in return that's actually a lot with multiple pools.
The pool operators could then charge another 1-2% on top of that for the service and they'd make money and thus incentive to run and advertise their pool.
Lemme know what you guys think, and if someone plans on making this... I call first dibs, I'm an old beta tester with some good experience and would love to start me up a pool.

Okay, have fun sharing your thoughts and opinions!

EDIT:
In fact, the project could go as a large pool with separate "outlets" in which users join.
That means Pool Site A has 352 users, Pool Site B has 128 users, Pool Site C has 412 users, but the service host's pool as a total of 892 users. (A + B +C)
This could benefit both the pool operators and the service operator, and it will well over-run regular pools because some people are zealots for administrators of things like pools. I, for one, am a zealot of a leader.