Subject: [Uri-review] URI scheme registration request: blockchain

From: Marco Pontello <[email-masked]>
Date: Sun, 10 Jan 2016 15:16:48 +0100

Hello!

This is a request for a new URI scheme.
Thanks for the attention.

Resource Identifier (RI) Scheme name: blockchain
Status: provisional

Scheme syntax:
   blockchain:[//chain]</type/hash>

Scheme semantics:
   Referencing objects on a specific blockchain.

Encoding considerations:
   7-bit ASCII is sufficient.

Applications/protocols that use this scheme name:
   Crypto wallets, block explorers, etc.

Interoperability considerations:
   None.

Security considerations:
   None known or expected.

Contact:
   Registering party: Marco Pontello <[email-masked]>
   Scheme creator: Marco Pontello <[email-masked]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:
   https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki

   Simple test handler / demo (sort of a blockchain explorer proxy):
   https://github.com/MarcoPon/blockchain-exploration
   https://www.youtube.com/watch?v=7wwVnQn7rj8

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Sun, 10 Jan 2016 15:27:53 +0100

>    blockchain:[//chain]</type/hash>

Firstly - would be nice to see a more RFC style definition; staying within the nomenclature of RFC 2396 to avoid doubt.

Secondly - you define a chain:

	chain	chain ID (see below) of the desired chain, leading 0s included. If omitted (which would be the usual case), Bitcoin main net is assumed.	optional

So we could have

	blockchain://X/Y/Z
and
	blockchain:/Y/Z

if ‘X’ where the ‘bitcoin main net’ (which is really called 000….25f I guess).

How would you compare this to (e.g. file) the commonly used:

	file:///foo.txt

	v.s

	file:foo.txt

And finally - are you implying any equivalancy in your example:

	A block on Bitcoin main net:

		 blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72
	or
		 blockchain:/block/372338

if so - can we state equivalency rules/comparison rules ?

Thanks,

Dw.

---

From: Marco Pontello <[email-masked]>
Date: Sun, 10 Jan 2016 16:29:42 +0100

Hi!

On Sun, Jan 10, 2016 at 3:27 PM, Dirk-Willem van Gulik <[email-masked]
> wrote:

> Firstly - would be nice to see a more RFC style definition; staying within
> the nomenclature of RFC 2396 to avoid doubt.
>

Actually I thought I did that, but I mostly looked at other URI definitions
as a template.
Will check the RFC and see how I can better specify it.

>         chain   chain ID (see below) of the desired chain, leading 0s
> included. If omitted (which would be the usual case), Bitcoin main net is
> assumed.        optional
>
> So we could have
>
>         blockchain://X/Y/Z
> and
>         blockchain:/Y/Z
>
Yes, exactly.

> How would you compare this to (e.g. file) the commonly used:

The idea (surfaced discussing the bitcoin-dev mailing list) was indeed to
use the authority part to indicate a specific blockchain, and structure the
other items as a path, in a way to give a hierarchical structure, and also
to mimic the way block explorers are already structuring their URLs.
For example, currently to point to a standard Bitcoin transaction with some
commonly used block explorers, URLs like these would be constructed:

https://blockchain.info/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492
https://tradeblock.com/bitcoin/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492
https://www.blockseer.com/transactions/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492/graph

Using the proposed URI that would be (no need to specify the chain, as it's
the default one):

blockchain:/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492/graph

Probably the strange part is the "/" at the start, and I was a bit
ambivalent about it too. But it turn out for various application and tools
already in use that let simply editing some configuration parameter and
adapt the code used to produce URLs to use the new URI, or allow some code
reuse with minimal modifications. So in the end that seemed a good way to
do it.

> if so - can we state equivalency rules/comparison rules ?

It's a well established convention to refer to blocks in a blockchain
either by block hash, or by block height/index.
The block hash is 32bit long, so requiring that the leading 0s are included
imply that it will always composed by 64 hex digits/chars. The height/index
instead is simply a sequential number.
So they are easily distinguishable, either visually and programmatically,
and most block explorers for example already are using a simple "lenght
logic" to process this kind of input. I wrote the spec in this way with the
idea of both keeping the URI simple (without adding another element) and
conform to an existing convention.

Thanks for your attention.
Bye!

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Sun, 10 Jan 2016 16:37:59 +0100

On 10 Jan 2016, at 16:29, Marco Pontello <[email-masked]> wrote:
...
>> if ‘X’ where the ‘bitcoin main net’ (which is really called 000….25f I guess).

So it may be an idea to make the spec a bit more exacting here.

> The idea (surfaced discussing the bitcoin-dev mailing list) was indeed to use the authority part to indicate a specific blockchain, and structure the other items as a path, in a way to give a hierarchical structure, and also to mimic the way block explorers are already structuring their URLs.

That makes sense - so perhaps be very clear about what the structure is - and (dis)allow explictly the ‘///‘ construct - or define an equivalency rule.

> For example, currently to point to a standard Bitcoin transaction with some commonly used block explorers, URLs like these would be constructed:
> 
> Using the proposed URI that would be (no need to specify the chain, as it's the default one):
> 

Right - so you may also want to be clear then about the equivalency between  'tx/….’ and ‘/tx/…./graph’ - or state that it must be blockchain:/tx…/graph always.

> Probably the strange part is the "/" at the start, and I was a bit ambivalent about it too. But it turn out for various application and tools already in use that let simply editing some configuration parameter and adapt the code used to produce URLs to use the new URI, or allow some code reuse with minimal modifications. So in the end that seemed a good way to do it.
>  

> It's a well established convention to refer to blocks in a blockchain either by block hash, or by block height/index.
> The block hash is 32bit long, so requiring that the leading 0s are included imply that it will always composed by 64 hex digits/chars. The height/index instead is simply a sequential number.
> So they are easily distinguishable, either visually and programmatically, and most block explorers for example already are using a simple "lenght logic" to process this kind of input. I wrote the spec in this way with the idea of both keeping the URI simple (without adding another element) and conform to an existing convention.

That is fine — but at some point applications will need to act on it; a firewall/proxy/whatever may need to record or trigger. Something needs to be logged; some auto complete needs to happen. Whatever.

And at that point you want to know how to compare them - or to ‘deny’ or declare certain constructs illegal. E.g. are

	blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72
	blockchain:/block/00000000000000000119AF5BCAE2926DF54AE262E9071A94A99C913CC217CC72
	blockchain:/block/0000000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72
	blockchain:/block/00000000000000000119af5bcae2926df54ae262e9071a94a99c913cc217cc72/

the same ? Or do you define the rules for this space very exacting - that it is exactly 64 hex digits - and they are to be lower case always ? And the use of % escaping is never allowed; etc. etc.

Dw.

---

From: Marco Pontello <[email-masked]>
Date: Sun, 10 Jan 2016 17:08:09 +0100

On Sun, Jan 10, 2016 at 4:37 PM, Dirk-Willem van Gulik <[email-masked]

> > The idea (surfaced discussing the bitcoin-dev mailing list) was indeed
> to use the authority part to indicate a specific blockchain, and structure
> the other items as a path, in a way to give a hierarchical structure, and
> also to mimic the way block explorers are already structuring their URLs.
>
> That makes sense - so perhaps be very clear about what the structure is -
> and (dis)allow explictly the ‘///‘ construct - or define an equivalency
> rule.
>

OK I'll see what I can do to clarify that.

>
> > For example, currently to point to a standard Bitcoin transaction with
> some commonly used block explorers, URLs like these would be constructed:
> >
> >
> Right - so you may also want to be clear then about the equivalency
> between  'tx/….’ and ‘/tx/…./graph’ - or state that it must be
> blockchain:/tx…/graph always.
>

Sorry here, the "/graph" ending part was a cut&paste mistake. The lines
always ends just with the hash:
I'll rewrite them here for clarity:

https://blockchain.info/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492
https://tradeblock.com/bitcoin/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492
https://www.blockseer.com/transactions/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492
<https://www.blockseer.com/transactions/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492/graph>

Corresponding blockchain URI:

blockchain:/tx/06198e99e5916fea6b5c66825f082710a52220dca018f26b9cf46633236e6492

> That is fine — but at some point applications will need to act on it; a
> firewall/proxy/whatever may need to record or trigger. Something needs to
> be logged; some auto complete needs to happen. Whatever.
>
> And at that point you want to know how to compare them - or to ‘deny’ or
> declare certain constructs illegal. E.g. are
>
>
> the same ? Or do you define the rules for this space very exacting - that
> it is exactly 64 hex digits - and they are to be lower case always ? And
> the use of % escaping is never allowed; etc. etc.
>

I see. I will refer to rfc2396 to see how to better specify everything.

Looking at other provisional URI spec I thought the rules were more
relaxed, but I understand that getting it just right from the start is
surely a better way.

Thanks.
Bye!

-- 
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 10 Jan 2016 17:20:24 +0100

> Thanks for the attention.

Thanks for working on this.  I had previously worked on a block explorer
using URIs (it's down now, but I can get it up and running again).

Some comments:

Have you looked at : https://tools.ietf.org/html/rfc6920

I implemented blocks, block headers and transactions using this system.  It
has one BIG advantage, allowing the URIs to be systematically dereferenced
on the web, thereby uniting all block explorers.  Incidentally I also
standardized the output enabling block explorer equivalence, as each
explorer seems to have rolled it's own JSON format.

Addresses are generally a wrapped public key, generally base58 encoded, tho
there's some differences (e.g. bitcoin vs ripple).  I didnt model addresses
using ni:/// but dont we have a bitcoin: URI scheme to do this already?

Will there be a registry that maps network addresses, prefixes and coins?
e.g. per:

https://github.com/brainwalletX/brainwalletX.github.io/blob/master/index.html#L47

Coin height is a tricky one.  A coin can have multiple blocks at a given
height.  e.g. if proof of work has yet to be established, or if a coin has
multiple genesis blocks, or any number of other scenarios with different
consensus algorithms.

Thanks again for this work, I welcome standardization in this area.  This
is a great incremental step, but with a little bit of thought we could
solve it once and for all.  I recognize getting consensus on bitcoin-dev is
something of a challenge, but could well be worth ironing out some details
and making it model electronic coins as per satoshi's paper.

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

---

From: Marco Pontello <[email-masked]>
Date: Sun, 10 Jan 2016 17:58:43 +0100

Hi Melvin!

I wasn't aware of rfc6920, and an (admittedly quick) read make me think
it's very interesting, thanks.

But, I have to say that I started the Bitcoin Improvement Proposal with the
idea to keep it as simple as possible, for the exactly same reason that you
mentioned at the end: getting consensus on bitcoin-dev is something of a
challenge.
The end result is that some things just don't get done, when there may be a
simple solution that cover 99% of the usage cases.

In the specific case, the main issue was that there are many block explorer
to choose from, and wallet devs used to just hard code support for one of
them. Then it become the norm to support at least some. But there are
always new explorers coming up, and differents users have different needs &
preferences. In a similar fashion, there are tons of references so specific
TXs made on messages, forums, subreddit, etc., and no easy way to browse
them, so the norm is basically cut & paste the hases on the preferred block
explorer, that would be like cut&pasting URLs on a browser. It's surely
time to do something better.

Even when I started discussing the BIP, I proposed a super-simple scheme
like: blockchain:hash.
But then it was mentioned that explicitly differentiating elements would be
better, which is surely true (at least it may save some database hits).
Then it emerged that it would a nice thing to point to different chain
(Bitcoin's main, test, regtest, etc.), and so the chain part was added.
Then again it become apparent that it could be coin agnostic, and so used
for other coins too; but some forks, so a system to define a different
chain id in those case was needed. You clearly get the idea.

Now we are at some point where the spec is functional enough, and has
gained a decent support (I had public and private conversation with wallet
& block explorer devs that though it was a nice idea and are willing to
implement it).
So I would think that now the best course would be to go on with this and
see it actually implemented, to finally resolve some of the more practical
use cases.

And that doesn't mean that an even better proposal / standards can go on
and eventually overlap or even supplant this scheme. Maybe it will even
simplify the process, as it will be more common for wallet devs to just use
URIs for provinding more details about a transaction, and it will be as
common for block explorer or similar web API/tools to deal with URI
handling.

Does that makes sense?

About the existance of registry, in this case to identify chains. That was
discussed initially, and the main target was to not have a central registry
and keep thing decentralized. From that the usage of a genesis block hash
(or first block after fork) as the chain-id: It's something already
available and unique.
I thought that also a truncated hash could be used (like the lowest 32bit,
rightmost 8 hex digits), for practical purposes, but again I left just the
full chain-id at the moment, to keep it simple.
That doesn't exclude that it may become practical to have some kind of
decentralized DNS system, or even just some some general agreed nicknames
to id some chains, but I thought it was outside the scope, at the moment.

Similar thing for the blocks height; it works well in most cases, but can
be tricky in some. Easy solution, when it may be tricky, don't use them and
just resort to block hashes.

I promise to give the rfc a proper read.

P.S. Sorry for the wall of text, and also for the inevitable mistakes
(English isn't my main language).

Bye!

On Sun, Jan 10, 2016 at 5:20 PM, Melvin Carvalho <[email-masked]>
wrote:

> I implemented blocks, block headers and transactions using this system.
> It has one BIG advantage, allowing the URIs to be systematically
> dereferenced on the web, thereby uniting all block explorers.  Incidentally
> I also standardized the output enabling block explorer equivalence, as each
> Addresses are generally a wrapped public key, generally base58 encoded,
> tho there's some differences (e.g. bitcoin vs ripple).  I didnt model
> addresses using ni:/// but dont we have a bitcoin: URI scheme to do this
> already?
>

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 10 Jan 2016 18:21:29 +0100

> it's very interesting, thanks.

Great!  I think this RFC could solve the problems, and has some really nice
features such as a web interface at .well-known/ which you may want to use
anyway.

>
> But, I have to say that I started the Bitcoin Improvement Proposal with
> the idea to keep it as simple as possible, for the exactly same reason that
> you mentioned at the end: getting consensus on bitcoin-dev is something
> of a challenge.
> The end result is that some things just don't get done, when there may be
> a simple solution that cover 99% of the usage cases.
>

I kind of figured, syntactic sugar is the addiction of our times :)

>
> In the specific case, the main issue was that there are many block
> explorer to choose from, and wallet devs used to just hard code support for
> one of them. Then it become the norm to support at least some. But there
> are always new explorers coming up, and differents users have different
> needs & preferences. In a similar fashion, there are tons of references so
> specific TXs made on messages, forums, subreddit, etc., and no easy way to
> browse them, so the norm is basically cut & paste the hases on the
> preferred block explorer, that would be like cut&pasting URLs on a browser.
> It's surely time to do something better.
>

I feel this pain point too, hence my motivation to create something that
works with all.

> But then it was mentioned that explicitly differentiating elements would
> be better, which is surely true (at least it may save some database hits).

Makes sense.  Simplicity is good, but we also need to be technically
correct or you can end up not solving the problem you set out to, in a
scalable way.  e.g. addition of a new coin or new version could break the
existing structure by providing collisions.  So some thought at the start
can be beneficial.

> see it actually implemented, to finally resolve some of the more practical

Im all for incremental improvements.  Is there a forum the block chain
implementors discuss?  Perhaps a W3C community group could be fired up.  I
think bitcore might be the key implementation, right (bitpay is already a
w3c cg participant).

It's possible to make a good spec that covers a lot of cases *and* make it
simple, or even simpler.

> common for block explorer or similar web API/tools to deal with URI

It makes sense, in a generic sense, but I think it's important to be clear
on goals.  Are we simply trying to provide shorthand for bitcoin?  Or
bitcoin + testnet?  Or general electronic coins as set out in satoshi's
paper (there's over 1000 coins) -- are some coins going to be included and
some discluded?

> (or first block after fork) as the chain-id: It's something already

This is a nice idea.  Tho even from one hash you can have several chains.
You can never actually know which chain is correct.  For example, the NSA
may have a longer chain in a big data center that we dont know about that
is the 'real' longest chain.

Thing is each block chain might have different ways of doing this.  Also
SHA256 might not always be used.  It doesnt even have to always be used in
*bitcoin*.

> to id some chains, but I thought it was outside the scope, at the moment.

Not much gain truncating the hash imho.  Why not use base64 as is standard,
and shorten the text.  Hex may be common in the btc community, but base64
is common elsewhere.  There's a one to one mapping between the two.

> just resort to block hashes.

One problem with height is that what it refers to can change.  Also
regarding what you call blocks, aren't they actually block headers?

BTW I also modelled the merkle roots which you can do with hashes and is
probably useful.

> (English isn't my main language).
Great!  Your english is better than my italian, kudos! :)

If it would help, I'll try and get my implementation up and running again?
... only issue was that running a full node was getting expensive for me

> Bye!
>
>
>
>
> On Sun, Jan 10, 2016 at 5:20 PM, Melvin Carvalho <[email-masked]
> > wrote:
>
>>
>>
>> Will there be a registry that maps network addresses, prefixes and
>> coins?  e.g. per:
>>
>>

---

From: Marco Pontello <[email-masked]>
Date: Sun, 10 Jan 2016 18:50:11 +0100

Hi Melvin!

I'll reply privately as I think we are going to be OT here.

Bye!

On Sun, Jan 10, 2016 at 6:21 PM, Melvin Carvalho <[email-masked]>
wrote:

> Great!  I think this RFC could solve the problems, and has some really
> nice features such as a web interface at .well-known/ which you may want to
> use anyway.
>
>
>>
>> About the existance of registry, in this case to identify chains. That
>> was discussed initially, and the main target was to not have a central
>> registry and keep thing decentralized. From that the usage of a genesis
>> block hash (or first block after fork) as the chain-id: It's something
>> already available and unique.
>>
>
>> I thought that also a truncated hash could be used (like the lowest
>> 32bit, rightmost 8 hex digits), for practical purposes, but again I left
>> just the full chain-id at the moment, to keep it simple.
> Not much gain truncating the hash imho.  Why not use base64 as is
> standard, and shorten the text.  Hex may be common in the btc community,
> but base64 is common elsewhere.  There's a one to one mapping between the
> two.
>
>
>>
>> Similar thing for the blocks height; it works well in most cases, but
>> can be tricky in some. Easy solution, when it may be tricky, don't use them
>> and just resort to block hashes.
>>
>
>> On Sun, Jan 10, 2016 at 5:20 PM, Melvin Carvalho <
>> [email-masked]> wrote:
>>
>>>
>>>
>>> Thanks again for this work, I welcome standardization in this area.
>>> This is a great incremental step, but with a little bit of thought we could

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 11 Jan 2016 10:55:28 +0900

> Will check the RFC and see how I can better specify it.

Please don't look at RFC 2396, it's obsoleted by 
https://tools.ietf.org/html/rfc3986.

For registration, also check out https://tools.ietf.org/html/bcp35 (RFC 
7595).

Regards,   Martin.

---

From: Marco Pontello <[email-masked]>
Date: Mon, 11 Jan 2016 03:04:27 +0100

> For registration, also check out https://tools.ietf.org/html/bcp35 (RFC

Will do, thanks!
Bye!

---

From: Graham Klyne <[email-masked]>
Date: Mon, 11 Jan 2016 06:04:52 +0000

> I see. I will refer to rfc2396 to see how to better specify everything.

The current RFC spec is (and has been for several years) RFC3986:

https://tools.ietf.org/html/rfc3986

#g
--

---

From: Marco Pontello <[email-masked]>
Date: Wed, 13 Jan 2016 11:58:27 +0100

Hello again!

Here's the updated request for the URI scheme.

Scheme name:
  blockchain

Status:
  Provisional

Contact:

  Same as contact.

References:

Scheme syntax:
  blockchain:[//<chain>]/<tx|block|address>/<hash>

  blockchainuri = bc-scheme ":" bc-hier-part
  bc-scheme = "blockchain"
  bc-hier-part = ["//" bc-authority] "/" object-path
  bc-authority = chain-id
  object-path = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) /
                ("address" "/" address)
  chain-id = hash
  hash = 64HEXDIG
  blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" integer
  address = base58 ; https://en.wikipedia.org/wiki/Base58

Scheme semantics:
    Referencing objects on a specific blockchain (usually Bitcoin main net).
    The main purpose is to provide a quick & simple way to look for details
    about a transaction/block/address, launching an appropriate web or local
    application.

Encoding considerations:
  US-ASCII.
  No special encoding/escaping needed or admitted for any part.

Security considerations:
  None known or expected.

Thanks again for the attention!
Bye!

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 13 Jan 2016 14:26:55 +0100

On 13 Jan 2016, at 11:58, Marco Pontello <[email-masked]> wrote:
..
>   https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki  

May be nice to cut-and-paste the key parts of this in this document; so they will life ‘forever’.

>   object-path = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) /

May be nice ot define these - or just clarify that it A7 is identical to a7 (if that is what you want). Or that you only allow uppercase ?

>   address = base58 ; https://en.wikipedia.org/wiki/Base58

May be good to be find a better normative reference; as you are not just meaning Base58; but the specific (I assume) “123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz” sequence and in exactly that order (and not the other odd garbled ones as used by some of the other cash coins). 

And clarify that the result is a byte array — as to define any worries about endianness.

Perhaps refer to RFC3548 and include something like below in the document (i.e. equivalent to table 1 to 5 of rfc3548); and a very small section that says that that linefeeds are not allowed; padding is (as your above structure does not seem to impose length differences which I guess one would need to guarantee that padding is never allowed).

>   No special encoding/escaping needed or admitted for any part.

So you consider bitcoin://%443289741289471239 etc.. an invalid one - as encoding/escaping is not permitted ?

Correct ?

> Interoperability considerations:

Actually - you may want to stress at this point the importance of non-escaping and applying the very strict ASCII range; as to avoid people getting ‘fooled’ by font and unicode tricks.

Dw.
                   Table 1: The Base 58 Alphabet - boitcoin ordered

value
ascii code point
encoding
value
ascii code point
encoding
value
ascii code point
encoding
value
ascii code point
encoding
0
49
1
15
71
G
30
88
X
45
110
n
1
50
2
16
72
H
31
89
Y
46
111
o
2
51
3
17
74
J
32
90
Z
47
112
p
3
52
4
18
75
K
33
97
a
48
113
q
4
53
5
19
76
L
34
98
b
49
114
r
5
54
6
20
77
M
35
99
c
50
115
s
6
55
7
21
78
N
36
100
d
51
116
t
7
56
8
22
80
P
37
101
e
52
117
u
8
57
9
23
81
Q
38
102
f
53
118
v
9
65
A
24
82
R
39
103
g
54
119
w
10
66
B
25
83
S
40
104
h
55
120
x
11
67
C
26
84
T
41
105
i
56
121
y
12
68
D
27
85
U
42
106
j
57
122
z
13
69
E
28
86
V
43
107
k

14
70
F
29
87
W
44
109
m
padding
61
=

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 13 Jan 2016 14:40:23 +0100

Correct ?

Dw.
                   Table 1: The Base 58 Alphabet - boitcoin ordered
+-------+------------------+----------+-------+------------------+----------+-------+------------------+----------+-------+------------------+----------+
| value | ascii code point | encoding | value | ascii code point | encoding | value | ascii code point | encoding | value | ascii code point | encoding |
+-------+------------------+----------+-------+------------------+----------+-------+------------------+----------+-------+------------------+----------+
+----+----+---+----+----+---+----+-----+---+---------+-----+---+
|  0 | 49 | 1 | 15 | 71 | G | 30 |  88 | X | 45      | 110 | n |
|  1 | 50 | 2 | 16 | 72 | H | 31 |  89 | Y | 46      | 111 | o |
|  2 | 51 | 3 | 17 | 74 | J | 32 |  90 | Z | 47      | 112 | p |
|  3 | 52 | 4 | 18 | 75 | K | 33 |  97 | a | 48      | 113 | q |
|  4 | 53 | 5 | 19 | 76 | L | 34 |  98 | b | 49      | 114 | r |
|  5 | 54 | 6 | 20 | 77 | M | 35 |  99 | c | 50      | 115 | s |
|  6 | 55 | 7 | 21 | 78 | N | 36 | 100 | d | 51      | 116 | t |
|  7 | 56 | 8 | 22 | 80 | P | 37 | 101 | e | 52      | 117 | u |
|  8 | 57 | 9 | 23 | 81 | Q | 38 | 102 | f | 53      | 118 | v |
|  9 | 65 | A | 24 | 82 | R | 39 | 103 | g | 54      | 119 | w |
| 10 | 66 | B | 25 | 83 | S | 40 | 104 | h | 55      | 120 | x |
| 11 | 67 | C | 26 | 84 | T | 41 | 105 | i | 56      | 121 | y |
| 12 | 68 | D | 27 | 85 | U | 42 | 106 | j | 57      | 122 | z |
| 13 | 69 | E | 28 | 86 | V | 43 | 107 | k |         |     |   |
| 14 | 70 | F | 29 | 87 | W | 44 | 109 | m | padding |  55 | = |
+----+----+---+----+----+---+----+-----+---+---------+-----+---+

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jan 2016 18:17:10 +0000

Hi Marco,

>   bc-hier-part = ["//" bc-authority] "/" object-path
One more issue: if you are not using a hostname/IP+port for the 
authority part, I don't think you can be using "//", as this is a 
semantics violation. Just drop "//".
>   address = base58 ; https://en.wikipedia.org/wiki/Base58

Best Regards,
Alexey

---

From: Adrian Hope-Bailie <[email-masked]>
Date: Thu, 14 Jan 2016 21:31:07 +0200

Hi Alexey,

On 14 January 2016 at 20:17, Alexey Melnikov <[email-masked]>
wrote:

> One more issue: if you are not using a hostname/IP+port for the authority
> part, I don't think you can be using "//", as this is a semantics
> violation. Just drop "//".
>

Is this true?
My understanding of RFC 3986 is that using "//" simply implies that the
path can be divided into an authority and then a path that follows.
i.e. Using "//" means that the value between that and the first single
slash "/", question mark "?" or hash sign "#" or the end of the URI is the
authority.

There is no requirement for an authority to be a DNS hostname or IP+port.
The ABNF notation is: [ userinfo "@" ] host [ ":" port ]
Where the ABNF for host is:  IP-literal / IPv4address / reg-name

The syntax rule applies the "first-match-wins" algorithm.
i.e. First try to parse as an IP-literal, then IPv4address then assume it's
a reg-name.
If host matches the rule for IPv4address, then it should be considered an
IPv4 address literal and not a reg-name.

>From the RFC:

   A host identified by a registered name is a sequence of characters
   usually intended for lookup within a locally defined host or service
   name registry, though the URI's scheme-specific semantics may require
   that a specific registry (or fixed name table) be used instead.

It would seem that a "chain" is a fair authority?

  bc-authority = chain-id

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Jan 2016 11:47:04 -0800

> Where the ABNF for host is:  IP-literal / IPv4address / reg-name
​I agree with this interpretation, and I have used "reg-name" based
authorities in the past that were not DNS delegations (for DHT-based
systems).

regards,

Ted​

> i.e. First try to parse as an IP-literal, then IPv4address then assume
> it's a reg-name.

---

From: Marco Pontello <[email-masked]>
Date: Sun, 17 Jan 2016 15:10:31 +0100

Hi again. Sorry for the late reply.

On Wed, Jan 13, 2016 at 2:26 PM, Dirk-Willem van Gulik <[email-masked]

> they will life ‘forever’.

OK, I see your point. Will do.

>   hash = 64HEXDIG
>
>
> May be nice ot define these - or just clarify that it A7 is identical to
> a7 (if that is what you want). Or that you only allow uppercase ?
>

Indeed I was meaning that both upper or lower case can be used. Probably
the stylistic preference would go to lowercase, but it's surely not a
requirement so I would prefer to allow both.
I was under the assumption that HEXDIG is a basic rule (rfc 5234, B.1), and
allow both casing. But this is my first encounter with ABNF, and I'm far
from very familiar with it.
So if you think that a clarification is need, I will add that.

> May be good to be find a better normative reference; as you are not just
> meaning Base58; but the specific (I assume)
> “123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz” sequence and
> in exactly that order (and not the other odd garbled ones as used by some
> of the other cash coins).
>

Actually, while the scheme was developed with Bitcoin in mind, I tried to
intentionally keep it coin agnostic, so that if other cryptocurrency can
see it useful and "fit in", they may very well use it.
Using a Base58 encoding for the address is basically a standard, but as the
order & values may be different, I think that I can better specify in the
ABNF grammar the exact symbols that Base58 allow, but leave out the
specific of the order/values.
I may add a remark to point out that is a responsibility of the handler to
recognize if the specified chain-id is something it can handle, and then
the address will be evaluated accordingly.

Would that be acceptable?

> And clarify that the result is a byte array — as to define any worries

OK.

> encoding/escaping is not permitted ?

Yes!

> Actually - you may want to stress at this point the importance of
> non-escaping and applying the very strict ASCII range; as to avoid people
> getting ‘fooled’ by font and unicode tricks.
>

OK!

Thanks again for your attention.
Bye!

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 18 Jan 2016 11:26:39 +0100

On 17 Jan 2016, at 15:10, Marco Pontello <[email-masked]> wrote:

> Actually, while the scheme was developed with Bitcoin in mind, I tried to intentionally keep it coin agnostic, so that if other cryptocurrency can see it useful and "fit in", they may very well use it.
> Using a Base58 encoding for the address is basically a standard, but as the order & values may be different, I think that I can better specify in the ABNF grammar the exact symbols that Base58 allow, but leave out the specific of the order/values.
> I may add a remark to point out that is a responsibility of the handler to recognize if the specified chain-id is something it can handle, and then the address will be evaluated accordingly. 
> 

So rapidly you are now going to a structure where you have a hierachy; which becomes increasingly opaque/weakly-defined towards the end.

So we have

	blockchain 

followed by

	some chain specifier

followed by 

	chain specific ‘things’ such as a block, transaction, etc.

followed by 

	an even more specific ‘identifier’.

And towards the ends it gets more and more arcane and specific. If we take that wiki page: https://en.wikipedia.org/wiki/Base58 we already see 3 types of ‘alphabets’ - each quite specific:

	Bitcoin addresses[1]	123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz[2]
	Ripple addresses[3]	rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz[4]
	short URLs for Flickr[5]	123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ[6]

and it is not unfair to imagine that some other type of chain would want to use plain old base64.

So there are two extremes (Just like in programming you have an endless debate between strongly typed languages and weakly typed ones):

-	You lock this down as tight as possible for bitcoins.

	Thus improving on interoperability, reliability, making spoofing and hacks/tricks harder (esp. those that confuse the user into doing something silly).

versus

-	You make this very generic - but for a whole raft of things the string that follows ‘blockchain:’ can be virtually anything.

	Thus making it long term very long-lived without updating documents — but bad for interoperability, nasty side effects, security, etc, etc. 

And between it a whole raft of compromises. E.g. one for bitcoin and ripple being very well defined; and others being very weakly defined. 

The downside of all of this is that of the (lazy*) developer may be tempted in allowing too much; and not locking down the parsing of a bitcoin as much as it could and should from a general internet good hygiene point of view.

Dw.

*: http://threevirtues.com — three great virtues of a programmer

---

From: Marco Pontello <[email-masked]>
Date: Mon, 18 Jan 2016 14:40:46 +0100

Hi!

On Mon, Jan 18, 2016 at 11:26 AM, Dirk-Willem van Gulik <
[email-masked]> wrote:

> And towards the ends it gets more and more arcane and specific. If we take
> that wiki page: https://en.wikipedia.org/wiki/Base58 we already see 3
> types of ‘alphabets’ - each quite specific:
>
>
>         Bitcoin addresses[1]
> 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz[2]
>         Ripple addresses[3]
>  rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz[4]
>         short URLs for Flickr[5]
> 123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ[6]
>

I see your point.
But, since an address (in this case) is the "final form" that's needed to
properly identify an address on a certain blockchain, I was thinking that
properly define how it "have to appear" is the key in this context, while
the details of the encoding itself are not really relevant.
For some applications, for example, it can also be used just "as is",
considered simply as a byte array and not even decoded.

Instead, another encoding with different symbols, like base64, is highly
unlike, since base58 was typically used in this context to create easily
readable addresses with as little ambiguities as possible. In any case, an
eventual crypto coin that would choose to use such an encoding, would not
be able to use this scheme, and that's perfectly fine.

Anyway, that was my reasoning, but I'm not an expert here.
So if you if you think a proper values/order table is a must / highly
recommended, I will add it. Maybe pointing out the possibility that, while
highly unlike, the specific order/values maybe different for some less
known or future crypto coin?

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Mon, 18 Jan 2016 18:00:10 +0100

On 18 Jan 2016, at 14:40, Marco Pontello <[email-masked]> wrote:
> 
> So if you if you think a proper values/order table is a must / highly recommended, I will add it. Maybe pointing out the possibility that, while highly unlike, the specific order/values maybe different for some less known or future crypto coin? 

So I guess the call you need to make is

-	do I want a URI scheme that is very good/reliable/robust and ‘safe’ (i.e. actively helps developers and admins years hence to keep things interoperable & secure/safe).

	At the expense of making it less generic.

-	do I want something very generic - pushing a lot of security and usability concerns out to some poor soul 5-10 years from now ?

Or do I do something in the middle. 

Dw.

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 18 Jan 2016 18:32:44 +0100

On 18 January 2016 at 14:40, Marco Pontello <[email-masked]> wrote:

>> And towards the ends it gets more and more arcane and specific. If we
>> take that wiki page: https://en.wikipedia.org/wiki/Base58 we already see
>> 3 types of ‘alphabets’ - each quite specific:
>>
>>
>>         Bitcoin addresses[1]

Is this actually base58?

IIRC electronic coins, such as bitcoin, add a checksum to base58 encoding?

I've never known the correct name for this internet wide, is it base58Check?

I believe also because the bitcoin P2P system doesnt do multiplexing, and
for example the test and main net run on different ports, then also each
coin has one byte identifier in order to distinguish which kind of address
it is on the network.  So while the base58 of a bitcoin address and testnet
and other coin may be identical, over the network (and e.g. in block
explorers) they look different, being actually a combination of a base58
address AND a prefix.  I dont recall all the minor details off the top of
my head, more info here:

https://en.bitcoin.it/wiki/Base58Check_encoding

I may be wrong on this, hopefully this can be corrected.

I'd also be interested in what the IETF things this kind of hash should be
called with reference to say the ni URI scheme in RFC 6920

ni:///base58Check;

for example?

---

From: Marco Pontello <[email-masked]>
Date: Mon, 18 Jan 2016 19:42:25 +0100

On Mon, Jan 18, 2016 at 6:00 PM, Dirk-Willem van Gulik <[email-masked]

> -       do I want a URI scheme that is very good/reliable/robust and
> ‘safe’ (i.e. actively helps developers and admins years hence to keep
> things interoperable & secure/safe).
>

Actually, I took some time to check the documentation of other crypto
coins, and found that all seems to use the exact convention of Bitcoin for
the addresses encoding (in terms of symbols, order, values).
>From the Wikipedia link about base58, for instance Ripple is not based on a
blockchain (so not even a candidate), and Flickr URL enconding scheme is
obviously an entirely different kind of animal.

So i can very well add the table like you recommended, without losing
anything.

Will prepare a new version of the scheme spec and resubmit.

Thanks again.
Bye!

---

From: Marco Pontello <[email-masked]>
Date: Mon, 18 Jan 2016 19:56:22 +0100

> I've never known the correct name for this internet wide, is it

Right. It's usually referred simply to base58, but I may very well use the
explicit name and add a reference to that page on bitcoin.it that you
mentioned.

> it is on the network.

Yes. But I don't think these lower level details should endup in the URI
spec.
It would also probably be pointless to try to specify them here, with the
rate of evolution of the subject. For example, in this period there's a lot
of work done regarding Segregated-Witness, and one of the byproducts is the
addition of another class of addresses (with different version bytes).
But the addresses will still look the same (for the purposes of this
scheme). For example we could have:
17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem (a normal Pubkey hash)
3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX (Script hash)
2MzQwSSnBHWHqSAqtTVQ6v47XtaisrJa1Vc (Testnet script hash)
etc.

Bye!

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 18 Jan 2016 20:02:35 +0100

On 18 January 2016 at 19:56, Marco Pontello <[email-masked]> wrote:

> On Mon, Jan 18, 2016 at 6:32 PM, Melvin Carvalho <[email-masked]
> > wrote:
>
>> Is this actually base58?
>>

Yes but that's not the public key hash.  It's the public key hash plus
network address prefix plus checksum.

Public key hashes are the same (character identical) over mainnet, testnet
and even other coins.

ECC public keys are pretty well defined.  Base58 is pretty well defined.
This is something else, I think.

---

From: Marco Pontello <[email-masked]>
Date: Mon, 18 Jan 2016 20:10:30 +0100

>> 2MzQwSSnBHWHqSAqtTVQ6v47XtaisrJa1Vc (Testnet script hash)
Well I took the examples from here:
https://en.bitcoin.it/wiki/List_of_address_prefixes

But again, I would not want to go in low level details in the scheme spec,
both because I don't presume to having any deep knowledge of them, and both
because it doesn't seems to add to the purpose. The common, hi-level
rappresentation of what is understood to be a Bitcoin (or Litecoin, or
Feathercoin, etc) address is what I'm after.

Bye!