From: "Jorge Timón" <jtimon@jtimon.cc>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Tue, 24 Mar 2015 13:08:03 +0100 [thread overview]
Message-ID: <CABm2gDo3VJ0Ss8ySw=e25X_e6bJWAu86S_NG7LBJy6VS5eVhJQ@mail.gmail.com> (raw)
In-Reply-To: <20150314155844.27EE5E37EC3@quidecco.de>
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3084 bytes --]
next prev parent reply other threads:[~2015-03-24 12:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 19:07 [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16 ` Richard Brady
2015-01-19 19:34 ` Jeff Garzik
2015-01-19 19:48 ` Peter Todd
2015-01-19 19:57 ` Richard Brady
2015-01-19 20:03 ` Alan Reiner
2015-01-19 20:06 ` Peter Todd
2015-01-19 20:40 ` Mike Hearn
2015-01-19 20:56 ` Gavin Andresen
2015-01-19 21:22 ` Brian Hoffman
2015-01-19 20:59 ` Ross Nicoll
2015-01-24 13:19 ` Isidor Zeuner
2015-01-25 22:59 ` Ross Nicoll
2015-03-14 15:58 ` Isidor Zeuner
2015-03-24 12:08 ` Jorge Timón [this message]
2015-01-19 21:21 ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37 ` Mike Hearn
2015-01-19 19:38 ` Jeff Garzik
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER
2015-01-28 15:42 ` Mike Hearn
2015-01-28 16:04 ` Jeff Garzik
2015-01-28 16:52 ` Nicolas DORIER
2015-01-28 17:29 ` Jeff Garzik
2015-01-28 17:45 ` Mike Hearn
2015-01-28 16:19 ` Giuseppe Mazzotta
2015-01-28 16:51 ` Matt Whitlock
2015-01-28 17:02 ` Mike Hearn
2015-01-28 16:34 ` Nicolas DORIER
2015-01-28 16:55 ` Mike Hearn
2015-01-28 17:04 ` Nicolas Dorier
2015-01-28 17:14 ` Mike Hearn
2015-01-28 17:17 ` Angel Leon
2015-01-28 17:27 ` Nicolas DORIER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABm2gDo3VJ0Ss8ySw=e25X_e6bJWAu86S_NG7LBJy6VS5eVhJQ@mail.gmail.com' \
--to=jtimon@jtimon.cc \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=cryptocurrencies@quidecco.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox