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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YaNcy-0004rr-9R
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Mar 2015 12:08:12 +0000
Received: from mail-wi0-f178.google.com ([209.85.212.178])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YaNcw-0006RI-7E
for bitcoin-development@lists.sourceforge.net;
Tue, 24 Mar 2015 12:08:12 +0000
Received: by wibg7 with SMTP id g7so72851608wib.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 24 Mar 2015 05:08:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=e5kfsxENEzYKgbOm5dN1G/ApKiLMkpKnrlLEXWEqnyU=;
b=dzbwZPGo1brQBLpUB87b0Z5hiZUT5GO7aTQ9vcWS8bRQ+yhvU4h59m8O1vdQQdiO6s
kXf6qqlJ88DhQBAXt5th8G81F1CAflim1VJcCDxvCkyDZsE/9Yb0APwVYhl0SLXPS6qM
Pm6PSYvAfOdMRJTxSXbB4MXXhLpR+iOEvWyzhIbLIsAWc1cuy2f1/2Q/fRjhRS8QOxSt
RbVPkhPYpwrfqup/Ug5+8cDpFtu4kPggBbSTMxLBezcI0Rv4dkdcimiXnI1XoNTwMndx
RLP3JtapsbWrHtAB3BUENhyBUqzo/hxDVEr79oAsQj7YEkyvwp1P2i7ij9fVm5uLuC9C
CqGQ==
X-Gm-Message-State: ALoCoQkSCfOxa/dLFwNuWIAAHMZHEthxSz+kvxRBg4jpeNmcSSmf3CqRicPT3+V0zIdUU5g0CTKb
MIME-Version: 1.0
X-Received: by 10.194.92.97 with SMTP id cl1mr7236858wjb.133.1427198883981;
Tue, 24 Mar 2015 05:08:03 -0700 (PDT)
Received: by 10.194.13.202 with HTTP; Tue, 24 Mar 2015 05:08:03 -0700 (PDT)
X-Originating-IP: [95.131.169.238]
Received: by 10.194.13.202 with HTTP; Tue, 24 Mar 2015 05:08:03 -0700 (PDT)
In-Reply-To: <20150314155844.27EE5E37EC3@quidecco.de>
References: <54BD7024.5070008@jrn.me.uk>
<CANEZrP3ZdFcQsP+EWgTYQDccFZbrZFTk+xi-YdWPCJzMRH79pA@mail.gmail.com>
<20150124131934.C9E6FE2A9B0@quidecco.de>
<54C57559.3090205@jrn.me.uk>
<20150314155844.27EE5E37EC3@quidecco.de>
Date: Tue, 24 Mar 2015 13:08:03 +0100
Message-ID: <CABm2gDo3VJ0Ss8ySw=e25X_e6bJWAu86S_NG7LBJy6VS5eVhJQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=047d7bfd062a80ffa3051207a238
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: 1YaNcw-0006RI-7E
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
encoding?
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: Tue, 24 Mar 2015 12:08:12 -0000
--047d7bfd062a80ffa3051207a238
Content-Type: text/plain; charset=UTF-8
That case is very unlikely IMO, but still you can solve it while keeping
hash of the genesis block as the chain id. If a community decides to accept
a forking chain with new rules from block N (let's call it bitcoinB), the
original chain can maintain the original genesis block and the new
community can define N (which is not accepted by bitcoin due to the new
rules) as the genesis block for bitcoinB for the purposes of chain ID. As
said forking bitcoins and bitcoinsB with the same owners doesn't make much
sense to me. If you're creating a new currency you can just as well define
a new chain. If you want to start an initial utxo giving the new coins to
bitcoin holders...I still don't see the point, but you can also do that in
a new chain.
In summary, your example is not a good reason not to adopt a hash of the
genesis block as chain ID.
On Mar 14, 2015 5:22 PM, "Isidor Zeuner" <cryptocurrencies@quidecco.de>
wrote:
> > That was essentially what we did in the end, we replaced the network
> > identifier ("main"/"test") with the genesis block hash. The result is
> > never going to accidentally work with Bitcoin Core (nor vice-versa), but
> > is readily extensible to any other altcoins that want to use the
> > specification without requiring any sort of central registry.
> >
>
> Interesting approach, and I also think that requiring a central
> registry would be potentially harmful.
>
> However, I think it might not be adequate to think of the network
> identifier as being congruent with the genesis block hash. In the
> theoretical case of the blockchain being continued on two forked
> chains (with two communities which prefer one of the chains each),
> clients would not be prevented from interpreting messages on the wrong
> chain.
>
> Best regards,
>
> Isidor
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--047d7bfd062a80ffa3051207a238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">That case is very unlikely IMO, but still you can solve it w=
hile keeping hash of the genesis block as the chain id. If a community deci=
des to accept a forking chain with new rules from block N (let's call i=
t bitcoinB), the original chain can maintain the original genesis block and=
the new community can define N (which is not accepted by bitcoin due to th=
e new rules) as the genesis block for bitcoinB for the purposes of chain ID=
. As said forking bitcoins and=C2=A0 bitcoinsB with the same owners doesn&#=
39;t make much sense to me. If you're creating a new currency you can j=
ust as well define a new chain. If you want to start an initial utxo giving=
the new coins to bitcoin holders...I still don't see the point, but yo=
u can also do that in a new chain.</p>
<p dir=3D"ltr">In summary, your example is not a good reason not to adopt a=
hash of the genesis block as chain ID.</p>
<div class=3D"gmail_quote">On Mar 14, 2015 5:22 PM, "Isidor Zeuner&quo=
t; <<a href=3D"mailto:cryptocurrencies@quidecco.de">cryptocurrencies@qui=
decco.de</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">> That was essentially what we did in the end, we replaced the netwo=
rk<br>
> identifier ("main"/"test") with the genesis block =
hash. The result is<br>
> never going to accidentally work with Bitcoin Core (nor vice-versa), b=
ut<br>
> is readily extensible to any other altcoins that want to use the<br>
> specification without requiring any sort of central registry.<br>
><br>
<br>
Interesting approach, and I also think that requiring a central<br>
registry would be potentially harmful.<br>
<br>
However, I think it might not be adequate to think of the network<br>
identifier as being congruent with the genesis block hash. In the<br>
theoretical case of the blockchain being continued on two forked<br>
chains (with two communities which prefer one of the chains each),<br>
clients would not be prevented from interpreting messages on the wrong<br>
chain.<br>
<br>
Best regards,<br>
<br>
Isidor<br>
<br>
---------------------------------------------------------------------------=
---<br>
Dive into the World of Parallel Programming The Go Parallel Website, sponso=
red<br>
by Intel and developed in partnership with Slashdot Media, is your hub for =
all<br>
things parallel software development, from weekly thought leadership blogs =
to<br>
news, videos, case studies, tutorials and more. Take a look and join the<br=
>
conversation now. <a href=3D"http://goparallel.sourceforge.net/" target=3D"=
_blank">http://goparallel.sourceforge.net/</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>
</blockquote></div>
--047d7bfd062a80ffa3051207a238--
|
