Alternative to getwork for miners/proxies

[DrHaribo]

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. 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?

• Verify which address(es) the coins are going to, so pool op cannot steal without miners knowing it
• Look for merged mining data in the coinbase, so pool op cannot secretly merged mine
• Look for "water marks" (pool name) to see where your hashes are actually going. If you are mining on pool "A" and the name of pool "B" is in the coinbase, you will know what's going on. Yes, pool "A" could pretend to be pool "B" if they wanted. But they cannot remove pool "B"s name if using work from pool "B".
• Perhaps prevent being used in 51% attacks? Bitcoin blocks will soon be required to include the block height in the coinbase, and you already have the hash for the parent block in the block header. Comparing height and parent block with a trusted source, you could see if you are building at a height lower than you should, or an unknown parent block. Only thing is, blocks take some time to become known by everyone, and there are also (non-hostile) forks. As long as the height looks ok, you'd have to cut some slack for unknown parent blocks.
• Display some of this info to the user, like height, generate payment address(es), presence of merged mining and pool names or other printable strings.
• IF server allows: Exclude transactions by whatever criteria the miner wants
• IF server allows: Add more transactions the server doesn't know
• IF server allows: Allow the miner to create its own work, thereby drastically reducing server load (server must allow modifying the coinbase, at least appending an extra nonce to it).
• IF server allows modifying coinbase: allows miner to put its own mark in the coinbase (or is that a bad thing?)

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:

• Largish proofs of work from miners as the server must now accept entire bitcoin blocks - not just headers but a long list of transactions as well.
• Servers: Possibly heavier processing of proofs of work from miners, depending on whether you care to check that all the transactions are OK and whether you allow modifying the coinbase.
• Scammers: More difficult to scam people

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.

[1715552305]

1715552305

[1715552305]

1715552305

[DrHaribo]

Any thoughts?

[Luke-Jr]

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.

[Luke-Jr]

https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool

[Gavin Andresen]

This would replace the existing JSON-RPC getmemorypool command?

Code:

getmemorypool [data]
If [data] is not specified, returns data needed to construct a block to work on:
  "version" : block version
  "previousblockhash" : hash of current highest block
  "transactions" : contents of non-coinbase transactions that should be included in the next block
  "coinbasevalue" : maximum allowable input to coinbase transaction, including the generation award and transaction fees
  "coinbaseflags" : data that should be included in coinbase so support for new features can be judged
  "time" : timestamp appropriate for next block
  "mintime" : minimum timestamp appropriate for next block
  "curtime" : current timestamp
  "bits" : compressed target of next block
If [data] is specified, tries to solve the block and returns true if it was successful.

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.

[bulanula]

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 !

[Luke-Jr]

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 also supports getmemorypool now.

[Luke-Jr]

https://en.bitcoin.it/wiki/Poolservers updated