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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
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 <pete@petertodd.org>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <bitcoin-development@lists.sourceforge.net>;
Mon, 10 Jun 2013 22:09:16 +0100 (BST)
Date: Mon, 10 Jun 2013 17:09:13 -0400
From: Peter Todd <pete@petertodd.org>
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: <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: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--
|
