[Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

Jorge Timón jtimon at jtimon.cc
Tue Mar 24 12:08:03 UTC 2015


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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150324/2236724b/attachment.html>


More information about the bitcoin-dev mailing list