Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Richard Moore <me@ricmoo.com>
In-Reply-To: <205843673.xtKUGbbkqt@crushinator>
Date: Sat, 29 Aug 2015 15:24:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F03EBBCA-21BB-4F22-9018-54D416646553@ricmoo.com>
References: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
	<CF21152C-15FA-421C-B369-A9A7DB59865F@ricmoo.com>
	<205843673.xtKUGbbkqt@crushinator>
To: Matt Whitlock <bip@mattwhitlock.name>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Precedence: list

I apologize, you are correct, I should not have used the word "real".=20

However, if you look at section 3 of the RFC, the first hierarchal level (wh=
ich in http is used to describe hosts) can be any "authority", not necessari=
ly a hostname.

So, you could use tx, block, address, etc. as the authority for their paths.=


RicMoo

Sent from my self-aware iPhone

.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8=
.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8=
.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>

Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com

> On Aug 29, 2015, at 1:19 PM, Matt Whitlock <bip@mattwhitlock.name> wrote:
>=20
> bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical U=
RI (a.k.a. a URL); rather, it's an opaque URI.
>=20
> And your suggestion is actually in violation of the URI spec, since "block=
hash", "txid", "block", and "address" are not host names.
>=20
> More correct would be:
>=20
> blockchain:?blockhash=3D00000000000000001003e880d500968d51157f210c632e08a6=
52af3576600198
> blockchain:?txid=3D3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0=
f7e04281a
> blockchain:?block=3D189000
> blockchain:?address=3D1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>=20
> You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
>=20
>=20
>> On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev w=
rote:
>> I like the idea of having a standard for this, that all explorers (and ev=
en core, eventually) would understand.
>>=20
>> I would recommend 2 changes though. First, using a real URI scheme, block=
chain:// so that we can just use normal URL parsing libraries. The bitcoin: t=
hing leads to additional code to mutate it into a proper URI before passing i=
t to URL parsing. And I think it would be fine to include the type looking u=
p. For example:
>>=20
>> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a6=
52af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0=
f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>>=20
>> I think this would help the URI be more human understandable as well as g=
ive the explorers the ability to optimize a bit what they are looking for wh=
en hitting various databases.
>>=20
>> A possible future path could also include blockchain://tx/123000/4 for bl=
ock height, tx index... Another possibility could be blockchain://version wh=
ich would return a list of supported paths, version of the BIP supported, et=
c.
>>=20
>> The BIP should also specify little endian searching. I'm not sure, but wo=
uld it also make sense for this BIP to include what the return results shoul=
d look like? Maybe another, related BIP.
>>=20
>>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>>>=20
>>> Hi!
>>> My first post here, hope I'm following the right conventions.
>>> I had this humble idea for a while, so I thought to go ahead and propose=

>>> it.
>>>=20
>>> BIP: XX
>>> Title: URI scheme for Blockchain exploration
>>> Author: Marco Pontello
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 29 August 2015
>>>=20
>>> Abstract
>>> =3D=3D=3D=3D=3D=3D=3D=3D
>>> This BIP propose a simple URI scheme for looking up blocks, transactions=
,
>>> addresses on a Blockchain explorer.
>>>=20
>>> Motivation
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> The purpose of this URI scheme is to enable users to handle all the
>>> requests for details about blocks, transactions, etc. with their preferr=
ed
>>> tool (being that a web service or a local application).
>>>=20
>>> Currently a Bitcoin client usually point to an arbitrary blockchain
>>> explorer when the user look for the details of a transaction (es. Bitcoi=
n
>>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>>> Other times resorting to cut&paste is needed.
>>> The same happens with posts and messages that reference some particular
>>> txs or blocks, if they provide links at all.
>>>=20
>>> Specification
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> The URI follow this simple form:
>>>=20
>>> blockchain: <hash/string> =20
>>>=20
>>> Examples:
>>>=20
>>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600=
198
>>> blockchain:001949
>>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e042=
81a
>>>=20
>>> Rationale
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> I thought about using some more complex scheme, or adding qualifiers to
>>> distinguish blocks from txs, but in the end I think that keeping it simp=
le
>>> should be practical enough. Blockchain explorers can apply the same
>>> disambiguation rules they are already using to process the usual search
>>> box.=20
>>>=20
>>> =46rom the point of view of a wallet developer (or other tool that need t=
o
>>> show any kind of Blockchain references), using this scheme mean that he
>>> can simply make it a blockchain: link and be done with it, without havin=
g
>>> to worry about any specific Blockchain explorer or provide a means for t=
he
>>> user to select one.
>>>=20
>>> Blockchain explorers in turn will simply offer to handle the blockchain:=

>>> URI, the first time the user visit their website, or launch/install the
>>> application, or even set themselves if there isn't already one.
>>>=20
>>> Users get the convenience of using always their preferred explorer, whic=
h
>>> can be especially handy on mobile devices, where juggling with cut&paste=

>>> is far from ideal.
>=20