1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EB9B1398
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 23:57:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 410C8177
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 23:57:18 +0000 (UTC)
Received: by wibz8 with SMTP id z8so48100286wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 16:57:17 -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
:content-transfer-encoding;
bh=/lBeptb8hCoarJiAOhhlJJyzYTkWw1ahx+yRakHRk9w=;
b=GNWVWmpBQnosX6F2APZ1qmbmawCwgpnrxqSPqO6k3JQw7Y3yN2+VIHIjK8m6kOy0ng
5bajT+i5fn6PM1BZBvxSTrWT4rLxNgxBZ/BYosO1wo8wtQqv4r8tHl6is4Lw0IUU3QUx
XoUusQ4iyf3/iE7Emp3hudIy/9SpWej4xLqYqB16YNFQ7JUEwd95H5DYZo4xlAUpEbcG
/tjLo6qVuZGcVqvlttWnfBMJHaUe9RuCS7Lxyrf+DIygnMusNkHxWMTQZw6S0Zb9Bsob
QTvSGiTlqid194IU4M3Z8x/N8xYuyDbeecTp6sEqysdL+Mgq/jUTFP5oF44yX1dx/irf
d3Xw==
X-Gm-Message-State: ALoCoQmhiBZY9rgw2oGguSKbpjyvWnCCCI1TVnJZ8TuBJIrCIfUy8i44UNeExmYBSwV4Cq0pspzH
MIME-Version: 1.0
X-Received: by 10.194.122.97 with SMTP id lr1mr36229939wjb.26.1441151836870;
Tue, 01 Sep 2015 16:57:16 -0700 (PDT)
Received: by 10.194.234.197 with HTTP; Tue, 1 Sep 2015 16:57:16 -0700 (PDT)
In-Reply-To: <CADJgMzuK6YpLyFQ1BnHuWi4GyoqOgnuaA7T3odukpB=Hh3pTgQ@mail.gmail.com>
References: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
<CF21152C-15FA-421C-B369-A9A7DB59865F@ricmoo.com>
<CADJgMztaJHDrz0+7KLouwZMCz--Za6-2pitmjjYVHG+nJjrG=Q@mail.gmail.com>
<2509151.XgrrNGsCxR@crushinator>
<CABm2gDpC55dsr4GNAUabgnOeXcNTrgHSAtM7Jqfp0_QUfjXmoQ@mail.gmail.com>
<CAJN5wHVdneuRv6Vpf4q3d=mqwu2HkNeJwFhoqPHFiQcatt4RSg@mail.gmail.com>
<CADJgMzuK6YpLyFQ1BnHuWi4GyoqOgnuaA7T3odukpB=Hh3pTgQ@mail.gmail.com>
Date: Wed, 2 Sep 2015 01:57:16 +0200
Message-ID: <CABm2gDrcZM8TH7__ViSgJ0Sr94SP_Yg4L8SLTqtto5JnCq95ow@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Matt Corallo <bitcoin-list@bluematt.me>
Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 23:57:19 -0000
On Wed, Sep 2, 2015 at 12:56 AM, Btc Drak <btcdrak@gmail.com> wrote:
> 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=3Dlitecoin, 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
I agree. That's why we don't need to account for altchains other than
testchains (ie sidechains and altcoins).
> On Sun, Aug 30, 2015 at 3:20 AM, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> Some altcoins (LTC and FTC for example) have the same genesis block has=
h.
>>
>> That's obviously a design mistake in FTC, but it's not unsolvable. FTC c=
ould
>> 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 no=
t
>> 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?
On Wed, Sep 2, 2015 at 12:59 AM, Btc Drak <btcdrak@gmail.com> wrote:
> The only sane way to me see to have cointype like BIP44.
> See https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#coin-t=
ype
We can do it the right way from now on (and as you say altcoins can
trivially adapt to this).
Sorry for having missed bip44 for review but that section is horrible
in my opinion (see the links above). And it seems to be incompatible
with bip001 which says are immutable once accepted (assuming that
document is expected to be the central registry of registered chains).
> 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.
Schism hardforks are explicitly renouncing to reach consensus with all
previous users. You're intentionally divorcing 2 chains, and you can
do that without confusing users.
In BIP99 the recommended deployment path for a schism fork is to
simply use the nHeight for activation.
The 95% miner's upgrade confirmation is not used here (like in
uncontroversial hardforks and softforks) because you don't necessarily
expect all miners to move to your side of the schism (and you don't
want to wait for them, specially if it's an "anti-miner" hardfork).
To avoid confusing users, you can define a new "genesis block" to use
for the chain ID, for example, 1000 blocks before the activation
height.
The same applies for potentially pre-mined altcoins that haven't had
the decency/competency of even changing the string in pszTimestamp.
For example, FTC, coins generated with coingen (Matt Corallo or the
current owner may want to correct me on this point) or elements alpha
(https://github.com/ElementsProject/elements/blob/alpha/src/chainparams.cpp=
#L115).
Fortunately alpha has a unique chain ID because it was changing both
the block and transaction serialization formats anyway. But hopefully
we will fix that for beta and later sidechains.
All chains that want a unique chain ID can have it retroactively. At
worst, they may need to use the hash of a block that is not the
genesis block.
In other words, they may need to move their "genesis checkpoint" upwards.
Terminology may make things more clear. We can replace:
"The chain ID is the hash of the genesis block"
with
"The chain ID is the hash of the genesis checkpoint".
If we want a unique chain ID we can have it: it just cannot be
memorable at the same time.
And each chain and implementation can start using them (in addition to
petname -> chain ID local dictionaries) at any point in time: this is
retroactively (and obviously forwards) compatible.
There can be many competing registries for the name -> chainID
dictionaries (maybe one of them based on namecoin?) but bitcoin/bips
shouldn't maintain one.
|
