slush0
commented
8 years ago Hey Jonathan,
I had the idea of tunelling GF with Stratum when I read concerns about chinese pools, too. However I think this is infrastructure-specific addon and any additional RPC methods should not be available for miners, so I don't see a need to change reference implementation (AFAIK no pool is using this implementation without heavy changes anyway).
Problem with this setup is that both "blockchain validation server" which generates stratum jobs (outside China) and "stratum mining proxy" which broadcast jobs to end miners (in China mainland) must be operated by the same entity because of trust issue (hashrate hijacking, validating unofficial rules etc). I don't think it is feasible some large chinese pool will rely on "blockchain validation server" which is operated by another entity. Because of this, I actually don't think it is even needed to add "submitfull" RPC, because if you operates blockchain validation server yourself, you don't need to push coinbase from China anymore.
Anyway, I'm working on new version of Stratum and I'll publish paper soon. New protocol proposal adds some specific features which would be useful especially in enterprise setups like this (tunneling whole Chinese hashrate via single Stratum connection etc).
jtoomim
I am working with a few pools to add a new feature to their pool system. I described a simplified version of this feature in my talk at Scaling Bitcoin:
http://toom.im/files/Jonathan_Toomim_BIP101_block_progapation_on_testnet.pdf page 23
https://www.youtube.com/watch?v=ivgxcEOyWNs&feature=youtu.be&t=2h46m00s
The basic idea is to use what is essentially a stratum proxy to cross the Great Firewall of China so that full blocks never have to cross the Firewall, at least not in the latency-critical path. Pools would operate bitcoind servers abroad which perform getblocktemplate, and send the summarized results to the poolserver via a slightly enhanced version of stratum.
The issue with this approach is that we don't trust the servers abroad to honestly enter the coinbase output address and the rest of the coinbase transaction. What we want to do is generate the whole coinbase transaction on the trusted poolserver in China. Currently we can do that, no problem, but we don't have an interface for submitting the new coinbase transaction back to our servers abroad when we submit the job via stratum.
What I would like to add is another function, say mining.submitfull(...) that includes the full coinbase tx instead of just the extranonce info. This extended interface should be disabled by default (lest a pool accept work that didn't pay the pool at all).
We can write the code for this on our own. The question I have for you is this: if we implemented this and submitted a pull request, do you think this is the kind of feature you would like to see in this project, or do you think it's better that we just maintain it as a fork?