MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Message-id: <4F52AE86.2060102@bitminter.com>
Date: Sun, 04 Mar 2012 00:51:34 +0100
From: Geir Harald Hansen <operator@bitminter.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216
	Thunderbird/10.0.2
To: bitcoin-development@lists.sourceforge.net
References: <201202281706.22650.luke@dashjr.org>
In-reply-to: <201202281706.22650.luke@dashjr.org>
Subject: Re: [Bitcoin-development] getmemorypool BIP process
Precedence: list

On 28.02.2012 23:06, Luke-Jr wrote:
> Please review and comment/critique:
>     https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool

Looking forward to implementing this in my pool backend and miner.

A few comments:

"transactions 	add or remove transactions (both of the above; default if
"transactions" omitted) "

In the above, you may want to specify that the "transactions" referred
to here is the one in the first table (JSON-RPC response object) and not
the mutations. For a moment I thought free tx editing was the default.

Long polling as currently implemented in pools has a race condition.
Does the miner reconnect first or does another block change happen
first? "Double" block changes are common with merged mining and I'm
doing all sorts of tricks in my pool backend to reduce this problem.

How about another entry "longpollid" in long poll responses. The last
seen longpollid should be included by the client in future long poll
requests. This enables the server to see if the client has missed any
block changes. The ID could perhaps be submitted in an HTTP header
(X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params
could hold an object with a key "longpollid". Could be a string or
number, like "workid".

Another useful value in the getmemorypool response would be "height", so
the miner can include the correct height in the coinbase. I would like
that in bitcoind as well. One JSON-RPC call instead of two, and no race
condition between getmemorypool and getblocknumber.

It should be explained how target vs. fulltarget works.

Perhaps some things should be optional for a client to implement? I
think "noncerange" is of limited use and there's a good chance of
getting the endianness wrong.

Regards,
Geir Harald Hansen