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
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UeJfm-0005ar-LW
for bitcoin-development@lists.sourceforge.net;
Mon, 20 May 2013 06:34:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.49 as permitted sender)
client-ip=209.85.160.49; envelope-from=etotheipi@gmail.com;
helo=mail-pb0-f49.google.com;
Received: from mail-pb0-f49.google.com ([209.85.160.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UeJfl-0004jK-25
for bitcoin-development@lists.sourceforge.net;
Mon, 20 May 2013 06:34:18 +0000
Received: by mail-pb0-f49.google.com with SMTP id rp8so3795576pbb.36
for <bitcoin-development@lists.sourceforge.net>;
Sun, 19 May 2013 23:34:11 -0700 (PDT)
X-Received: by 10.66.12.40 with SMTP id v8mr59859787pab.13.1369031651150;
Sun, 19 May 2013 23:34:11 -0700 (PDT)
Received: from [192.168.6.14] (ip-64-134-225-21.public.wayport.net.
[64.134.225.21]) by mx.google.com with ESMTPSA id
zy5sm22740554pbb.43.2013.05.19.23.34.08
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 19 May 2013 23:34:10 -0700 (PDT)
Message-ID: <5199C3DE.901@gmail.com>
Date: Mon, 20 May 2013 02:34:06 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20130519132359.GA12366@netbook.cypherspace.org>
<CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com>
In-Reply-To: <CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------070502010301040004020702"
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
(etotheipi[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: 1UeJfl-0004jK-25
Subject: Re: [Bitcoin-development] is there a way to do bitcoin-staging?
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, 20 May 2013 06:34:18 -0000
This is a multi-part message in MIME format.
--------------070502010301040004020702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
This is exactly what I was planning to do with the inappropriately-named
"Ultimate Blockchain Compression
<https://bitcointalk.org/index.php?topic=88208.0>". I wanted to
reorganize the blockchain data into an authenticated tree, indexed by
TxOut script (address), instead of tx-hash. Much like a regular merkle
tree, you can store the root in the block header, and communicate
branches of that tree to nodes, to prove inclusion (and exclusion!) of
TxOuts for any given script/address. Additionally, you can include at
each node, the sum of BTC in all nodes below it, which offers some other
nice benefits.
I think this idea is has epic upside-potential for bitcoin if it works
-- even "SPV" nodes could query their unspent TxOut list for their
wallet from any untrusted peer and compare the result directly to the
blockheaders/POW. Given nothing but the headers, you can verify the
balance of 100 addresses with 250 kB. But also epic failure-potential
in terms of feasibility and cost-to-benefit for miners. For it to
really work, it's gotta be part of the mainnet validation rules, but no
way it can be evaluated realistically without some kind of "staging".
Therefore, I had proposed that this be merge-mined on a "meta-chain"
first...get a bunch of miners on board to agree to merge mine and see it
in action. It seemed like a perfectly non-disruptive way to prove out a
particular idea before we actually consider making a protocol change
that significant. Even if it stayed on its own meta chain, as long as
there is some significant amount of hashpower working on it, it can
still be a useful tool.
Unfortunately, my experience with merged mining is minimal, so I'm still
not clear how feasible/reliable it is as an alternative to direct
blockchain integration. That's a discussion I'd like to have.
-Alan
On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> I think this is a very interesting idea. As Bitcoiners, we often stuff
> things into the 'alt chain' bucket in our heads; I wonder if this idea
> works better as a curing period, essentially an extended version of
> the current 100 block wait for mined coins.
>
> An alternate setup comes to mind; I can imagine this working as a sort
> of gift economy; people pay real BTC for merge-mined "beta BTC" as a
> way to support development. There is no doubt a more elegant and
> practical solution that might have different economic and crypto
> characteristics.
>
>
>
> On Sun, May 19, 2013 at 6:23 AM, Adam Back <adam@cypherspace.org
> <mailto:adam@cypherspace.org>> wrote:
>
> Is there a way to experiment with new features - eg committed
> coins - that
> doesnt involve an altcoin in the conventional sense, and also
> doesnt impose
> a big testing burden on bitcoin main which is a security and
> testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging? where the coins are the same coins as on
> bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged
> mining, but no
> native mining. and ability to use bitcoins by locking them on
> bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out? Seems vaguely doable and
> maybe productive. The only people with coins at risk of defects
> in a new
> feature, or insufficiently well tested novel feature are people
> with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it. I mean a real live
> system,
> with live value, but that is intentionally wanting to avoid
> forking bitcoins
> parameters, nor value, nor mindshare dillution. In this way something
> potentially interesting could move forward faster, and be les
> risky to the
> main bitcoin network. eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test)
> because
> some parameters are different on test, and some issues may not
> manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge
> them after
> extensive real-world validation with real-money at stake (by early
> adopters).
>
> Adam
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers
> complete
> security visibility with the essential security capabilities.
> Easily and
> efficiently configure, manage, and operate all of your security
> controls
> from a single console and one unified framework. Download a free
> trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> Are you coming to Bitcoin2013 <http://bitcoin2013.com> in San Jose In
> May?
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter@coinlab.com <mailto:peter@coinlab.com> * / 206.486.6856 /
> SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------070502010301040004020702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">This is exactly what I was planning to
do with the inappropriately-named "<a
href="https://bitcointalk.org/index.php?topic=88208.0">Ultimate
Blockchain Compression</a>". I wanted to reorganize the
blockchain data into an authenticated tree, indexed by TxOut
script (address), instead of tx-hash. Much like a regular merkle
tree, you can store the root in the block header, and communicate
branches of that tree to nodes, to prove inclusion (and
exclusion!) of TxOuts for any given script/address. Additionally,
you can include at each node, the sum of BTC in all nodes below
it, which offers some other nice benefits.<br>
<br>
I think this idea is has epic upside-potential for bitcoin if it
works -- even "SPV" nodes could query their unspent TxOut list for
their wallet from any untrusted peer and compare the result
directly to the blockheaders/POW. Given nothing but the headers,
you can verify the balance of 100 addresses with 250 kB. But also
epic failure-potential in terms of feasibility and cost-to-benefit
for miners. For it to really work, it's gotta be part of the
mainnet validation rules, but no way it can be evaluated
realistically without some kind of "staging". Therefore, I had
proposed that this be merge-mined on a "meta-chain" first...get a
bunch of miners on board to agree to merge mine and see it in
action. It seemed like a perfectly non-disruptive way to prove
out a particular idea before we actually consider making a
protocol change that significant. Even if it stayed on its own
meta chain, as long as there is some significant amount of
hashpower working on it, it can still be a useful tool. <br>
<br>
Unfortunately, my experience with merged mining is minimal, so I'm
still not clear how feasible/reliable it is as an alternative to
direct blockchain integration. That's a discussion I'd like to
have.<br>
<br>
-Alan<br>
<br>
<br>
On 5/19/2013 11:08 AM, Peter Vessenes wrote:<br>
</div>
<blockquote
cite="mid:CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com"
type="cite">
<div dir="ltr">I think this is a very interesting idea. As
Bitcoiners, we often stuff things into the 'alt chain' bucket in
our heads; I wonder if this idea works better as a curing
period, essentially an extended version of the current 100 block
wait for mined coins.
<div>
<br>
</div>
<div>An alternate setup comes to mind; I can imagine this
working as a sort of gift economy; people pay real BTC for
merge-mined "beta BTC" as a way to support development. There
is no doubt a more elegant and practical solution that might
have different economic and crypto characteristics.<br>
<div style=""><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, May 19, 2013 at 6:23 AM, Adam
Back <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:adam@cypherspace.org" target="_blank">adam@cypherspace.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Is there a
way to experiment with new features - eg committed coins -
that<br>
doesnt involve an altcoin in the conventional sense, and
also doesnt impose<br>
a big testing burden on bitcoin main which is a security and
testing risk?<br>
<br>
eg lets say some form of merged mine where an alt-coin lets
call it<br>
bitcoin-staging? where the coins are the same coins as on
bitcoin, the<br>
mining power goes to bitcoin main, so some aspect of merged
mining, but no<br>
native mining. and ability to use bitcoins by locking them
on bitcoin to<br>
move them to bitcoin-staging and vice versa (ie exchange
them 1:1<br>
cryptographically, no exchange).<br>
<br>
Did anyone figure anything like that out? Seems vaguely
doable and<br>
maybe productive. The only people with coins at risk of
defects in a new<br>
feature, or insufficiently well tested novel feature are
people with coins<br>
on bitcoin-staging.<br>
<br>
Yes I know about bitcoin-test this is not it. I mean a real
live system,<br>
with live value, but that is intentionally wanting to avoid
forking bitcoins<br>
parameters, nor value, nor mindshare dillution. In this way
something<br>
potentially interesting could move forward faster, and be
les risky to the<br>
main bitcoin network. eg particularly defenses against<br>
<br>
It might also be a more real world test test (after
bitcoin-test) because<br>
some parameters are different on test, and some issues may
not manifest<br>
without more real activity.<br>
<br>
Then also bitcoin could cherry pick interesting patches and
merge them after<br>
extensive real-world validation with real-money at stake (by
early<br>
adopters).<br>
<br>
Adam<br>
<br>
------------------------------------------------------------------------------<br>
AlienVault Unified Security Management (USM) platform
delivers complete<br>
security visibility with the essential security
capabilities. Easily and<br>
efficiently configure, manage, and operate all of your
security controls<br>
from a single console and one unified framework. Download a
free trial.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/alienvault_d2d" target="_blank">http://p.sf.net/sfu/alienvault_d2d</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Are you coming to <a moz-do-not-send="true"
href="http://bitcoin2013.com" target="_blank">Bitcoin2013</a>
in San Jose In May? <br>
<hr
style="font-family:Times;font-size:medium;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-top-color:rgb(204,204,204);margin:10px
0px">
<p
style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span
style="color:rgb(50,90,135);text-transform:uppercase"><img
moz-do-not-send="true"
src="http://coinlab.com/static/images/email_logo.jpg"
alt="CoinLab Logo" width="130" align="right">PETER <span
style="font-weight:bold">VESSENES </span><br>
<span style="color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p>
<p
style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span
style="color:rgb(96,58,23);font-size:0.9em"><strong><a
moz-do-not-send="true" href="mailto:peter@coinlab.com"
style="text-decoration:none;color:rgb(96,58,23)"
target="_blank">peter@coinlab.com</a> </strong> / 206.486.6856
/ <span style="font-size:0.7em;text-transform:uppercase">SKYPE:</span> vessenes </span><br>
<span
style="color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase">71
COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104</span></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/alienvault_d2d">http://p.sf.net/sfu/alienvault_d2d</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------070502010301040004020702--
|
