Title: Alternative to getwork for miners/proxies Post by: DrHaribo on February 21, 2012, 06:18:36 PM There are some weaknesses in the way mining is done today, with the "getwork" json-rpc call. I'd like to suggest we create a new standard based on what Luke-jr. is working on for Eloipool. There is some code for this here: https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533 (https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533). As you can see it is basically a "getmemorypool" interface but instead of parts to create a generate transaction from, you get complete generate transaction from the server as "coinbasetxn".
I think it would be a good idea to add a "target" like "getwork" has, so that the server can control the difficulty for its clients. Also, perhaps the procedure should have a different name, since it is not the same as the "getmemorypool" of bitcoind? What does this solve, compared to plain getwork?
Perhaps the data from the server should also provide info on which modifications of the data will be accepted. Obviously this is the direction Eligius is already going. I think it would be a great benefit if we can agree on a standard and get as many pool servers, proxies and miners supporting it as possible. As suggested by Luke-jr. already, if you have a proxy supporting this then you don't really need miners to support it directly. But at a minimum you need pool servers and a proxy supporting it. Downside:
Possible fix for the first two points: all the transactions could be replaced by just coinbase and its merkle branch when the data cannot create a block and the miner just needs to prove it is doing work. More efficient but it means supporting 2 ways to deliver work. And it needs an extra "target" value (because of merged mining) to determine the lowest target for which the server can create a block. One problem I can think of is if the miner gets a transaction from a local bitcoind that is on a different fork than the server's bitcoind. In that case you might get a transaction in a block when it already exists in the parent block. But I think duplicate transactions are simply ignored and do no harm, right? PS: Maybe this time have 2 separate RPC procedure names? Not "getwork" both for getting work and for delivering work results. Never made sense to me. Title: Re: Alternative to getwork for miners/proxies Post by: DrHaribo on February 21, 2012, 06:19:06 PM Any thoughts?
Title: Re: Alternative to getwork for miners/proxies Post by: Luke-Jr on February 21, 2012, 06:28:46 PM I think it would be a good idea to add a "target" like "getwork" has, so that the server can control the difficulty for its clients. I agree, this is a major oversight of mine.Also, perhaps the procedure should have a different name, since it is not the same as the "getmemorypool" of bitcoind? I consider it to be the same, just with slightly different semantics based on what the server needs/allows/supports.Perhaps the data from the server should also provide info on which modifications of the data will be accepted. An array of strings in the key named "mutable"?Possible fix for the first two points: all the transactions could be replaced by just coinbase and its merkle branch when the data cannot create a block and the miner just needs to prove it is doing work. More efficient but it means supporting 2 ways to deliver work. Well, the 2nd way could be as simple as truncating the block data after the first transaction, and providing the merkle links between coinbase and root.One problem I can think of is if the miner gets a transaction from a local bitcoind that is on a different fork than the server's bitcoind. In that case you might get a transaction in a block when it already exists in the parent block. But I think duplicate transactions are simply ignored and do no harm, right? No, they invalidate the block. A miner would need to always be working on the same parent as the pool. BitPenny fails over to solo mining when there is a desync.Title: Re: Alternative to getwork for miners/proxies Post by: Luke-Jr on February 28, 2012, 10:29:36 PM https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool
Title: Re: Alternative to getwork for miners/proxies Post by: Gavin Andresen on February 29, 2012, 12:40:31 AM This would replace the existing JSON-RPC getmemorypool command?
Code: getmemorypool [data] And a meta-question: are there any other implementations that will be supporting external mining via JSON-RPC soon? There's no reason to go through the whole BIP process to make a change or improvement to one implementation. Title: Re: Alternative to getwork for miners/proxies Post by: bulanula on February 29, 2012, 12:42:29 AM I am no developer but what about making the protocol more robust / resistant to flaky network connections and high pink 3G WAN links or is that fully independent of the protocol and I am a noob ???
Thanks ! Title: Re: Alternative to getwork for miners/proxies Post by: Luke-Jr on February 29, 2012, 12:55:43 AM This would replace the existing JSON-RPC getmemorypool command? It should be mostly compatible. bitcoind would probably want to add the "mutable" key to inform miners they can change anything.And a meta-question: are there any other implementations that will be supporting external mining via JSON-RPC soon? There's no reason to go through the whole BIP process to make a change or improvement to one implementation. Eloipool (https://gitorious.org/bitcoin/eloipool) also supports getmemorypool now.Title: Re: Alternative to getwork for miners/proxies Post by: Luke-Jr on February 29, 2012, 01:59:43 AM https://en.bitcoin.it/wiki/Poolservers updated
|