Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 16FA310D0 for ; Tue, 1 Sep 2015 21:26:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 66A81196 for ; Tue, 1 Sep 2015 21:26:19 +0000 (UTC) Received: by ykdg206 with SMTP id g206so4068465ykd.1 for ; Tue, 01 Sep 2015 14:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UU+OFlHe2e1+exHne5nwFSN3/+s0WXYWFwcZJJAm/70=; b=HO8prrmMJcvGSJvCGOYTymBbaSOaIZRGxaglvUi/9Qug/KUEbkHcMJTJNplruiEPZQ TF1++/CdR+omUbw0n/7M7iS04rORCxBIKuL5JmSrm+5PLMqVyYF/m2T5dMpxhJKT2vMM YvQepBNvTWvBIfaH/A+Te9dfV3rhvhQjSew4Yq4d2ZTHGKIAOh+DOsJE3lB87u/kZdxH HmR82Fz05yDEzSp2JAhTcqL9jn1IjzRMAA4KvTDpjmmVtgslZkFpvQ9HoObAwDaddXPs 3ywRfkct5pN2FwRBZSuPLIjcJ7AhPmHiW5DP8XEhJZvpS9r5W3F1kxtzCygl5Ss2qXnw mJGQ== X-Received: by 10.170.165.197 with SMTP id h188mr611458ykd.45.1441142778578; Tue, 01 Sep 2015 14:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.255.196 with HTTP; Tue, 1 Sep 2015 14:25:59 -0700 (PDT) In-Reply-To: <5546682.RnG4VcateO@crushinator> References: <5546682.RnG4VcateO@crushinator> From: Esteban Ordano Date: Tue, 1 Sep 2015 18:25:59 -0300 Message-ID: To: Matt Whitlock Content-Type: multipart/alternative; boundary=001a113a2fe0634ef4051eb63303 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 21:26:20 -0000 --001a113a2fe0634ef4051eb63303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Slightly relevant: standardization of http queries to blockchain explorers. It's not just about URLs, it's about the query body and response. https://github.com/common-blockchain On Tue, Sep 1, 2015 at 6:16 PM, Matt Whitlock via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Isn't this all backward? The "authority" component of the URL should > identify the chain, and the "path" component should identify the particul= ar > block, tx, or address in that chain. > > So instead of: > > > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918= f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8= ce26f > > It should be: > > > blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8c= e26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f > > 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 > > > On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello 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 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 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 u= se > > 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/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918= f76c17f > > > > > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918= f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8= ce26f > > > > > blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76= c17f?chain=3Dmain > > > > (or a different element name maybe) > > > > -- > > Try the Online TrID File Identifier > > http://mark0.net/onlinetrid.aspx > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113a2fe0634ef4051eb63303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Slightly relevant: standardization of http queries to bloc= kchain explorers. It's not just about URLs, it's about the query bo= dy and response. https://g= ithub.com/common-blockchain

On Tue, Sep 1, 2015 at 6:16 PM, Matt Whitlock via bitco= in-dev <bitcoin-dev@lists.linuxfoundation.org><= /span> wrote:
Isn't this all backward= ? The "authority" component of the URL should identify the chain,= and the "path" component should identify the particular block, t= x, or address in that chain.

So instead of:

blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f7= 6c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce= 26f

It should be:

blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce2= 6f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f

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/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24e= cd3918f76c17f


On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> On Sat, Aug 29, 2015 at 10:10 PM, Jorge Tim=C3=B3n <
> bitcoin-dev@l= ists.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://g= ithub.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > I'm completely fine with doing that using an optional paramet= er (for
> > backwards compatibility).
> >
>
> I see that using the genesis block hash would be the perfectly rigorou= s 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/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3= 918f76c17f
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3= 918f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b6= 0a8ce26f
>
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918= f76c17f?chain=3Dmain
>
> (or a different element name maybe)
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
_______________________= ________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113a2fe0634ef4051eb63303--