📅 Original date posted:2012-03-03
📝 Original message: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
Geir Harald Hansen [ARCHIVE] /
npub1kp…7e3fd
2023-06-07 03:12:06
in reply to nevent1q…mem6
Author Public Key
npub1kpxa282a99fc93xx30ru3sfmqnyqk3r8aurz3znzxyslhd7felfsg7e3fdPublished at
2023-06-07 03:12:06Event JSON
{
"id": "0559629634ab35c5f4effee93105843d1e4de41b8dbb4452133c4d92983875d2",
"pubkey": "b04dd51d5d295382c4c68bc7c8c13b04c80b4467ef06288a623121fbb7c9cfd3",
"created_at": 1686107526,
"kind": 1,
"tags": [
[
"e",
"3c851c8f17df1dd68608e4374d6cde0ed02a6a2268be0433e6610590ab1017ab",
"",
"root"
],
[
"e",
"1d07aef20ebb8e2ef7a2d4d379b8abee9c1d671be02d1a6029aa3abfd8c29c2e",
"",
"reply"
],
[
"p",
"49f07bd32c0108a2903a0fa59f904ed312e0ea427d3269eb5fa910eb4a9e22c4"
]
],
"content": "📅 Original date posted:2012-03-03\n📝 Original message:On 28.02.2012 23:06, Luke-Jr wrote:\n\u003e Please review and comment/critique:\n\u003e https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool\n\nLooking forward to implementing this in my pool backend and miner.\n\nA few comments:\n\n\"transactions \tadd or remove transactions (both of the above; default if\n\"transactions\" omitted) \"\n\nIn the above, you may want to specify that the \"transactions\" referred\nto here is the one in the first table (JSON-RPC response object) and not\nthe mutations. For a moment I thought free tx editing was the default.\n\nLong polling as currently implemented in pools has a race condition.\nDoes the miner reconnect first or does another block change happen\nfirst? \"Double\" block changes are common with merged mining and I'm\ndoing all sorts of tricks in my pool backend to reduce this problem.\n\nHow about another entry \"longpollid\" in long poll responses. The last\nseen longpollid should be included by the client in future long poll\nrequests. This enables the server to see if the client has missed any\nblock changes. The ID could perhaps be submitted in an HTTP header\n(X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params\ncould hold an object with a key \"longpollid\". Could be a string or\nnumber, like \"workid\".\n\nAnother useful value in the getmemorypool response would be \"height\", so\nthe miner can include the correct height in the coinbase. I would like\nthat in bitcoind as well. One JSON-RPC call instead of two, and no race\ncondition between getmemorypool and getblocknumber.\n\nIt should be explained how target vs. fulltarget works.\n\nPerhaps some things should be optional for a client to implement? I\nthink \"noncerange\" is of limited use and there's a good chance of\ngetting the endianness wrong.\n\nRegards,\nGeir Harald Hansen",
"sig": "d5167199f93ac83f3109111ef206bbfe752c6e7d3ae4f7190ab6bbe6191d9cad82be40ddd81af40d4eb9f9c2d2e091124def53638a90ec263b18aa3997b1926c"
}