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
165
|
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 7617C1012
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 22:46:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 465931BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Sep 2015 22:46:48 +0000 (UTC)
Received: by wicge5 with SMTP id ge5so22089543wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Sep 2015 15:46:47 -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=1/DFTuG3PTgy/jjXRtZ95+AK8251evJJlT3UOUmkrdY=;
b=fEV5wjHuVvDAtNDd+RSCpSsniBV4jE1kMlSVNOrFrELzEpN4ReDAEVgZ71oH1Oor+e
ZsbluKVSnfB4HW1BQeCEkOrCmJGvN/Hn1T3SgMf/UhPTLaQnuidI56W4RIvnwvjqAqYg
UvInali+oSiKAtJTPeTYwoudJKyeb2was0Mpylmg1j1YshJZA9dIbioIdRT66zAOUjkb
AKT39f6Kw8E9Us+Q/Mvxy7oxFr0OUUOnaT0CCOtwiZlUPYU2EJViEMGQO4Z6pTn5OJt3
uInvUaJBZJWLyHlzmSM3I9t/jCMxwgInLJA5DGG5IPy+TNLzFJr8cgwVtcyQMNGMUZFP
coGQ==
X-Gm-Message-State: ALoCoQmEmyCCkVYzlYFfOOjdsyHlq1kR7LJ4/LQkA/LzZcckJPkQ/gXIhuVwO0amygFq4RLxSY/A
MIME-Version: 1.0
X-Received: by 10.194.122.97 with SMTP id lr1mr36050845wjb.26.1441147607010;
Tue, 01 Sep 2015 15:46:47 -0700 (PDT)
Received: by 10.194.234.197 with HTTP; Tue, 1 Sep 2015 15:46:46 -0700 (PDT)
In-Reply-To: <5546682.RnG4VcateO@crushinator>
References: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
<CABm2gDpC55dsr4GNAUabgnOeXcNTrgHSAtM7Jqfp0_QUfjXmoQ@mail.gmail.com>
<CAE0pAC+32rhWdBL+WbPANy0rd+eh-XsPQy-u3OHUxS0ku7eN-Q@mail.gmail.com>
<5546682.RnG4VcateO@crushinator>
Date: Wed, 2 Sep 2015 00:46:46 +0200
Message-ID: <CABm2gDrhh1cSJAVwBQ4meKyjzp4EU_U0feJHJPd=qoC7iojeAw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Matt Whitlock <bip@mattwhitlock.name>
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>
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 22:46:49 -0000
On Tue, Sep 1, 2015 at 4:49 PM, Marco Pontello <marcopon@gmail.com> wrote:
>
> On Sat, Aug 29, 2015 at 10:10 PM, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> I would really prefer chain=3D<chainID> over network=3D<chainPetnameStr>
>> By chainID I mean the hash of the genesis block, see
>>
>> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bd=
c04809d39
>> I'm completely fine with doing that using an optional parameter (for
>> backwards compatibility).
>
>
> I see that using the genesis block hash would be the perfectly rigorous w=
ay
> to do it, but what do you think about the possibility of letting also use
> the name constants, as a simple / more relaxed alternative? That would sp=
are
> a source lookup just to write a correct reference to a tx, maybe in a for=
um
> or a post.
>
> So a reference to a certain tx could be either:
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918=
f76c17f
I'm fine with each explorer using whatever chain they prefer as default.
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918=
f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8=
ce26f
>
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76=
c17f?chain=3Dmain
>
> (or a different element name maybe)
It would need to be a different argument, for example chainPetName.
On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock <bip@mattwhitlock.name> wrot=
e:
> And I would agree with allowing well-known chains to register a name, to =
be used as an alternative to the literal, hash syntax:
>
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f2=
4ecd3918f76c17f
But who is the central authority that registers the mnemonic names?
That's why I say petname, because no dictionary of supported chains
should be considered universally accepted and thus it will always be
just a local registry.
If we're chainPetName is supported, there should be an additional call
to query that local list. For example:
blockchain:/chains
JSON response:
{ "main": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f=
",
"test": "000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943=
",
"regtest": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2=
206"}
It may be problematic when too many chains are supported. For example,
#6382 introduces std::numeric_limits<uint64_t>::max() new chains.
On Tue, Sep 1, 2015 at 6:12 PM, Danny Thorpe <danny.thorpe@gmail.com> wrote=
:
> Rather than using an inhumanly long hex string from the genesis hash to
> distinguish between mainnet and testnet, why not use the network magic by=
tes
> instead? Much shorter, just as distinct.
Obviously 4 bytes is not "as distinct" as 32 bytes. In #6382,
std::numeric_limits<uint64_t>::max() new chains share the same magic
bytes.
And again, there's no central authority to register unique magic
bytes. In contrast, producing a unique genesis block is trivial (look
how I produced std::numeric_limits<uint64_t>::max() new unique genesis
blocks in #6382).
> I'd still prefer a common network name mapping for the sake of humanity. =
Few
> bitcoin library implementations use the same string names for mainnet and
> testnet. This BIP could simply define one string name alias for each
> supported network and leave mapping to local lingo to the implementors.
There's many altcoins that call "testnet" to their own testnet. In
Bitcoin itself, we've been using "testnet" to refer to the original
testnet, testnet2 and testnet3.
But again, the main issue is that we don't want a central authority to
register unique unique and memorable chain name strings.
Relevant links:
https://en.wikipedia.org/wiki/Zooko%27s_triangle
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
|
