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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1Un7ki-0004ML-5o
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Jun 2013 13:39:48 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.176 as permitted sender)
client-ip=209.85.215.176; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f176.google.com;
Received: from mail-ea0-f176.google.com ([209.85.215.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Un7kg-00017M-MS
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Jun 2013 13:39:48 +0000
Received: by mail-ea0-f176.google.com with SMTP id z15so4683791ead.21
for <bitcoin-development@lists.sourceforge.net>;
Thu, 13 Jun 2013 06:39:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent:x-hashcash
:x-hashcash;
bh=AHquSphSYtHVb0PiyksWNO+kzmYLd+zDZWza/hYTY1I=;
b=h/l4jSF7fJc0N4cvPvtQxucDITp1BMnS8InujC1ki/Y+RGMiTbD1+60+Gz74jKyK9z
CTPn1H0qApBADsZywJ6lhNmYe+fCstE3kdODT80Fc8EEzFimKQ8ZTIQR0NmIxZ0objcR
cXpVYQtGN7CAeYLlyk/oir1DweUPfQaBLQBBW+TSIcNV+tY/A90U5IrYFrERch7zbYFF
WuT97n1X17KSripYqyl57voINdIk8LC94POpJKevcb0IkafHh4hg3oABU0cGAMsK4PLO
hLENTVUS5GQIO62Kg0Zg6GR0dbbmGrQX4plcb/vzc9+wZpipA5qRyfvUMiUKDvjoNFxu
AUOQ==
X-Received: by 10.15.23.73 with SMTP id g49mr1391951eeu.8.1371130780279;
Thu, 13 Jun 2013 06:39:40 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
y44sm43849112eel.10.2013.06.13.06.39.37
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 13 Jun 2013 06:39:39 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id A3F2C2E03ED; Thu, 13 Jun 2013 15:39:35 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Thu, 13 Jun 2013 15:39:32 +0200
Date: Thu, 13 Jun 2013 15:39:32 +0200
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130613133932.GA13028@netbook.cypherspace.org>
References: <20130519132359.GA12366@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130519132359.GA12366@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130613:bitcoin-development@lists.sourceforge.net::GQXAUyZlV2WP8
QhT:000000000000000000009Vax
X-Hashcash: 1:20:130613:adam@cypherspace.org::pIPdsnLEDZLCL218:00000000000000000
000000000000000000000000BQuB
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: 1Un7kg-00017M-MS
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: Thu, 13 Jun 2013 13:39:48 -0000
I had one thought towards this which is a different kind of merged mining.
I think a "fair" merged mining aiming for price parity would be done by the
miner having to choose the altcoin or btc at mine time, and altcoin chain
considering btc mine unspendable and bitcoin considering ac unspendable.
In terms of validation which miners are currently doing to help SVP clients,
it implies verification of both chains. Or more incrementally each mine
should indicate in its serialization which chain it has validated. This wa
about a hypothethical pure zerocoin altcoin hence zc/zerocoin:
Maybe we can say that a mergemine does not count as a validation of the
network for the respective network unless there is serialization in the
coinbase indicating that the network is validated. In that way you could
have zerocoin mined and zerocoin validated, zero mined and bitcoin validated
(strange but possible), zerocoin mined and both zero and bit coin validated,
and also the same for bitcoin mined and zerocoin validated (strange but
possible), bitcoin mined and bitcoin validated (normal bitcoin ignoring
zerocoin) and bitcoin mined and bitcoin and zerocoin validated. Then the
validation events on zerocoin network might not be as frequent. Maybe
miners will tend to validate both networks as then they can claim fees on
both networks, even if the protocol prevents direct merged mining on both
networks (one or the other mined, and whatever chains validated as indicated
by coinbase serialization).
(I described it in this thread
https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768 which
is mostly about understanding zerocoin, but digressed at that point to a
hypothetical pure zerocoin alt-coin that retains a fair merged mine and
exchangeless tradeability with main bitcoin.)
I think another gap is the exchangeless tradeability. Apparently the
contract based proposals have race conditions, and ransom issues (refuse to
complete agreed commitment phase without being part-paid again). I didnt
follow that discussion yet but Greg Maxwell and Sergio Lerner were
discussing and that seemed to be their conclusion, and Sergio's proposed
solution relied on a non-standard and not-fully-worked-through assumption
for the alt-coin (probably non-SPV compatible I think).
ps I thought it was quite interesting that seemingly you could make a pure
zerocoin alt-coin, it turns out you could direct mine them, and do zc-zc
transactions.
They are fixed denomination however I think you could extend them with
homomorphic amounts. I noticed Matthew Green mentioned this idea in his
presentation at microsoft research (saw in the video they have put online).
From my perspective (he didnt specify how other than as an attribute) its
something like a Brands credential where you can prove in ZK that two
attributes sum to a given value without revealing the attributes at all.
The missing last part is you have to prove that the attributes are less than
some threshold to avoid people cheating and adding q to their balance.
(Arithmetic in the exponents is modulo q in the subgroup used in zerocoin).
There are several approaches to doing this some of them not that cheap (eg
involving k DSA-like signatures to prove vale v < 2^k). The idea of proving
it is less than k where k is say 128 is that then to add q, you have to
spend 2^128 coins which you cant do. You can either make the values
uncertain by having v eg have 44 bits of useful precision and a few binary
00s and then 80-bits of randomness, or you can use a second never disclosed
random attribute like in a Pederson commitment or Brands credential eg
c=g^v h^r mod p where r is random and never disclosed, but the user proves
knowledge of discrete log representation of c in terms of powers of g and h.
The downside of k signatures is validation CPU cost, and worse transaction
size.
There are several other approaches which seem to be able to prove v < 2^k
with less than k, eg even 1 DSA-like signature. I need to gather that info
in one place and write something referencing the literature I found so far.
A homomorphically verifiable coin balance transfer could be interesting
outside of zerocoin - eg for bitcoin, or an alt-coin.
Adam
On Sun, May 19, 2013 at 03:23:59PM +0200, Adam Back 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
|
