summaryrefslogtreecommitdiff
path: root/02/7920d4d1ea77d120d9afafe6ef687f2e8a65c4
blob: 339ced5b3ecfab72af13ad1172684f81135335a9 (plain)
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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1Um9gU-0005cG-Mm
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 21:31:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.45 as permitted sender)
	client-ip=209.85.215.45; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f45.google.com; 
Received: from mail-la0-f45.google.com ([209.85.215.45])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Um9gT-00010j-8r
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 21:31:26 +0000
Received: by mail-la0-f45.google.com with SMTP id fr10so6235250lab.32
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Jun 2013 14:31:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.189.101 with SMTP id gh5mr7336682lbc.73.1370899878441;
	Mon, 10 Jun 2013 14:31:18 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Mon, 10 Jun 2013 14:31:18 -0700 (PDT)
In-Reply-To: <20130610210913.GA17242@petertodd.org>
References: <20130527111149.GB8955@tilt> <20130531165445.GA29104@petertodd.org>
	<20130531165758.GA29135@petertodd.org>
	<20130610210913.GA17242@petertodd.org>
Date: Mon, 10 Jun 2013 23:31:18 +0200
Message-ID: <CAKaEYhKDhPmORRgXSYg+4wrCFcCdvmRW9nJcbzWba4NraEqkQA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c3738a46f9bc04ded3807e
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Um9gT-00010j-8r
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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:31:26 -0000

--001a11c3738a46f9bc04ded3807e
Content-Type: text/plain; charset=ISO-8859-1

On 10 June 2013 23:09, Peter Todd <pete@petertodd.org> wrote:

> 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
>

Sounds very promising.  Suspect it will need a fair amount of testing ...


>
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a11c3738a46f9bc04ded3807e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 June 2013 23:09, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"=
mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">So here&#39;s the parts that need to be done=
 for step #1:<br>
<br>
<br>
# Protocol Work<br>
<br>
Basic idea is the miner makes two connections, their pool, and a local<br>
bitcoind.<br>
<br>
They always (usually?) work on the subset of transactions common to both<br=
>
the pool&#39;s getblocktemplate and their local one. When they find a share=
<br>
if it doesn&#39;t meet difficulty they just hand it to the pool. Currently<=
br>
that is done by handing the whole block over, correct? I know the BIP<br>
says otherwise, but we should optimize this to just hand over tx hashes<br>
where possible.<br>
<br>
If the share does meet difficulty, hand it to both the pool and the<br>
local bitcoind. Should hand it to the pool first though, because the<br>
pool likely has the fastest block propagation, then hand it to local<br>
bitcoind. An optimized version may want to have some record of measured<br>
bandwidth - this applies Bitcoin in general too, although also has other<br=
>
issues.<br>
<br>
<br>
## Reducing bandwidth<br>
<br>
How about for normal shares we just pass the block header, and have the<br>
pool randomly pick a subset of transactions to audit? Any fraud cancels<br>
the users shares. This will work best in conjunction with a UTXO proof<br>
tree to prove fees, or by just picking whole shares randomly to audit.<br>
<br>
We&#39;ll need persistent share storage so if your connection disconnects<b=
r>
you can provide the pool with the full share later though.<br>
<br>
Incedentally, note how the miner can do the reverse: pick random block<br>
headers and challenge the pool to prove that they correspond to a valid<br>
block. With some modifications Stratum can support this approach.<br>
<br>
<br>
## Delibrate orphaning of slow to propagate blocks<br>
<br>
Block headers can be flooded-filled much faster than blocks themselves.<br>
They are also small enough to fit into a UDP packet. Nodes should pass<br>
headers around separately via UDP, optinally with some tiny number of<br>
transactions. When we see a valid block header whose contents we do not<br>
know about a miner should switch to mining empty or near empty blocks in<br=
>
solo mode that would orphan the still propagating block. Doing this is<br>
safe, we&#39;ll never build on an invalid block, economically rational whil=
e<br>
the inflation subsidy is still high, and helps reduce (although not<br>
eliminate!) the advantage a large miner with high-bandwidth connections<br>
has over those who don&#39;t.<br>
<br>
Of course, the other option is to build a block extending the one you<br>
don&#39;t know about, which is even more rational, but doing poses major<br=
>
risks to Bitcoin...<br>
<br>
This functionality can be implemented later - it&#39;s not strictly part of=
<br>
pooled-solo mode.<br>
<br>
<br>
# Pool work<br>
<br>
So does eliopool already accept arbitrary shares like this and do the<br>
correct accounting already? (IE adjust share amount based on fees?) What<br=
>
happens when the pool doesn&#39;t get the share directly, but does see the<=
br>
new block?<br>
<br>
+ possible protocol extensions<br>
<br>
<br>
# Miner work<br>
<br>
Basically we need code to merge the two block templates together to find<br=
>
commonality. I guess you probably want to implement this in bfgminer<br>
first, so add the code to libblkmaker first, then maybe python-blkmaker.<br=
>
<br>
We also want an automatic fallback to local solo mining if the pool<br>
can&#39;t be contacted.<br>
<br>
+ possible protocol extensions<br></blockquote><div><br></div><div>Sounds v=
ery promising.=A0 Suspect it will need a fair amount of testing ...<br></di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
This SF.net email is sponsored by Windows:<br>
<br>
Build for Windows Store.<br>
<br>
<a href=3D"http://p.sf.net/sfu/windows-dev2dev" target=3D"_blank">http://p.=
sf.net/sfu/windows-dev2dev</a><br>_________________________________________=
______<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--001a11c3738a46f9bc04ded3807e--