On Tue, Sep 1, 2015 at 4:49 PM, Marco Pontello <marco...@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 <b...@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.tho...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
