From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Mon, 10 Jun 2013 21:23:14 +0000
User-Agent: KMail/1.13.7 (Linux/3.7.8-gentoo; KDE/4.10.2; x86_64; ; )
References: <20130527111149.GB8955@tilt> <20130531165758.GA29135@petertodd.org>
	<20130610210913.GA17242@petertodd.org>
In-Reply-To: <20130610210913.GA17242@petertodd.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201306102123.15732.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Decentralizing mining
Precedence: list

On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote:
> # Protocol Work

This is basically done.

> Basic idea is the miner makes two connections, their pool, and a local
> bitcoind.
> 
> 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.

The plan was to tell the pool it doesn't need to send transactions at all, and 
only work on the ones from bitcoind. Currently, share submissions are just the 
block header and coinbase transaction; in this case, however, the miner will 
need to send merkle links also, possibly just once via a block proposal in 
advance.

> 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
> issues.

Currently, BFGMiner is doing submission to the pool, waiting for a response, 
then submitting to a local bitcoind. This is because the pool might need to 
receive/record the share before it processes the block on bitcoind, or you 
could lose credit for it. The response from the pool is rather small (a single 
TCP packet), so this shouldn't delay much longer.

> ## 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.

Might as well just use higher difficulty shares (each one audited) for the 
same effect. Block proposals allow the miner to tell the pool its transaction 
set once (per txset change) for any number of shares.

IF bandwidth becomes a real problem, I have a draft of a "GBT 2.0" that does 
some more improvement in this area.

> # 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

I don't follow.

> # 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.

libblkmaker's API was designed for this from the start, so it should be fairly 
easily implemented.

> We also want an automatic fallback to local solo mining if the pool
> can't be contacted.
> 
> + possible protocol extensions

Failover already functions, but probably could use a rewrite...

Luke