diff options
| author | Luke-Jr <luke@dashjr.org> | 2013-06-10 21:23:14 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-10 21:23:28 +0000 |
| commit | a5ad502328e0dfb356da23e6e0d686a30506ce45 (patch) | |
| tree | 3aec5f96ba5001de92c085d7b3556f7c4e7ad868 | |
| parent | 25ee6c507a2c959df78a989e56968dda031d7803 (diff) | |
| download | pi-bitcoindev-a5ad502328e0dfb356da23e6e0d686a30506ce45.tar.gz pi-bitcoindev-a5ad502328e0dfb356da23e6e0d686a30506ce45.zip | |
Re: [Bitcoin-development] Decentralizing mining
| -rw-r--r-- | 3f/b71cf229779629a609f1a2d10bed34dcb2a1f2 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/3f/b71cf229779629a609f1a2d10bed34dcb2a1f2 b/3f/b71cf229779629a609f1a2d10bed34dcb2a1f2 new file mode 100644 index 000000000..5520b0588 --- /dev/null +++ b/3f/b71cf229779629a609f1a2d10bed34dcb2a1f2 @@ -0,0 +1,129 @@ +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 <luke@dashjr.org>) 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" <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> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 + + |