URI scheme registration request: blockchain

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

URI scheme registration request: blockchain

Marco Pontello
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 <[hidden email]>
   Scheme creator: Marco Pontello <[hidden email]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Dirk-Willem van Gulik
On 10 Jan 2016, at 15:16, Marco Pontello <[hidden email]> wrote:

> Scheme syntax:
>    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.
_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
Hi!

On Sun, Jan 10, 2016 at 3:27 PM, Dirk-Willem van Gulik <[hidden email]> wrote:
On 10 Jan 2016, at 15:16, Marco Pontello <[hidden email]> wrote:

> Scheme syntax:
>    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.

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.

 
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).


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

        file:///foo.txt

        v.s

        file:foo.txt

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:


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.


 
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 ?

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!


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Dirk-Willem van Gulik
On 10 Jan 2016, at 16:29, Marco Pontello <[hidden email]> wrote:
...
>> 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).
>>
> Yes, exactly.

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


>  How would you compare this to (e.g. file) the commonly used:
>
>         file:///foo.txt
>
>         v.s
>
>         file:foo.txt
>
> 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:
>
> 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

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.
>  
>> 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 ?

> 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.
       



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello


On Sun, Jan 10, 2016 at 4:37 PM, Dirk-Willem van Gulik <[hidden email]> wrote:
>  How would you compare this to (e.g. file) the commonly used:
>
>         file:///foo.txt
>
>         v.s
>
>         file:foo.txt
>
> 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:
>
> 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

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:



 
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.

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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Melvin Carvalho
In reply to this post by Marco Pontello


On 10 January 2016 at 15:16, Marco Pontello <[hidden email]> wrote:
Hello!

This is a request for a new URI scheme.
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:

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.
 


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 <[hidden email]>
   Scheme creator: Marco Pontello <[hidden email]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):

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



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
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 <[hidden email]> wrote:


On 10 January 2016 at 15:16, Marco Pontello <[hidden email]> wrote:
Hello!

This is a request for a new URI scheme.
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:

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.
 


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 <[hidden email]>
   Scheme creator: Marco Pontello <[hidden email]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):

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





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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Melvin Carvalho


On 10 January 2016 at 17:58, Marco Pontello <[hidden email]> wrote:
Hi Melvin!

I wasn't aware of rfc6920, and an (admittedly quick) read make me think 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.
 

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.

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.
 

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.

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. 
 

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?

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?
 

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.

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*. 
 
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.

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.

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.
 


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).


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 <[hidden email]> wrote:


On 10 January 2016 at 15:16, Marco Pontello <[hidden email]> wrote:
Hello!

This is a request for a new URI scheme.
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:

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.
 


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 <[hidden email]>
   Scheme creator: Marco Pontello <[hidden email]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):

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





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


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
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 <[hidden email]> wrote:


On 10 January 2016 at 17:58, Marco Pontello <[hidden email]> wrote:
Hi Melvin!

I wasn't aware of rfc6920, and an (admittedly quick) read make me think 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.
 

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.

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.
 

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.

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. 
 

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?

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?
 

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.

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*. 
 
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.

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.

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.
 


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).


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 <[hidden email]> wrote:


On 10 January 2016 at 15:16, Marco Pontello <[hidden email]> wrote:
Hello!

This is a request for a new URI scheme.
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:

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.
 


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 <[hidden email]>
   Scheme creator: Marco Pontello <[hidden email]>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):

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





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




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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Martin J. Dürst
In reply to this post by Marco Pontello
On 2016/01/11 00:29, Marco Pontello wrote:

> On Sun, Jan 10, 2016 at 3:27 PM, Dirk-Willem van Gulik <[hidden email]
>> 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.

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.

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
On Mon, Jan 11, 2016 at 2:55 AM, Martin J. Dürst <[hidden email]> wrote:

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.

Will do, thanks!
Bye!


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Graham Klyne-2
In reply to this post by Marco Pontello
On 10/01/2016 16:08, Marco Pontello wrote:
> 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
--

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
In reply to this post by Marco Pontello
Hello again!

Here's the updated request for the URI scheme.


Scheme name:
  blockchain 

Status:
  Provisional

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

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

Author/Change controller:
  Same as contact.

References:
  BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

  Simple test handler / demo (sort of a blockchain explorer proxy):

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

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.

Interoperability considerations:
  None.

Security considerations:
  None known or expected.


Thanks again for the attention!
Bye!

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Dirk-Willem van Gulik
On 13 Jan 2016, at 11:58, Marco Pontello <[hidden email]> wrote:
..
References:
  BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:
  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’.

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

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 ?

  blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" integer
  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).


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.

So you consider <a href="bitcoin://%443289741289471239" class="">bitcoin://%443289741289471239 etc.. an invalid one - as encoding/escaping is not permitted ?

Correct ?

Interoperability considerations:
  None.

Security considerations:
  None known or expected.

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
=


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain (resent, ascii formatted)

Dirk-Willem van Gulik
On 13 Jan 2016, at 11:58, Marco Pontello <[hidden email]> wrote:
..
References:
  BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:
  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’.

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

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 ?

  blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" integer
  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).


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.

So you consider <a href="bitcoin://%443289741289471239" class="">bitcoin://%443289741289471239 etc.. an invalid one - as encoding/escaping is not permitted ?

Correct ?

Interoperability considerations:
  None.

Security considerations:
  None known or expected.

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 |  55 | = |
+----+----+---+----+----+---+----+-----+---+---------+-----+---+

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Alexey Melnikov
In reply to this post by Marco Pontello
Hi Marco,

On 13/01/2016 10:58, Marco Pontello wrote:
> Scheme syntax:
> blockchain:[//<chain>]/<tx|block|address>/<hash>
>
>   blockchainuri = bc-scheme ":" bc-hier-part
>   bc-scheme = "blockchain"
>   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 "//".
>   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
>

Best Regards,
Alexey

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Adrian Hope-Bailie
Hi Alexey,

On 14 January 2016 at 20:17, Alexey Melnikov <[hidden email]> wrote:
Hi Marco,

On 13/01/2016 10:58, Marco Pontello wrote:
Scheme syntax:
blockchain:[//<chain>]/<tx|block|address>/<hash>

  blockchainuri = bc-scheme ":" bc-hier-part
  bc-scheme = "blockchain"
  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 "//".

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
  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


Best Regards,
Alexey


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


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Ted Hardie-2
On Thu, Jan 14, 2016 at 11:31 AM, Adrian Hope-Bailie <[hidden email]> wrote:
Hi Alexey,

On 14 January 2016 at 20:17, Alexey Melnikov <[hidden email]> wrote:
Hi Marco,

On 13/01/2016 10:58, Marco Pontello wrote:
Scheme syntax:
blockchain:[//<chain>]/<tx|block|address>/<hash>

  blockchainuri = bc-scheme ":" bc-hier-part
  bc-scheme = "blockchain"
  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 "//".

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


​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​


 
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
  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


Best Regards,
Alexey


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


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



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Marco Pontello
In reply to this post by Dirk-Willem van Gulik
Hi again. Sorry for the late reply.

On Wed, Jan 13, 2016 at 2:26 PM, Dirk-Willem van Gulik <[hidden email]> wrote:
On 13 Jan 2016, at 11:58, Marco Pontello <[hidden email]> wrote:
..
References:
  BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:
  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’.

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.
 
  blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" integer
  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). 

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 about endianness.

OK.

 

Encoding considerations:
  US-ASCII.
  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 ?

Yes!


Interoperability considerations:
  None.

Security considerations:
  None known or expected.

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!


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request: blockchain

Dirk-Willem van Gulik
On 17 Jan 2016, at 15:10, Marco Pontello <[hidden email]> wrote:

>>   blockheight = 1*15DIGIT ; 15 is somehow arbitrary, i.e. a "small" integer
>>   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).
>
> 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?

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




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