Author: Peter Todd 2013-06-10 21:09:13
Published on: 2013-06-10T21:09:13+00:00
The context discusses the parts needed for step #1 of the pooled-solo mining mode. The basic idea is that the miner makes two connections: their pool and a local bitcoind. They work on the subset of transactions common to both the pool's getblocktemplate and their local one. If they find a share that doesn't meet difficulty, they hand it over to the pool. For shares that do meet difficulty, they hand it to both the pool and the local bitcoind, with an optimized version possibly having some record of measured bandwidth. To reduce bandwidth, they suggest passing only the block header for normal shares and having the pool randomly pick a subset of transactions to audit. This will work best in conjunction with a UTXO proof tree or by picking whole shares randomly to audit. Persistent share storage will be needed if the connection disconnects. They also discuss the deliberate orphaning of slow to propagate blocks, with nodes passing headers around separately via UDP. When a valid block header is seen whose contents they don't know about, miners should switch to mining empty or near-empty blocks in solo mode that would orphan the still propagating block. For pool work, they ask if eliopool already accepts arbitrary shares and does the correct accounting. They also mention possible protocol extensions. Miner work involves merging the two block templates together to find commonality. There should also be an automatic fallback to local solo mining if the pool can't be contacted, with possible protocol extensions.
Updated on: 2023-06-06T18:19:15.314108+00:00