Some things to consider:
Transaction fees would also go to the pool, right?
How about the "I find a solution but don't post it" attack, aka. "withholding winning shares"? As miners might have to be adapted for this pooling scheme anyways, please also implement "oblivious shares"!
Can the pool require it's miners to always include some special transactions (for free), like payouts?
Topic: Think I just solved the pool problem. - page 2. (Read 19141 times)
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy.I think she works for Google, and is planning on working on this project during her 20% time.
http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872
Quote
(1) Relate at the time of conception or reduction to practice of
the invention to the employer's business, or actual or demonstrably
anticipated research or development of the employer; or
the invention to the employer's business, or actual or demonstrably
anticipated research or development of the employer; or
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy.I think she works for Google, and is planning on working on this project during her 20% time.
First comment and a new user to bitcoins.. I'm very intrigued by this pool solution, hope it gets solved eventually.
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy.
I wish I had the skills to do this, myself.
Just curious, but do you mind sharing who your employer is?
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy.Just curious, but do you mind sharing who your employer is?
Any progress on this? Seems to be one of the most important outstanding issues.
I am waiting for permission from my employer before I proceed. Nearly have it, but bureaucracy bureaucracy. Any progress on this? Seems to be one of the most important outstanding issues.
I've got other stuff on the works right now, but if by the time I've got some time no one has implemented it, I'll give it a try.
Any progress on this? Seems to be one of the most important outstanding issues.
2. no more pools being able to decide what transactions to include or not (see eligius and its policy of charging fees for all tx), or to try to create blockchain forks for double spending if they get too powerful (this hasn't happened yet, but it /could/, theoretically.)
Why they can't now?
It sadly is going to be necessary to modify the bitcoin client to return enough of the block under construction - right now, there is no way for a pool to verify that the pool's payment address is being specified unless the necessary information from the block is provided rather than just midpoint hash, etc.
Proposal: https://docs.google.com/document/d/1ciKH3M8WYS49ywz08beXtvpCm2wVGdzU7waKwcn_uaU/edit?hl=en_US&authkey=CJTqyOMF#
Proposal: https://docs.google.com/document/d/1ciKH3M8WYS49ywz08beXtvpCm2wVGdzU7waKwcn_uaU/edit?hl=en_US&authkey=CJTqyOMF#
the whole point of this is to allow TX selection (and headers to an extent) by individual miners.
I thought you were referring to the 50BTC reward.
The independent class makes the transaction list upload to the pool simpler since you have dedicated code to maintain and access this information. Naturally the pool needs to know which transactions the users have included in their block in order to verify the hash. The TX ID communication thing will work fine for this. The pool needs extra memory to maintain this transaction list, but it can be reduced to a certain extent:
1) only maintaining TX per ID, and per non included TX.
2) the class can send a "worker" group ID to the pool to put all the workers running from the same COM object (same machine or even same IP if you link your miners to one IP within your own LAN) under the same list in order to maintain a single TX list per machine and/or IP.
Lastly using IDs ensures the TX have been broadcasted to the network before hand. No shady business that way.
1) The pool posts an address to be used for generation. This could be on the website, or through RPC.
2) A node takes that address, and forms a block using it as the generation address.
3) The miner gets that work from the local node and starts working.
4) The miner gets a candidate, and sends it to the local node, plus another copy to the pool server.
5) The pool verifies that the generation address is the one published, and assigns credit to the miner.
6) When the block is found, it goes out through the local node as usual, and the pool notices it, and pays the miners.
2) A node takes that address, and forms a block using it as the generation address.
3) The miner gets that work from the local node and starts working.
4) The miner gets a candidate, and sends it to the local node, plus another copy to the pool server.
5) The pool verifies that the generation address is the one published, and assigns credit to the miner.
6) When the block is found, it goes out through the local node as usual, and the pool notices it, and pays the miners.
Here are the things that need to be done to get this idea working in the real world:
1) The standard client must be modified to accept an address for the generation transaction.
2) Mining clients (and/or the flex proxy) must be modified to send another copy of each found block (share) to a second server.
3) New pool software (or a mod of an existing pool) to accept these block copies.
1) The standard client must be modified to accept an address for the generation transaction.
2) Mining clients (and/or the flex proxy) must be modified to send another copy of each found block (share) to a second server.
3) New pool software (or a mod of an existing pool) to accept these block copies.
But currently there is no way to tell bitcoind to give you work of a specific difficulty and for a specific public key.
This is why it would be better to come up with a class independent of bitcoind, that will create the block header and provide the work on its own. This prevents modifications to the core elements while it allows to:
1) Skip bitcoind entirely for pool miners as it is done right now. Keeping things simple is always a plus. It also ensures miners aren't nodes in the network, as it is now.
2) Simply have the miners getwork() from that class, let's say as a COM object. Then as said before, the class can determine pool version and outright bypass its main functions if it is dealing with a classic pool, or provide the work as a modded pool would need it to. This allows miner developers to easily implement the change, while keeping it independent from further improvement related to pure number crunching.
then who collects the transactions?
The pool, who else? The header is created with the pool's address.
the whole point of this is to allow TX selection (and headers to an extent) by individual miners.
But currently there is no way to tell bitcoind to give you work of a specific difficulty and for a specific public key.
This is why it would be better to come up with a class independent of bitcoind, that will create the block header and provide the work on its own. This prevents modifications to the core elements while it allows to:
1) Skip bitcoind entirely for pool miners as it is done right now. Keeping things simple is always a plus. It also ensures miners aren't nodes in the network, as it is now.
2) Simply have the miners getwork() from that class, let's say as a COM object. Then as said before, the class can determine pool version and outright bypass its main functions if it is dealing with a classic pool, or provide the work as a modded pool would need it to. This allows miner developers to easily implement the change, while keeping it independent from further improvement related to pure number crunching.
then who collects the transactions?
The pool, who else? The header is created with the pool's address.
But currently there is no way to tell bitcoind to give you work of a specific difficulty and for a specific public key.
This is why it would be better to come up with a class independent of bitcoind, that will create the block header and provide the work on its own. This prevents modifications to the core elements while it allows to:
1) Skip bitcoind entirely for pool miners as it is done right now. Keeping things simple is always a plus. It also ensures miners aren't nodes in the network, as it is now.
2) Simply have the miners getwork() from that class, let's say as a COM object. Then as said before, the class can determine pool version and outright bypass its main functions if it is dealing with a classic pool, or provide the work as a modded pool would need it to. This allows miner developers to easily implement the change, while keeping it independent from further improvement related to pure number crunching.
then who collects the transactions?
But currently there is no way to tell bitcoind to give you work of a specific difficulty and for a specific public key.
This is why it would be better to come up with a class independent of bitcoind, that will create the block header and provide the work on its own. This prevents modifications to the core elements while it allows to:
1) Skip bitcoind entirely for pool miners as it is done right now. Keeping things simple is always a plus. It also ensures miners aren't nodes in the network, as it is now.
2) Simply have the miners getwork() from that class, let's say as a COM object. Then as said before, the class can determine pool version and outright bypass its main functions if it is dealing with a classic pool, or provide the work as a modded pool would need it to. This allows miner developers to easily implement the change, while keeping it independent from further improvement related to pure number crunching.
But currently there is no way to tell bitcoind to give you work of a specific difficulty and for a specific public key.
You still need a way to get work at a specific difficulty and for a specific public key
You'd be feeding that work to yourself. The public key and difficulty are broadcasted by the pool.
Jump to: