path: root/f5/0925d43ec8fa7b7bfa0a48dd45075af1391c35

Return-Path: <eordano@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 16FA310D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Sep 2015 21:26:19 +0000 (UTC)
Received: by ykdg206 with SMTP id g206so4068465ykd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
	<CABm2gDpC55dsr4GNAUabgnOeXcNTrgHSAtM7Jqfp0_QUfjXmoQ@mail.gmail.com>
	<CAE0pAC+32rhWdBL+WbPANy0rd+eh-XsPQy-u3OHUxS0ku7eN-Q@mail.gmail.com>
	<5546682.RnG4VcateO@crushinator>
From: Esteban Ordano <eordano@gmail.com>
Date: Tue, 1 Sep 2015 18:25:59 -0300
Message-ID: <CALp1fU=yF0EJHq1heLx5jSFCQfzL3YsH+gZgWmcWjjOTE6K_-w@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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<chainID> over network=3D<chainPetnameS=
tr>
> > > 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

<div dir=3D"ltr">Slightly relevant: standardization of http queries to bloc=
kchain explorers. It&#39;s not just about URLs, it&#39;s about the query bo=
dy and response. <a href=3D"https://github.com/common-blockchain">https://g=
ithub.com/common-blockchain</a></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Tue, Sep 1, 2015 at 6:16 PM, Matt Whitlock via bitco=
in-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Isn&#39;t this all backward=
? The &quot;authority&quot; component of the URL should identify the chain,=
 and the &quot;path&quot; component should identify the particular block, t=
x, or address in that chain.<br>
<br>
So instead of:<br>
<br>
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f7=
6c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce=
26f<br>
<br>
It should be:<br>
<br>
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce2=
6f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f<br>
<br>
And I would agree with allowing well-known chains to register a name, to be=
 used as an alternative to the literal, hash syntax:<br>
<br>
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24e=
cd3918f76c17f<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:<br>
&gt; On Sat, Aug 29, 2015 at 10:10 PM, Jorge Tim=C3=B3n &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; I would really prefer chain=3D&lt;chainID&gt; over network=3D&lt;=
chainPetnameStr&gt;<br>
&gt; &gt; By chainID I mean the hash of the genesis block, see<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"https://github.com/jtimon/bitcoin/commit/3191d5e8e7568=
7a27cf466b7a4c70bdc04809d39" rel=3D"noreferrer" target=3D"_blank">https://g=
ithub.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39</a=
><br>
&gt; &gt; I&#39;m completely fine with doing that using an optional paramet=
er (for<br>
&gt; &gt; backwards compatibility).<br>
&gt; &gt;<br>
&gt;<br>
&gt; I see that using the genesis block hash would be the perfectly rigorou=
s way<br>
&gt; to do it, but what do you think about the possibility of letting also =
use<br>
&gt; the name constants, as a simple / more relaxed alternative? That would=
<br>
&gt; spare a source lookup just to write a correct reference to a tx, maybe=
 in a<br>
&gt; forum or a post.<br>
&gt;<br>
&gt; So a reference to a certain tx could be either:<br>
&gt;<br>
&gt; blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3=
918f76c17f<br>
&gt;<br>
&gt; blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3=
918f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b6=
0a8ce26f<br>
&gt;<br>
&gt; blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918=
f76c17f?chain=3Dmain<br>
&gt;<br>
&gt; (or a different element name maybe)<br>
&gt;<br>
&gt; --<br>
&gt; Try the Online TrID File Identifier<br>
&gt; <a href=3D"http://mark0.net/onlinetrid.aspx" rel=3D"noreferrer" target=
=3D"_blank">http://mark0.net/onlinetrid.aspx</a><br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">_______________________=
________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--001a113a2fe0634ef4051eb63303--