1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
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
|
