From: "Jorge Timón" <jtimon@jtimon•cc>
To: Matt Whitlock <bip@mattwhitlock•name>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Date: Wed, 2 Sep 2015 00:46:46 +0200 [thread overview]
Message-ID: <CABm2gDrhh1cSJAVwBQ4meKyjzp4EU_U0feJHJPd=qoC7iojeAw@mail.gmail.com> (raw)
In-Reply-To: <5546682.RnG4VcateO@crushinator>
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ón
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>
>> I would really prefer chain=<chainID> over network=<chainPetnameStr>
>> By chainID I mean the hash of the genesis block, see
>>
>> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
>> 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 way
> 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 spare
> a source lookup just to write a correct reference to a tx, maybe in a forum
> or a post.
>
> So a reference to a certain tx could be either:
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
I'm fine with each explorer using whatever chain they prefer as default.
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
>
> (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> wrote:
> 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/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
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": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206"}
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 bytes
> 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
next prev parent reply other threads:[~2015-09-01 22:46 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
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 [this message]
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='CABm2gDrhh1cSJAVwBQ4meKyjzp4EU_U0feJHJPd=qoC7iojeAw@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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