summaryrefslogtreecommitdiff
path: root/9e/8cda3fb68dca24e1929bc0b2b0aab6415fc2f8
blob: 23e9d2bd83a8a4d21c7627e4fd7f300ea834fa29 (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
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dennison@dennisonbertram.com>) id 1UoFAb-0003Ak-KI
	for bitcoin-development@lists.sourceforge.net;
	Sun, 16 Jun 2013 15:47:09 +0000
X-ACL-Warn: 
Received: from mail-we0-f175.google.com ([74.125.82.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UoFAZ-0007hK-Nd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 16 Jun 2013 15:47:09 +0000
Received: by mail-we0-f175.google.com with SMTP id t59so1656835wes.6
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 16 Jun 2013 08:47:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=MFjyIkGYwix705GVMj96bJ1iirCBcqKfd4a2iv+aW0s=;
	b=hyQXVNMY7XLFl8+PV95GpD0323fXS1BhNP2LOHxpE3BRbPqb7jjw+KkMhTg/Ebr1Sb
	r6jFIdKh2vwo4FRR76Ln1AUzUGghiAwT3t1JDPpDWSpTdrh4wdQj3siSXHrqmWjvaWhy
	5e7OKzxsqWi7iFOuWNTSBGbLB1HrigU5RCHGDfrPAxU8JrB4j2rFPj9+n4JkqAjmSS9S
	s+mpv44Hs98jP0M1V378+bx+7otGXCqYJwbLOzqcmE/iUNuZUCnbwrvfuywU7Cr8hxx9
	eBcaZSSx7cCz7qIeUssEhg+wY/OAoQLQU1PFeOPubvG9Y/Ut3rOFjAZz8UdwpWyHSQ9x
	YnEg==
X-Received: by 10.194.1.226 with SMTP id 2mr5951355wjp.91.1371397621490; Sun,
	16 Jun 2013 08:47:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.1.137 with HTTP; Sun, 16 Jun 2013 08:46:41 -0700 (PDT)
X-Originating-IP: [46.246.35.235]
In-Reply-To: <B19431AC-47B9-4BB2-9AA0-28C114556A01@dennisonbertram.com>
References: <20130519132359.GA12366@netbook.cypherspace.org>
	<CAKaEYhJfrszqC=7L9inkSH5+9nzUzRLx6Oq+C6bA+fDXXLfh8Q@mail.gmail.com>
	<B19431AC-47B9-4BB2-9AA0-28C114556A01@dennisonbertram.com>
From: Dennison Bertram <dennison@dennisonbertram.com>
Date: Sun, 16 Jun 2013 17:46:41 +0200
Message-ID: <CANTZ12OEzOgK2Q7uO4KP94ojChSSpVL_M+p-+gTfqFDoJGjHJQ@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a82d413391304df476422
X-Gm-Message-State: ALoCoQkKnOrAn1y2+BP5CU+OZgk9kQZHFAWzwLRRx4VoRT+nAxjtYl2lyQi9zijYUucMiMdfaOjC
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1UoFAZ-0007hK-Nd
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
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: Sun, 16 Jun 2013 15:47:09 -0000

--047d7b3a82d413391304df476422
Content-Type: text/plain; charset=ISO-8859-1

Is there a relatively easy way to switch between Testnet versions in the
client? On the forums I am in discussion with one member who mentioned the
idea of a Main net, a testnet and a "beta-net" where the coins on the
beta-net would be allowed to have value. It seems like simple and logical
way to do this would be something like a "testnet=1, testnetversion=3" in
the bitcoin.conf file. Is this possible?


On Sat, Jun 15, 2013 at 3:26 PM, Dennison Bertram <
dennison@dennisonbertram.com> wrote:

> Why use ripple and not just use the testnet?
>
> The advantageous of allowing testnet to be used as an alt-coin are
> That Non standard transactions can be tested in a pseudo live environment
> where because the coins have some nominal value people are incentivized to
> try and steal and come up with clever ways of gamin the system. This sort
> of knowledge would be invaluable if non standard transactions are ever
> going to become a reality on main net.
>
> It also allows developers a chance to develop in advance new technologies
> and services that currently won't run on bitcoin main net but might be
> enabled in the future at which point they can switch over to main net.
> Additionally without any development happening with non standard
> transactions as currently there is no economic incentive , there might be a
> strong argument to never bother enabling non standard transactions as the
> risk of doing so might not justify in many people's minds  the benefits as
> if no one develops anything in advance  most users might not find the
> theoretical possibilities worth the risk, thus permanently hobbling the
> full potential of satoshis idea. Rather if testnet were allowed to act as
> an alt coin something cool might be developed that the main net users might
> desire enough to overcome the inertia of the status quo.
>
> Additionally it should be considered that the time in the future when non
> standard transactions might be enabled  might be so far in the future when
> bitcoin has hit mass adoption and changing anything might require far more
> political negotiations between users and devs then currently. Meaning that
> perhaps much more proof of functionality and value as well as testing might
> e required.
>
> Dennison
>
> Sent from my iPhone
>
> On Jun 15, 2013, at 1:18 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
>
> On 19 May 2013 15:23, Adam Back <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).
>>
>
> Interesting idea.  I wonder if ripple could be used to set up a transfer
> system between the 'main' and 'staging' systems ...
>
>
>>
>> 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
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 

Dennison Bertram, photographer and film maker

www.dennisonbertram.com

dennison@dennisonbertram.com

Milan: +39 320 781 0128

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

<div dir=3D"ltr">Is there a=A0relatively=A0easy way to switch between Testn=
et versions in the client? On the forums I am in discussion with one member=
 who mentioned the idea of a Main net, a testnet and a &quot;beta-net&quot;=
 where the coins on the beta-net would be allowed to have value. It seems l=
ike simple and logical way to do this would be something like a &quot;testn=
et=3D1, testnetversion=3D3&quot; in the bitcoin.conf file. Is this possible=
?=A0</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jun 1=
5, 2013 at 3:26 PM, Dennison Bertram <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:dennison@dennisonbertram.com" target=3D"_blank">dennison@dennisonbertram.=
com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Why use ripple and no=
t just use the testnet?=A0</div><div><br></div><div>The advantageous of all=
owing testnet to be used as an alt-coin are That=A0Non standard transaction=
s can be tested in a pseudo live environment where because the coins have s=
ome nominal value people are incentivized to try and steal and come up with=
 clever ways of gamin the system. This sort of knowledge would be invaluabl=
e if non standard transactions are ever going to become a reality on main n=
et.=A0</div>

<div><br></div><div>It also allows developers a chance to develop in advanc=
e new technologies and services that currently won&#39;t run on bitcoin mai=
n net but might be enabled in the future at which point they can switch ove=
r to main net. Additionally without any development happening with non stan=
dard transactions as currently there is no economic incentive , there might=
 be a strong argument to never bother enabling non standard transactions as=
 the risk of doing so might not justify in many people&#39;s minds =A0the b=
enefits as if no one develops anything in advance =A0most users might not f=
ind the theoretical possibilities worth the risk, thus permanently hobbling=
 the full potential of satoshis idea. Rather if testnet were allowed to act=
 as an alt coin something cool might be developed that the main net users m=
ight desire enough to overcome the inertia of the status quo.=A0</div>

<div><br></div><div>Additionally it should be considered that the time in t=
he future when non standard transactions might be enabled =A0might be so fa=
r in the future when bitcoin has hit mass adoption and changing anything mi=
ght require far more political negotiations between users and devs then cur=
rently. Meaning that perhaps much more proof of functionality and value as =
well as testing might e required.=A0</div>

<div><br></div><div>Dennison</div><div><br>Sent from my iPhone</div><div><d=
iv class=3D"h5"><div><br>On Jun 15, 2013, at 1:18 PM, Melvin Carvalho &lt;<=
a href=3D"mailto:melvincarvalho@gmail.com" target=3D"_blank">melvincarvalho=
@gmail.com</a>&gt; wrote:<br>

<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><br><div class=3D=
"gmail_extra"><br><br><div class=3D"gmail_quote">On 19 May 2013 15:23, Adam=
 Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=
=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Is there a way to experiment with new featur=
es - 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? =A0where the coins are the same coins as on bitcoin, the<b=
r>
mining power goes to bitcoin main, so some aspect of merged mining, but no<=
br>
native mining. =A0and 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? =A0Seems vaguely doable and<br>
maybe productive. =A0The 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. =A0I mean a real live system,=
<br>
with live value, but that is intentionally wanting to avoid forking bitcoin=
s<br>
parameters, nor value, nor mindshare dillution. =A0In this way something<br=
>
potentially interesting could move forward faster, and be les risky to the<=
br>
main bitcoin network. =A0eg particularly defenses against<br>
<br>
It might also be a more real world test test (after bitcoin-test) because<b=
r>
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 afte=
r<br>
extensive real-world validation with real-money at stake (by early<br>
adopters).<br></blockquote><div><br></div><div>Interesting idea.=A0 I wonde=
r if ripple could be used to set up a transfer system between the &#39;main=
&#39; and &#39;staging&#39; systems ...<br></div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">



<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 href=3D"http://p.sf.net/sfu/alienvault_d2d" target=3D"_blank">http://p.s=
f.net/sfu/alienvault_d2d</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
</blockquote></div><br></div></div>
</div></blockquote></div></div><div class=3D"im"><blockquote type=3D"cite">=
<div><span>----------------------------------------------------------------=
--------------</span><br><span>This <a href=3D"http://SF.net" target=3D"_bl=
ank">SF.net</a> email is sponsored by Windows:</span><br>

<span></span><br><span>Build for Windows Store.</span><br><span></span><br>=
<span><a href=3D"http://p.sf.net/sfu/windows-dev2dev" target=3D"_blank">htt=
p://p.sf.net/sfu/windows-dev2dev</a></span></div></blockquote></div><blockq=
uote type=3D"cite">

<div><span>_______________________________________________</span><div class=
=3D"im"><br><span>Bitcoin-development mailing list</span><br><span><a href=
=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_blank">Bit=
coin-development@lists.sourceforge.net</a></span><br>

<span><a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-devel=
opment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitc=
oin-development</a></span><br></div></div></blockquote></div></blockquote>
</div>
<br><br clear=3D"all"><div><br></div>-- <br>







<p>Dennison Bertram, photographer and film maker</p>
<p><a href=3D"http://www.dennisonbertram.com" target=3D"_blank">www.denniso=
nbertram.com</a></p>
<p><a href=3D"mailto:dennison@dennisonbertram.com" target=3D"_blank">dennis=
on@dennisonbertram.com</a></p>
<p>Milan:=A0+39 320 781 0128</p><br>
</div>

--047d7b3a82d413391304df476422--