Matt Corallo
Matt Corallo
Need to make sure both mining-proxy and pool-proxy can re-accept shares at least for a brief period after a disconnect.
We need some analysis on a per-user basis of too many shares possibly indicative of weak block witholding. Assuming a max-median payout limit this should just be belt-and-suspenders, and assuming...
Will need something like https://github.com/bitcoin/bitcoin/pull/13415 though with a slight tweak to interpret the data as provided by TRANSACTION_DATA.
Pool-side transaction data should be deduplicated in memory across clients, with clients sending lots of novel data getting weak block data resets.
Maybe we dont want to use TCP, maybe we want to switch to a different congestion control algorithm, maybe we want to run some dirty hack on the servers that...
...so that it can deliver them later, keeping the bitcoind sigcache warm.
See https://github.com/TheBlueMatt/RelayNode/blob/master/c%2B%2B/relayprocess.cpp#L68 and eg https://github.com/bitcoin/bitcoin/pull/6508
but, yea, the client software is pretty stable when it fails it just reconnects which is what makes it stable :) even to another node? no, sadly not i really...
It would be nice to have a client which is available to miners to peer with each other that doesnt depend on the centralized infrastructure.
client.cpp should grow an RPCClient to the same bitcoind and use that to send non-oob txn to the server.