From: Geir Harald Hansen <operator@bitminter•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] getmemorypool BIP process
Date: Sun, 04 Mar 2012 00:51:34 +0100 [thread overview]
Message-ID: <4F52AE86.2060102@bitminter.com> (raw)
In-Reply-To: <201202281706.22650.luke@dashjr.org>
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
next prev parent reply other threads:[~2012-03-04 0:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 22:06 Luke-Jr
2012-03-03 14:23 ` Stefan Thomas
2012-03-03 15:00 ` Luke-Jr
2012-03-03 17:08 ` Michael Grønager
2012-03-04 0:18 ` Stefan Thomas
2012-03-03 23:51 ` Geir Harald Hansen [this message]
2012-03-04 1:04 ` Luke-Jr
2012-03-04 17:49 ` Geir Harald Hansen
2012-03-03 15:44 Luke-Jr
2012-03-04 0:18 ` Stefan Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F52AE86.2060102@bitminter.com \
--to=operator@bitminter$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox