summaryrefslogtreecommitdiff
path: root/5f/e2bd214d7067bd30bb5d56d6308bf21cbab5be
blob: c18a3d74afec1245acd561512fa8897afc456ab7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
Return-Path: <marcopon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C2CD8E95
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 11:49:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com
	[209.85.217.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 07002A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 11:49:19 +0000 (UTC)
Received: by lbbsx3 with SMTP id sx3so41895074lbb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 29 Aug 2015 04:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=1VsbfZR1yULFt/gXw4EwNPvcrG4ABFxnThOiepD17qw=;
	b=FDJ8O/pbxpelv9YrwLQVYxd0G33Ppvdk+mRP872Jhf502gTT7P/JRjJKEL+Ji/fjH/
	Y2oe6JDTuJ0eKvooVgC7X0vaZGK1+X75mebqLHmq3XFRYx/a4vOLGCFnXlGWiGLRyuAK
	MdeSZrv561dx/3X5/GNmQ0E0KWVwPWmwQU6of2wd5NjiVTGpvDjGiPjKDgeqMJY5UP9y
	Ie+sboNpxuMjP475A8cV3t7PipCJnRLTz6jLm80NUNgvPIQPTxvOQPc37XGBh99xYajk
	KpiA9Zi2LgJYFihSVUOqfgzcDPon2y8pQkA+KAQs7vjxUFQuskNqB74fYcJ66J0i+1Tn
	+zEw==
X-Received: by 10.112.180.137 with SMTP id do9mr6730768lbc.78.1440848958132;
	Sat, 29 Aug 2015 04:49:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.186.168 with HTTP; Sat, 29 Aug 2015 04:48:58 -0700 (PDT)
From: Marco Pontello <marcopon@gmail.com>
Date: Sat, 29 Aug 2015 13:48:58 +0200
Message-ID: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c25c3e531715051e71ca29
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
Subject: [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 11:49:20 -0000

--001a11c25c3e531715051e71ca29
Content-Type: text/plain; charset=UTF-8

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.

BIP: XX
Title: URI scheme for Blockchain exploration
Author: Marco Pontello
Status: Draft
Type: Standards Track
Created: 29 August 2015

Abstract
========
This BIP propose a simple URI scheme for looking up blocks, transactions,
addresses on a Blockchain explorer.

Motivation
==========
The purpose of this URI scheme is to enable users to handle all the
requests for details about blocks, transactions, etc. with their preferred
tool (being that a web service or a local application).

Currently a Bitcoin client usually point to an arbitrary blockchain
explorer when the user look for the details of a transaction (es. Bitcoin
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.

Specification
=============
The URI follow this simple form:

blockchain: <hash/string>

Examples:

blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

Rationale
=========
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 simple
should be practical enough. Blockchain explorers can apply the same
disambiguation rules they are already using to process the usual search
box.

From the point of view of a wallet developer (or other tool that need to
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 having
to worry about any specific Blockchain explorer or provide a means for the
user to select one.

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.

Users get the convenience of using always their preferred explorer, which
can be especially handy on mobile devices, where juggling with cut&paste
is far from ideal.

--001a11c25c3e531715051e71ca29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi!</div><div>My first post here, hope I&#39;m follow=
ing the right conventions.</div><div>I had this humble idea for a while, so=
 I thought to go ahead and propose</div><div>it.</div><div><br></div><div><=
div>BIP: XX</div><div>Title: URI scheme for Blockchain exploration</div><di=
v>Author: Marco Pontello</div><div>Status: Draft</div><div>Type: Standards =
Track</div><div>Created: 29 August 2015</div><div><br></div><div>Abstract</=
div><div>=3D=3D=3D=3D=3D=3D=3D=3D</div><div>This BIP propose a simple URI s=
cheme for looking up blocks, transactions,</div><div>addresses on a Blockch=
ain explorer.</div><div><br></div><div>Motivation</div><div>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D</div><div>The purpose of this URI scheme is to enable users=
 to handle all the</div><div>requests for details about blocks, transaction=
s, etc. with their preferred</div><div>tool (being that a web service or a =
local application).</div><div><br></div><div>Currently a Bitcoin client usu=
ally point to an arbitrary blockchain</div><div>explorer when the user look=
 for the details of a transaction (es. Bitcoin</div><div>Wallet use BitEasy=
, Mycelium or Electrum use Blockchain.info, etc.).</div><div>Other times re=
sorting to cut&amp;paste is needed.</div><div>The same happens with posts a=
nd messages that reference some particular</div><div>txs or blocks, if they=
 provide links at all.</div><div><br></div><div>Specification</div><div>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>The URI follow this simple f=
orm:</div><div><br></div><div>blockchain: &lt;hash/string&gt; =C2=A0</div><=
div><br></div><div>Examples:</div><div><br></div><div>blockchain:0000000000=
0000001003e880d500968d51157f210c632e08a652af3576600198</div><div>blockchain=
:001949</div><div>blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b781=
6d4dfc3f0f7e04281a</div><div><br></div><div>Rationale</div><div>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</div><div>I thought about using some more complex scheme=
, or adding qualifiers to</div><div>distinguish blocks from txs, but in the=
 end I think that keeping it simple</div><div>should be practical enough. B=
lockchain explorers can apply the same</div><div>disambiguation rules they =
are already using to process the usual search</div><div>box.=C2=A0</div><di=
v><br></div><div>From the point of view of a wallet developer (or other too=
l that need to</div><div>show any kind of Blockchain references), using thi=
s scheme mean that he</div><div>can simply make it a blockchain: link and b=
e done with it, without having</div><div>to worry about any specific Blockc=
hain explorer or provide a means for the</div><div>user to select one.</div=
><div><br></div><div>Blockchain explorers in turn will simply offer to hand=
le the blockchain:</div><div>URI, the first time the user visit their websi=
te, or launch/install the</div><div>application, or even set themselves if =
there isn&#39;t already one.</div><div><br></div><div>Users get the conveni=
ence of using always their preferred explorer, which</div><div>can be espec=
ially handy on mobile devices, where juggling with cut&amp;paste</div><div>=
is far from ideal.</div><div><br></div></div><div><br></div>
</div>

--001a11c25c3e531715051e71ca29--