[Bitcoin-development] Decentralizing mining
melvincarvalho at gmail.com
Mon Jun 10 21:31:18 UTC 2013
On 10 June 2013 23:09, Peter Todd <pete at petertodd.org> wrote:
> So here's the parts that need to be done for step #1:
> # Protocol Work
> Basic idea is the miner makes two connections, their pool, and a local
> They always (usually?) work on the subset of transactions common to both
> the pool's getblocktemplate and their local one. When they find a share
> if it doesn't meet difficulty they just hand it to the pool. Currently
> that is done by handing the whole block over, correct? I know the BIP
> says otherwise, but we should optimize this to just hand over tx hashes
> where possible.
> If the share does meet difficulty, hand it to both the pool and the
> local bitcoind. Should hand it to the pool first though, because the
> pool likely has the fastest block propagation, then hand it to local
> bitcoind. An optimized version may want to have some record of measured
> bandwidth - this applies Bitcoin in general too, although also has other
> ## Reducing bandwidth
> How about for normal shares we just pass the block header, and have the
> pool randomly pick a subset of transactions to audit? Any fraud cancels
> the users shares. This will work best in conjunction with a UTXO proof
> tree to prove fees, or by just picking whole shares randomly to audit.
> We'll need persistent share storage so if your connection disconnects
> you can provide the pool with the full share later though.
> Incedentally, note how the miner can do the reverse: pick random block
> headers and challenge the pool to prove that they correspond to a valid
> block. With some modifications Stratum can support this approach.
> ## Delibrate orphaning of slow to propagate blocks
> Block headers can be flooded-filled much faster than blocks themselves.
> They are also small enough to fit into a UDP packet. Nodes should pass
> headers around separately via UDP, optinally with some tiny number of
> transactions. When we see a valid block header whose contents we do not
> know about a miner should switch to mining empty or near empty blocks in
> solo mode that would orphan the still propagating block. Doing this is
> safe, we'll never build on an invalid block, economically rational while
> the inflation subsidy is still high, and helps reduce (although not
> eliminate!) the advantage a large miner with high-bandwidth connections
> has over those who don't.
> Of course, the other option is to build a block extending the one you
> don't know about, which is even more rational, but doing poses major
> risks to Bitcoin...
> This functionality can be implemented later - it's not strictly part of
> pooled-solo mode.
> # Pool work
> So does eliopool already accept arbitrary shares like this and do the
> correct accounting already? (IE adjust share amount based on fees?) What
> happens when the pool doesn't get the share directly, but does see the
> new block?
> + possible protocol extensions
> # Miner work
> Basically we need code to merge the two block templates together to find
> commonality. I guess you probably want to implement this in bfgminer
> first, so add the code to libblkmaker first, then maybe python-blkmaker.
> We also want an automatic fallback to local solo mining if the pool
> can't be contacted.
> + possible protocol extensions
Sounds very promising. Suspect it will need a fair amount of testing ...
> This SF.net email is sponsored by Windows:
> Build for Windows Store.
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev