Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Um9LG-0003fr-9W for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 21:09:30 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Um9LF-0007BC-04 for bitcoin-development@lists.sourceforge.net; Mon, 10 Jun 2013 21:09:30 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r5AL9IBc019681 for ; Mon, 10 Jun 2013 22:09:18 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r5AL9DdX083818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 10 Jun 2013 22:09:16 +0100 (BST) Date: Mon, 10 Jun 2013 17:09:13 -0400 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20130610210913.GA17242@petertodd.org> References: <20130527111149.GB8955@tilt> <20130531165445.GA29104@petertodd.org> <20130531165758.GA29135@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20130531165758.GA29135@petertodd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 025651a9-d212-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgV1 Kg0XXVBSFQZ4Ax4L BhcUUx88dgJCZn9y bFhgVm5ZWE1lcE56 XU8aV2h3GW4UPAgf WENQdgsaeAVJeFFF aFV5UXJcaHhTZHti WlZqMmp0NGkOI2EN GltQfApNHh5UF2cq fR1QVQYFHFEOQCQ1 ahArNFMYG14UP0Mu BBMNVFkVNQMIAwlf DUBLD2dcJl8AQSVD X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Um9LF-0007BC-04 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:09:30 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 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. 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. ## 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 --=20 'peter'[:-1]@petertodd.org 000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189 --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlG2QHkACgkQpEFN739thowGvQCfeMJsHXVA3mnMs/LBwP8U5Zvg Sf8AmgM/Rf8uAPTHlcQvBT+TGwXBQY4E =elII -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--