Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Um9Ym-00018D-1f for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 21:23:28 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Um9Yj-0007uQ-Ue for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 21:23:28 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id DE39A27A2965; Mon, 10 Jun 2013 21:23:17 +0000 (UTC) From: "Luke-Jr" 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> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201306102123.15732.luke@dashjr.org> X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Um9Yj-0007uQ-Ue Subject: Re: [Bitcoin-development] Decentralizing mining X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:23:28 -0000 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