From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <20150124131934.C9E6FE2A9B0@quidecco.de> <54C57559.3090205@jrn.me.uk> <20150314155844.27EE5E37EC3@quidecco.de> Date: Tue, 24 Mar 2015 13:08:03 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Isidor Zeuner 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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

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.

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&quo= t; <cryptocurrencies@qui= decco.de> wrote:
> That was essentially what we did in the end, we replaced the netwo= rk
> identifier ("main"/"test") with the genesis block = hash. The result is
> never going to accidentally work with Bitcoin Core (nor vice-versa), b= ut
> 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, sponso= red
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7bfd062a80ffa3051207a238--