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
|
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 <adam.back@gmail.com>) id 1VVmZ0-0003KX-G5
for bitcoin-development@lists.sourceforge.net;
Mon, 14 Oct 2013 18:08:18 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.173 as permitted sender)
client-ip=209.85.215.173; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f173.google.com;
Received: from mail-ea0-f173.google.com ([209.85.215.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VVmYz-0001XB-6Q
for bitcoin-development@lists.sourceforge.net;
Mon, 14 Oct 2013 18:08:18 +0000
Received: by mail-ea0-f173.google.com with SMTP id g10so3572348eak.4
for <bitcoin-development@lists.sourceforge.net>;
Mon, 14 Oct 2013 11:08:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=tTGZbjFpavEBN3Dm0JuXENtxkpIgRUifGNBpuAb/svQ=;
b=bu195YTwywBqobDfo5iDuMc3Pt0/T4W6P/Hh0r9esyFI362C9UIB3zmEXEGDgjorCz
2sB11WP4G0VtLGwsg9oNJ/Bhzoo0YjXL0yDcT7n5Db6A0zjxF+9mCXfh48riqVzwRsvx
f7Y+oIh0ytvlp4wBLRKtZk546CFVRtTYOqJrganol0fqJD8b+ZVOtTxoYzzIHSXQjago
q2kWVp2IV//TZRwGV11uYHI67EdMzbILbMjv3yI8eP46VgclXPeguyVyX6Ap1VQDoVTc
gWwj9GYUuAtrm7R68Vqilzu0gcPFQCQIJAhl2g26jCOuSOknixCfhsnMBttzqhWoepCU
6Npw==
X-Received: by 10.14.214.136 with SMTP id c8mr57449984eep.6.1381774090854;
Mon, 14 Oct 2013 11:08:10 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
b45sm156213970eef.4.1969.12.31.16.00.00
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 14 Oct 2013 11:08:10 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id E616C2E0B63; Mon, 14 Oct 2013 20:08:08 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Mon, 14 Oct 2013 20:08:07 +0200
Date: Mon, 14 Oct 2013 20:08:07 +0200
From: Adam Back <adam@cypherspace.org>
To: Alan Reiner <etotheipi@gmail.com>
Message-ID: <20131014180807.GA32082@netbook.cypherspace.org>
References: <20130519132359.GA12366@netbook.cypherspace.org>
<CAMGNxUsGRyYWepSn4on+V9CJAj0J8oSXndo36OrrCyMhvKnoxA@mail.gmail.com>
<5199C3DE.901@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <5199C3DE.901@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:131014:etotheipi@gmail.com::JsyhncP/H8Aum4Nc:000000000000000000
0000000000000000000000000iM+
X-Hashcash: 1:20:131014:bitcoin-development@lists.sourceforge.net::LSlN6z1RFJXUK
erm:000000000000000000000Ale
X-Hashcash: 1:20:131014:peter@coinlab.com::qFokguuQhJ1U3Ps0:00000000000000000000
0000000000000000000000003I/h
X-Hashcash: 1:20:131014:adam@cypherspace.org::vIF9+FOe8R2htPHb:00000000000000000
0000000000000000000000007Sla
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VVmYz-0001XB-6Q
Cc: 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: Mon, 14 Oct 2013 18:08:18 -0000
Coming back to the staging idea, maybe this is a realistic model that could
work. The objective being to provide a way for bitcoin to move to a live
beta and stable being worked on in parallel like fedora vs RHEL or odd/even
linux kernel versions.
Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
stable and leap-frogs as beta becomes stable after testing.
Its a live beta, meaning real value, real contracts. But we dont want it to
be an alt-coin with a floating value exactly, we want it to be bitcoin, but
the bleeding edge bitcoin so we want to respect the 21 million coin limit,
and allow coins to move between bitcoin and betacoin with some necessary
security related restrictions.
There is no mining reward on the betacoin network (can be merge mined for
security), and the way you opt to move a bitcoin into the betacoin network
is to mark it as transferred in some UTXO recognized way. It cant be
reanimated, its dead. (eg spend to a specific recognized invalid address on
the bitcoin network). In this way its not really a destruction, but a move,
moving the coin from bitcoin to betacoin network.
This respects the 21 million coin cap, and avoids betacoin bugs flowing back
and affecting bitcoin security or value-store properties. Users may buy or
swap betacoin for bitcoin to facilitate moving money back from betacoin to
bitcoin. However that is market priced so the bitcoin network is security
insulated from beta. A significant security bug in beta would cause a
market freeze, until it is rectified.
The cost of a betacoin is capped at one BTC because no one will pay more
than one bitcoin for a betacoin because they could alternatively move their
own coin. The reverse is market priced.
Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
decision is reached to promote 1.0 beta to 2.0 stable, the remaining
bitcoins can be moved, and the old network switched off, with mining past a
flag day moving to the betacoin.
During the beta period betacoin is NOT an alpha, people can rely on it and
use it in anger for real value transactions. eg if it enables more script
features, or coin coloring, scalabity tweaks etc people can use it.
Probably for large value store they are always going to prefer
bitcoin-stable, but applications that need the coloring features, or
advanced scripting etc can go ahead and beta.
Bitcoin-stable may pull validated changes and merge them, as a way to pull
in any features needed in the shorter term and benefit from the betacoin
validation. (Testing isnt as much validation as real-money at stake
survivability).
The arguments are I think that:
- it allows faster development allowing bitcoin to progress features faster,
- it avoids mindshare dilution if alternatively an alt-coin with a hit
missing feature takes off;
- it concentrates such useful-feature alt activities into one OPEN source
and OPEN control foundation mediated area (rather than suspected land
grabs on colored fees or such like bitcoin respun as a business model
things),
- maybe gets the developers that would've been working on their pet
alt-coin, or their startup alt-coin to work together putting more
developers, testers and resources onto something with open control (open
source does not necessarily mean that much) and bitcoin mindshare
branding, its STILL bitcoin, its just the beta network.
- it respects the 21 million limit, starting new mining races probably
dillutes the artificial scarcity semantic
- while insulating bitcoin from betacoin security defects (I dont mean
betacoin as a testnet, it should have prudent rigorous testing like
bitcoin, just the very act of adding a feature creates risk that bitcoin
stable can be hesitant to take).
Probably the main issue as always is more (trustable) very high caliber
testers and developers. Maybe if the alt-coin minded startups and
developers donate their time to bitcoin-beta (or bitcoin-stable) for the
bits they are missing, we'll get more hands to work on something of reusable
value to humanity, in parallel with their startup's objectives and as a way
for them to get their needed features, while giving back to the bitcoin
community, and helping bitcoin progress faster.
Maybe bitcoin foundation could ask for BTC donations to hire more developers
and testers full time. $1.5b of stored value should be interested to safe
guard their value store, and develop the transaction features.
Adam
On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> This is exactly what I was planning to do with the
> inappropriately-named "Ultimate Blockchain Compression". [...]
>
> 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".
> 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.
|
