From: Btc Drak <btcdrak@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Date: Tue, 1 Sep 2015 23:56:32 +0100 [thread overview]
Message-ID: <CADJgMzuNzO+J7yEUwdEq7jZV=GBhEp65LZp+_vDEdpxzmkNx6Q@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDqNQEcm5CWE8Rb0p1NGk=9bzjeSh6DD84=qvJ9kk+uFYw@mail.gmail.com>
On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>> Some altcoins (LTC and FTC for example) have the same genesis block hash.
>
> That's obviously a design mistake in FTC, but it's not unsolvable. FTC could
> move their genesis block to the next block (or the first one that is not
> identical to LTC's).
>
> Bitcoin and all its test chains have different genesis blocks, so I'm not
> sure FTC should be a concern for a BIP anyway...
That's a very sweeping generalisation indeed. Why should two chains
have to have a separate genesis? It's cleaner, but it's certainly not
a necessity. You cant exclude this case just because it doesn't fit
your concept of neat and tidy. Other BIP proposals that account for
alternative chains do not rely on the genesis hash, but instead an
identifier. Why should it be any different here? How would you account
for a world with XTCoin and Bitcoin which would also share the same
genesis hash, but clearly not be the same coin.
When I brought up the issue originally, I deliberately steered away
from altchains choosing to focus on networks like mainnet, testnet
because I think it's easier to repurpose a protocol for an altcoin
than it is to make the proposal work for all cases. Take the payment
protocol for example. The BIP specifies a URI with bitcoin: well it's
just as easy to repurpose that for litecoin: etc than adding something
like ?cointype=litecoin, so that was my reason for not mentioning
altcoins at all.
If the proposal is made to account for altcoins, genesis hash is
definitely not desirable, or at least not genesis hash in isolation,
and if that's the case, better to have an identifier.
next prev parent reply other threads:[~2015-09-01 22:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-29 11:48 Marco Pontello
2015-08-29 16:31 ` Richard Moore
2015-08-29 17:19 ` Matt Whitlock
2015-08-29 19:24 ` Richard Moore
2015-08-29 18:07 ` Andreas Schildbach
2015-09-01 14:33 ` Marco Pontello
2015-08-29 18:58 ` Btc Drak
2015-08-29 19:01 ` Matt Whitlock
2015-08-29 20:10 ` Jorge Timón
2015-08-30 2:02 ` Chun Wang
2015-08-30 2:20 ` Jorge Timón
2015-09-01 22:56 ` Btc Drak [this message]
2015-09-01 14:49 ` Marco Pontello
2015-09-01 21:16 ` Matt Whitlock
2015-09-01 21:25 ` Esteban Ordano
2015-09-01 21:38 ` Marco Pontello
2015-09-01 21:42 ` Matt Whitlock
2015-09-01 21:43 ` Marco Pontello
2015-09-01 22:46 ` Jorge Timón
2015-09-01 23:25 ` Matt Whitlock
2015-09-01 16:12 ` Danny Thorpe
2015-09-01 22:59 ` Btc Drak
2015-09-01 23:57 ` Jorge Timón
2015-08-29 19:28 ` Richard Moore
2015-09-01 14:51 ` Marco Pontello
2015-11-15 2:14 ` Marco Pontello
2015-11-15 11:42 ` Jorge Timón
2015-11-16 0:59 ` Marco Pontello
2015-11-16 14:43 ` Jorge Timón
2015-11-16 22:10 ` Marco Pontello
2015-11-18 11:29 ` Jorge Timón
2015-11-18 12:31 ` Marco Pontello
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='CADJgMzuNzO+J7yEUwdEq7jZV=GBhEp65LZp+_vDEdpxzmkNx6Q@mail.gmail.com' \
--to=btcdrak@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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