📅 Original date posted:2012-03-03
📝 Original message:On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote:
> 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 would you suggest addressing this? I presume if a share solves blocks on
multiple chains, you just longpoll once when that's successful?
> 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".
Hmm, the problem is that adding any parameters to getmemorypool itself breaks
compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific
again. Any ideas?
> 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.
Good catch. Should this be required (since it might be necessary for future
Bitcoin blocks), or just "should" for compatibility?
> It should be explained how target vs. fulltarget works.
What is unclear about this?
> Perhaps some things should be optional for a client to implement?
Doing this safely needs some way for clients to communicate capabilities to
the server, which has the problem of passing parameters to getmemorypool.
> I think "noncerange" is of limited use and there's a good chance of getting
> the endianness wrong.
There is no mining hardware to date that exhausts even half the nonce space,
so I'd really prefer to see this as a required feature on the miner side. On
the other hand, it's merely an extension for getwork, so I can see the problem
so long as we're using getwork proxies.
Luke
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 03:12:09
in reply to nevent1q…57l2
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsSeen on
wss://relay.nostr.bandPublished at
2023-06-07 03:12:09Event JSON
{
"id": "a454421122a120644d95a58e2652485aaf43afb47604330a5f9b0f8dee454155",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686107529,
"kind": 1,
"tags": [
[
"e",
"3c851c8f17df1dd68608e4374d6cde0ed02a6a2268be0433e6610590ab1017ab",
"",
"root"
],
[
"e",
"0559629634ab35c5f4effee93105843d1e4de41b8dbb4452133c4d92983875d2",
"",
"reply"
],
[
"p",
"b04dd51d5d295382c4c68bc7c8c13b04c80b4467ef06288a623121fbb7c9cfd3"
]
],
"content": "📅 Original date posted:2012-03-03\n📝 Original message:On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote:\n\u003e Long polling as currently implemented in pools has a race condition.\n\u003e Does the miner reconnect first or does another block change happen\n\u003e first? \"Double\" block changes are common with merged mining and I'm\n\u003e doing all sorts of tricks in my pool backend to reduce this problem.\n\nHow would you suggest addressing this? I presume if a share solves blocks on \nmultiple chains, you just longpoll once when that's successful?\n\n\u003e How about another entry \"longpollid\" in long poll responses. The last\n\u003e seen longpollid should be included by the client in future long poll\n\u003e requests. This enables the server to see if the client has missed any\n\u003e block changes. The ID could perhaps be submitted in an HTTP header\n\u003e (X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params\n\u003e could hold an object with a key \"longpollid\". Could be a string or\n\u003e number, like \"workid\".\n\nHmm, the problem is that adding any parameters to getmemorypool itself breaks \ncompatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific \nagain. Any ideas?\n\n\u003e Another useful value in the getmemorypool response would be \"height\", so\n\u003e the miner can include the correct height in the coinbase. I would like\n\u003e that in bitcoind as well. One JSON-RPC call instead of two, and no race\n\u003e condition between getmemorypool and getblocknumber.\n\nGood catch. Should this be required (since it might be necessary for future \nBitcoin blocks), or just \"should\" for compatibility?\n\n\u003e It should be explained how target vs. fulltarget works.\n\nWhat is unclear about this?\n\n\u003e Perhaps some things should be optional for a client to implement?\n\nDoing this safely needs some way for clients to communicate capabilities to \nthe server, which has the problem of passing parameters to getmemorypool.\n\n\u003e I think \"noncerange\" is of limited use and there's a good chance of getting\n\u003e the endianness wrong.\n\nThere is no mining hardware to date that exhausts even half the nonce space, \nso I'd really prefer to see this as a required feature on the miner side. On \nthe other hand, it's merely an extension for getwork, so I can see the problem \nso long as we're using getwork proxies.\n\nLuke",
"sig": "257d464342c494a77a9f734d4fe3f6b6d6ad05fe57f34e7ed9266a40676dab1ab357110f152ab2b590df05bba2bb7399e26494b0119447990b6af3ef5b5afb3c"
}