Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CCAE13ED for ; Tue, 1 Sep 2015 16:12:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1544524E for ; Tue, 1 Sep 2015 16:12:43 +0000 (UTC) Received: by oibi136 with SMTP id i136so2400477oib.3 for ; Tue, 01 Sep 2015 09:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LmkJTIsflZLHQwbwkWn8P0lhwVQ8gUGst5XKXP2Qlc=; b=RjQn7++ePO5dZgkRr/hJgDrbrgVCULne0k3QGfTekVVRS/MbHpfT3gyTFKChYTC+HF NakkEleZGIBCOvi3uZWg2bBWuX9iQ9TDGenbchjP7VrEsQGMtcFhz9/GiiOY+POzINcH LZ3yshs/Q8314pV0IL0vquJwJTN8cSpbZzqL39aBx5w1Xn+tczzMluLwMZ5mJ+YYkX8I 0D/XN6rSPooOV9a4goed1iy8r9JUqbZ6wXN9O6ZZttOwuZ35gCvtvsebLR2ZRoY5aKiS xy0uhOs1hgsOv09j9NjfJNGz3I+fD79OfhkPuENoJSv6mdChtDh7ZZel2IV1uWKyxGoI n8tw== MIME-Version: 1.0 X-Received: by 10.202.243.136 with SMTP id r130mr17060713oih.39.1441123962432; Tue, 01 Sep 2015 09:12:42 -0700 (PDT) Received: by 10.202.204.22 with HTTP; Tue, 1 Sep 2015 09:12:42 -0700 (PDT) In-Reply-To: References: <2509151.XgrrNGsCxR@crushinator> Date: Tue, 1 Sep 2015 09:12:42 -0700 Message-ID: From: Danny Thorpe To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=94eb2c0944e0dbb833051eb1d1c6 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 16:12:44 -0000 --94eb2c0944e0dbb833051eb1d1c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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. -Danny On Sat, Aug 29, 2015 at 1:10 PM, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev > wrote: > > That's still not right, since "mainnet" and "testnet" are not host name= s. > > > > You'd have to do something like: > > > > > blockchain:?network=3Dtestnet&txid=3D3b95a766d7a99b87188d6875c8484cb2b310= b78459b7816d4dfc3f0f7e04281a > > 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/3191d5e8e75687a27cf466b7a4c70bdc= 04809d39 > I'm completely fine with doing that using an optional parameter (for > backwards compatibility). > > I agree with Andreas Schildbach that respecting the most commonly used > schemes is desirable. > So my preference would be: > > > /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chai= n=3D000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 > > (a tx in testnet) > > > /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?c= hain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > (a block in bitcoin's mainnet) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c0944e0dbb833051eb1d1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rather than using an inhumanly long hex string from the ge= nesis hash to distinguish between mainnet and testnet, why not use the netw= ork magic bytes instead? Much shorter, just as distinct.

I'd still prefer a common network name mapping for the sake of humanit= y. Few bitcoin library implementations use the same string names for mainne= t and testnet. This BIP could simply define one string name alias for each = supported network and leave mapping to local lingo to the implementors.

-Danny

On Sat, Aug 29, 2015 at 1:10 PM, Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
On Sat, Aug 29, 201= 5 at 9:01 PM, Matt Whitlock via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> That's still not right, since "mainnet" and "testne= t" are not host names.
>
> You'd have to do something like:
>
> blockchain:?network=3Dtestnet&txid=3D3b95a766d7a99b87188d6875c8484= cb2b310b78459b7816d4dfc3f0f7e04281a

I would really prefer chain=3D<chainID> over network=3D<cha= inPetnameStr>
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 agree with Andreas Schildbach that respecting the most commonly used
schemes is desirable.
So my preference would be:

/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain= =3D000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943

(a tx in testnet)

/block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?cha= in=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

(a block in bitcoin's mainnet)
___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--94eb2c0944e0dbb833051eb1d1c6--