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
|
Return-Path: <bip@mattwhitlock.name>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EA44E93
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 17:19:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from resqmta-ch2-06v.sys.comcast.net
(resqmta-ch2-06v.sys.comcast.net [69.252.207.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3BEA103
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 17:19:21 +0000 (UTC)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97])
by resqmta-ch2-06v.sys.comcast.net with comcast
id AhKL1r00726dK1R01hKLQP; Sat, 29 Aug 2015 17:19:20 +0000
Received: from crushinator.localnet
([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0])
by resomta-ch2-01v.sys.comcast.net with comcast
id AhKJ1r0094eLRLv01hKLca; Sat, 29 Aug 2015 17:19:20 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-dev@lists.linuxfoundation.org, Richard Moore <me@ricmoo.com>
Date: Sat, 29 Aug 2015 13:19:17 -0400
Message-ID: <205843673.xtKUGbbkqt@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; )
In-Reply-To: <CF21152C-15FA-421C-B369-A9A7DB59865F@ricmoo.com>
References: <CAE0pACLMcMzHkA=vEx+fiEmq7FA1bXDc4t_hQ+955=r=62V5=g@mail.gmail.com>
<CF21152C-15FA-421C-B369-A9A7DB59865F@ricmoo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20140121; t=1440868760;
bh=XQOYIWa6FqIgpO7eRoD4Ijl4PZi2QUDJpji5arQ/9tM=;
h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version:
Content-Type;
b=r0SlbB75qfGgbW2891ufIN12edu1mA412mAKPcncO2h1GufMPJc0JpRTwMnNdG3YQ
4o6viHSFOPdxBFg4YHzMDxdlw8NeY5bilYO7kOZO1g0F8LCazztqeMeeIQiEJEbPi+
NILkqeG2MuztgFUs79Z91qOZc3and/i9pAbtCzx+RsNjCJss2my7HtGXtN0SrQ4aL5
WbM3ZtYq16FLIhEU/5xYYoiDWLP8c+pyN56YfpC8bzyHybP7AMd/Haq/CNq21B4z1o
0kylRIwoTiU/8Lx4fiGfA7mnqAcIYNQ0Kg2rzqURk7YnC3rTSSerg/oLCc5IJtFujg
l9ptNsgLxKKjg==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 17:19:22 -0000
bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI (a.k.a. a URL); rather, it's an opaque URI.
And your suggestion is actually in violation of the URI spec, since "blockhash", "txid", "block", and "address" are not host names.
More correct would be:
blockchain:?blockhash=00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain:?block=189000
blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
>
> A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
>
> The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
>
> > On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > 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.
|
