Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7617C1012 for ; 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 ; Tue, 1 Sep 2015 22:46:48 +0000 (UTC) Received: by wicge5 with SMTP id ge5so22089543wic.0 for ; 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:

<5546682.RnG4VcateO@crushinator> Date: Wed, 2 Sep 2015 00:46:46 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Matt Whitlock 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 22:46:49 -0000 On Tue, Sep 1, 2015 at 4:49 PM, Marco Pontello wrote: > > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Tim=C3=B3n > wrote: >> >> >> I would really prefer chain=3D over network=3D >> 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 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::max() new chains. On Tue, Sep 1, 2015 at 6:12 PM, Danny Thorpe 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::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::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