path: root/35/dd34ff615f9fa02364771e5c4085b2f4528145

Return-Path: <me@ricmoo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F13D511C7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 19:24:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
	[209.85.223.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19FEEA7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 19:24:16 +0000 (UTC)
Received: by ioej130 with SMTP id j130so41460244ioe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 12:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=DEMHZ37nAJVqnVwGfeu3SgxCokKW3DEbeZd6oPO0tPU=;
	b=a6o4IZmg0pV2VjCRUuopCEznVSynb0KGI13EWDuunaPJBbegylAMYJMUoddzXpGkVu
	LmwvOBu4YTNeYaGBecpGgq0OGLeR4CJR8DRKz7n5NSzyW/O0Aw+x5JS3N8ZLeKTHB/Li
	FZdXHlBKRZWJhebKgR5op2UYL/bhoY5/qJs9k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:content-transfer-encoding:message-id:references
	:to; bh=DEMHZ37nAJVqnVwGfeu3SgxCokKW3DEbeZd6oPO0tPU=;
	b=Tb2famo9HcpQTs1MfQQMl9aSzQktszqXtVnN/n1fNI/E+CHpaOVlDT5rEavUjdbkJ5
	KnWMw9hCrQHCQBlQq/A61L+9TgrKzufTuzQsjKu8Wjla95gPaP3ZmncIxJeDvndTIzr7
	cZpxOAm1pNQFBc0l3+ahKuFMEZQhEHJpdyN4RzoM3Q/YqkxauKijR8RtJbUYqhOR7F1Y
	Rjd9v93cRip+m5YCrh+f1iyXSBCwYdg7p/mbqRC1idsfcDnWhmN9OSqCDyOXw9a6VIPJ
	SD5r+to3kUCeqLgHrcYj4h+3N4USKH9OqD3pbD/jiAWU9MvR+6wxd83NgEQxIc5MC9jn
	7uCw==
X-Gm-Message-State: ALoCoQn0VIrOQTdajqRgNgl3HL8rO35CP+poJHX1j/nynNanH/sorVlXJVd9lxZyjBlIP7da3slc
X-Received: by 10.107.10.162 with SMTP id 34mr19165418iok.139.1440876255521;
	Sat, 29 Aug 2015 12:24:15 -0700 (PDT)
Received: from [25.21.55.173] ([24.114.59.155])
	by smtp.gmail.com with ESMTPSA id o23sm5261367ioi.8.2015.08.29.12.24.13
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sat, 29 Aug 2015 12:24:13 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Richard Moore <me@ricmoo.com>
X-Mailer: iPhone Mail (12H321)
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>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, MIME_QP_LONG_LINE,
	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@lists.linuxfoundation.org"
	<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: Sat, 29 Aug 2015 19:24:17 -0000

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