Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YWopO-0005F4-Hk for bitcoin-development@lists.sourceforge.net; Sat, 14 Mar 2015 16:22:18 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YWopM-0007J5-Cg for bitcoin-development@lists.sourceforge.net; Sat, 14 Mar 2015 16:22:18 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 27EE5E37EC3; Sat, 14 Mar 2015 16:58:44 +0100 (CET) From: Isidor Zeuner To: Ross Nicoll Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252; format=flowed References: <54C57559.3090205@jrn.me.uk> <54BD7024.5070008@jrn.me.uk> <20150124131934.C9E6FE2A9B0@quidecco.de> In-Reply-To: <54C57559.3090205@jrn.me.uk> Message-Id: <20150314155844.27EE5E37EC3@quidecco.de> Date: Sat, 14 Mar 2015 16:58:44 +0100 (CET) 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1YWopM-0007J5-Cg Cc: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:22:18 -0000 > 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