* [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
@ 2015-08-29 11:48 Marco Pontello
2015-08-29 16:31 ` Richard Moore
2015-11-15 2:14 ` Marco Pontello
0 siblings, 2 replies; 32+ messages in thread
From: Marco Pontello @ 2015-08-29 11:48 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hi!
My first post here, hope I'm following the right conventions.
I had this humble idea for a while, so I thought to go ahead and propose
it.
BIP: XX
Title: URI scheme for Blockchain exploration
Author: Marco Pontello
Status: Draft
Type: Standards Track
Created: 29 August 2015
Abstract
========
This BIP propose a simple URI scheme for looking up blocks, transactions,
addresses on a Blockchain explorer.
Motivation
==========
The purpose of this URI scheme is to enable users to handle all the
requests for details about blocks, transactions, etc. with their preferred
tool (being that a web service or a local application).
Currently a Bitcoin client usually point to an arbitrary blockchain
explorer when the user look for the details of a transaction (es. Bitcoin
Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
Other times resorting to cut&paste is needed.
The same happens with posts and messages that reference some particular
txs or blocks, if they provide links at all.
Specification
=============
The URI follow this simple form:
blockchain: <hash/string>
Examples:
blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
Rationale
=========
I thought about using some more complex scheme, or adding qualifiers to
distinguish blocks from txs, but in the end I think that keeping it simple
should be practical enough. Blockchain explorers can apply the same
disambiguation rules they are already using to process the usual search
box.
From the point of view of a wallet developer (or other tool that need to
show any kind of Blockchain references), using this scheme mean that he
can simply make it a blockchain: link and be done with it, without having
to worry about any specific Blockchain explorer or provide a means for the
user to select one.
Blockchain explorers in turn will simply offer to handle the blockchain:
URI, the first time the user visit their website, or launch/install the
application, or even set themselves if there isn't already one.
Users get the convenience of using always their preferred explorer, which
can be especially handy on mobile devices, where juggling with cut&paste
is far from ideal.
[-- Attachment #2: Type: text/html, Size: 3053 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 11:48 [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration Marco Pontello
@ 2015-08-29 16:31 ` Richard Moore
2015-08-29 17:19 ` Matt Whitlock
` (2 more replies)
2015-11-15 2:14 ` Marco Pontello
1 sibling, 3 replies; 32+ messages in thread
From: Richard Moore @ 2015-08-29 16:31 UTC (permalink / raw)
To: Marco Pontello; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4362 bytes --]
I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://block/189000
blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 6134 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 16:31 ` Richard Moore
@ 2015-08-29 17:19 ` Matt Whitlock
2015-08-29 19:24 ` Richard Moore
2015-08-29 18:07 ` Andreas Schildbach
2015-08-29 18:58 ` Btc Drak
2 siblings, 1 reply; 32+ messages in thread
From: Matt Whitlock @ 2015-08-29 17:19 UTC (permalink / raw)
To: bitcoin-dev, Richard Moore
bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI (a.k.a. a URL); rather, it's an opaque URI.
And your suggestion is actually in violation of the URI spec, since "blockhash", "txid", "block", and "address" are not host names.
More correct would be:
blockchain:?blockhash=00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain:?block=189000
blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
>
> A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
>
> The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
>
> > On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > Hi!
> > My first post here, hope I'm following the right conventions.
> > I had this humble idea for a while, so I thought to go ahead and propose
> > it.
> >
> > BIP: XX
> > Title: URI scheme for Blockchain exploration
> > Author: Marco Pontello
> > Status: Draft
> > Type: Standards Track
> > Created: 29 August 2015
> >
> > Abstract
> > ========
> > This BIP propose a simple URI scheme for looking up blocks, transactions,
> > addresses on a Blockchain explorer.
> >
> > Motivation
> > ==========
> > The purpose of this URI scheme is to enable users to handle all the
> > requests for details about blocks, transactions, etc. with their preferred
> > tool (being that a web service or a local application).
> >
> > Currently a Bitcoin client usually point to an arbitrary blockchain
> > explorer when the user look for the details of a transaction (es. Bitcoin
> > Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> > Other times resorting to cut&paste is needed.
> > The same happens with posts and messages that reference some particular
> > txs or blocks, if they provide links at all.
> >
> > Specification
> > =============
> > The URI follow this simple form:
> >
> > blockchain: <hash/string>
> >
> > Examples:
> >
> > blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> > blockchain:001949
> > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >
> > Rationale
> > =========
> > I thought about using some more complex scheme, or adding qualifiers to
> > distinguish blocks from txs, but in the end I think that keeping it simple
> > should be practical enough. Blockchain explorers can apply the same
> > disambiguation rules they are already using to process the usual search
> > box.
> >
> > From the point of view of a wallet developer (or other tool that need to
> > show any kind of Blockchain references), using this scheme mean that he
> > can simply make it a blockchain: link and be done with it, without having
> > to worry about any specific Blockchain explorer or provide a means for the
> > user to select one.
> >
> > Blockchain explorers in turn will simply offer to handle the blockchain:
> > URI, the first time the user visit their website, or launch/install the
> > application, or even set themselves if there isn't already one.
> >
> > Users get the convenience of using always their preferred explorer, which
> > can be especially handy on mobile devices, where juggling with cut&paste
> > is far from ideal.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 16:31 ` Richard Moore
2015-08-29 17:19 ` Matt Whitlock
@ 2015-08-29 18:07 ` Andreas Schildbach
2015-09-01 14:33 ` Marco Pontello
2015-08-29 18:58 ` Btc Drak
2 siblings, 1 reply; 32+ messages in thread
From: Andreas Schildbach @ 2015-08-29 18:07 UTC (permalink / raw)
To: bitcoin-dev
On 08/29/2015 06:31 PM, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and
> even core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to
> include the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
Good thinking! It might make sense to look at the existing de-facto
standard (e.g. blockexplorer.com, blockchain.info):
/tx/ for transactions
/block/ for blocks, supports both hash or height
/address/ for address
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 16:31 ` Richard Moore
2015-08-29 17:19 ` Matt Whitlock
2015-08-29 18:07 ` Andreas Schildbach
@ 2015-08-29 18:58 ` Btc Drak
2015-08-29 19:01 ` Matt Whitlock
2015-08-29 19:28 ` Richard Moore
2 siblings, 2 replies; 32+ messages in thread
From: Btc Drak @ 2015-08-29 18:58 UTC (permalink / raw)
To: Richard Moore; +Cc: bitcoin-dev
What about supporting different networks? What if I want to look up
testnet for example?
blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
or
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I like the idea of having a standard for this, that all explorers (and even
> core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to include
> the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> I think this would help the URI be more human understandable as well as give
> the explorers the ability to optimize a bit what they are looking for when
> hitting various databases.
>
> A possible future path could also include blockchain://tx/123000/4 for block
> height, tx index... Another possibility could be blockchain://version which
> would return a list of supported paths, version of the BIP supported, etc.
>
> The BIP should also specify little endian searching. I'm not sure, but would
> it also make sense for this BIP to include what the return results should
> look like? Maybe another, related BIP.
>
> RicMoo
>
> Sent from my self-aware iPhone
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software Inc.
> phone: (778) 882-6125
> email: ricmoo@geneticmistakes•com
> www: http://GeneticMistakes.com
>
> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 18:58 ` Btc Drak
@ 2015-08-29 19:01 ` Matt Whitlock
2015-08-29 20:10 ` Jorge Timón
2015-08-29 19:28 ` Richard Moore
1 sibling, 1 reply; 32+ messages in thread
From: Matt Whitlock @ 2015-08-29 19:01 UTC (permalink / raw)
To: bitcoin-dev, Btc Drak
That's still not right, since "mainnet" and "testnet" are not host names.
You'd have to do something like:
blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
On Saturday, 29 August 2015, at 7:58 pm, Btc Drak via bitcoin-dev wrote:
> What about supporting different networks? What if I want to look up
> testnet for example?
>
> blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> or
>
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
>
> On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I like the idea of having a standard for this, that all explorers (and even
> > core, eventually) would understand.
> >
> > I would recommend 2 changes though. First, using a real URI scheme,
> > blockchain:// so that we can just use normal URL parsing libraries. The
> > bitcoin: thing leads to additional code to mutate it into a proper URI
> > before passing it to URL parsing. And I think it would be fine to include
> > the type looking up. For example:
> >
> > blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> > blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> > blockchain://block/189000
> > blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
> >
> > I think this would help the URI be more human understandable as well as give
> > the explorers the ability to optimize a bit what they are looking for when
> > hitting various databases.
> >
> > A possible future path could also include blockchain://tx/123000/4 for block
> > height, tx index... Another possibility could be blockchain://version which
> > would return a list of supported paths, version of the BIP supported, etc.
> >
> > The BIP should also specify little endian searching. I'm not sure, but would
> > it also make sense for this BIP to include what the return results should
> > look like? Maybe another, related BIP.
> >
> > RicMoo
> >
> > Sent from my self-aware iPhone
> >
> > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
> >
> > Richard Moore ~ Founder
> > Genetic Mistakes Software Inc.
> > phone: (778) 882-6125
> > email: ricmoo@geneticmistakes•com
> > www: http://GeneticMistakes.com
> >
> > On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > Hi!
> > My first post here, hope I'm following the right conventions.
> > I had this humble idea for a while, so I thought to go ahead and propose
> > it.
> >
> > BIP: XX
> > Title: URI scheme for Blockchain exploration
> > Author: Marco Pontello
> > Status: Draft
> > Type: Standards Track
> > Created: 29 August 2015
> >
> > Abstract
> > ========
> > This BIP propose a simple URI scheme for looking up blocks, transactions,
> > addresses on a Blockchain explorer.
> >
> > Motivation
> > ==========
> > The purpose of this URI scheme is to enable users to handle all the
> > requests for details about blocks, transactions, etc. with their preferred
> > tool (being that a web service or a local application).
> >
> > Currently a Bitcoin client usually point to an arbitrary blockchain
> > explorer when the user look for the details of a transaction (es. Bitcoin
> > Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> > Other times resorting to cut&paste is needed.
> > The same happens with posts and messages that reference some particular
> > txs or blocks, if they provide links at all.
> >
> > Specification
> > =============
> > The URI follow this simple form:
> >
> > blockchain: <hash/string>
> >
> > Examples:
> >
> > blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> > blockchain:001949
> > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >
> > Rationale
> > =========
> > I thought about using some more complex scheme, or adding qualifiers to
> > distinguish blocks from txs, but in the end I think that keeping it simple
> > should be practical enough. Blockchain explorers can apply the same
> > disambiguation rules they are already using to process the usual search
> > box.
> >
> > From the point of view of a wallet developer (or other tool that need to
> > show any kind of Blockchain references), using this scheme mean that he
> > can simply make it a blockchain: link and be done with it, without having
> > to worry about any specific Blockchain explorer or provide a means for the
> > user to select one.
> >
> > Blockchain explorers in turn will simply offer to handle the blockchain:
> > URI, the first time the user visit their website, or launch/install the
> > application, or even set themselves if there isn't already one.
> >
> > Users get the convenience of using always their preferred explorer, which
> > can be especially handy on mobile devices, where juggling with cut&paste
> > is far from ideal.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 17:19 ` Matt Whitlock
@ 2015-08-29 19:24 ` Richard Moore
0 siblings, 0 replies; 32+ messages in thread
From: Richard Moore @ 2015-08-29 19:24 UTC (permalink / raw)
To: Matt Whitlock; +Cc: bitcoin-dev
I apologize, you are correct, I should not have used the word "real".
However, if you look at section 3 of the RFC, the first hierarchal level (which in http is used to describe hosts) can be any "authority", not necessarily a hostname.
So, you could use tx, block, address, etc. as the authority for their paths.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 1:19 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
>
> bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical URI (a.k.a. a URL); rather, it's an opaque URI.
>
> And your suggestion is actually in violation of the URI spec, since "blockhash", "txid", "block", and "address" are not host names.
>
> More correct would be:
>
> blockchain:?blockhash=00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:?txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain:?block=189000
> blockchain:?address=1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986
>
>
>> On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev wrote:
>> I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
>>
>> I would recommend 2 changes though. First, using a real URI scheme, blockchain:// so that we can just use normal URL parsing libraries. The bitcoin: thing leads to additional code to mutate it into a proper URI before passing it to URL parsing. And I think it would be fine to include the type looking up. For example:
>>
>> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>>
>> I think this would help the URI be more human understandable as well as give the explorers the ability to optimize a bit what they are looking for when hitting various databases.
>>
>> A possible future path could also include blockchain://tx/123000/4 for block height, tx index... Another possibility could be blockchain://version which would return a list of supported paths, version of the BIP supported, etc.
>>
>> The BIP should also specify little endian searching. I'm not sure, but would it also make sense for this BIP to include what the return results should look like? Maybe another, related BIP.
>>
>>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> Hi!
>>> My first post here, hope I'm following the right conventions.
>>> I had this humble idea for a while, so I thought to go ahead and propose
>>> it.
>>>
>>> BIP: XX
>>> Title: URI scheme for Blockchain exploration
>>> Author: Marco Pontello
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 29 August 2015
>>>
>>> Abstract
>>> ========
>>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>>> addresses on a Blockchain explorer.
>>>
>>> Motivation
>>> ==========
>>> The purpose of this URI scheme is to enable users to handle all the
>>> requests for details about blocks, transactions, etc. with their preferred
>>> tool (being that a web service or a local application).
>>>
>>> Currently a Bitcoin client usually point to an arbitrary blockchain
>>> explorer when the user look for the details of a transaction (es. Bitcoin
>>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>>> Other times resorting to cut&paste is needed.
>>> The same happens with posts and messages that reference some particular
>>> txs or blocks, if they provide links at all.
>>>
>>> Specification
>>> =============
>>> The URI follow this simple form:
>>>
>>> blockchain: <hash/string>
>>>
>>> Examples:
>>>
>>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>>> blockchain:001949
>>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>>
>>> Rationale
>>> =========
>>> I thought about using some more complex scheme, or adding qualifiers to
>>> distinguish blocks from txs, but in the end I think that keeping it simple
>>> should be practical enough. Blockchain explorers can apply the same
>>> disambiguation rules they are already using to process the usual search
>>> box.
>>>
>>> From the point of view of a wallet developer (or other tool that need to
>>> show any kind of Blockchain references), using this scheme mean that he
>>> can simply make it a blockchain: link and be done with it, without having
>>> to worry about any specific Blockchain explorer or provide a means for the
>>> user to select one.
>>>
>>> Blockchain explorers in turn will simply offer to handle the blockchain:
>>> URI, the first time the user visit their website, or launch/install the
>>> application, or even set themselves if there isn't already one.
>>>
>>> Users get the convenience of using always their preferred explorer, which
>>> can be especially handy on mobile devices, where juggling with cut&paste
>>> is far from ideal.
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 18:58 ` Btc Drak
2015-08-29 19:01 ` Matt Whitlock
@ 2015-08-29 19:28 ` Richard Moore
2015-09-01 14:51 ` Marco Pontello
1 sibling, 1 reply; 32+ messages in thread
From: Richard Moore @ 2015-08-29 19:28 UTC (permalink / raw)
To: Btc Drak; +Cc: bitcoin-dev
Yes! Good point, network should be encoded. Not sure I like this format yet, but what if it was part of the authority, like block:testnet. Like http uses port 80 by default, you could have block by default refer to block:mainnet.
Eg.
blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
I will read the RFC over more thoroughly tomorrow to get an idea of what types of things make more or less sense.
RicMoo
Sent from my self-aware iPhone
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software Inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com
www: http://GeneticMistakes.com
> On Aug 29, 2015, at 2:58 PM, Btc Drak <btcdrak@gmail•com> wrote:
>
> What about supporting different networks? What if I want to look up
> testnet for example?
>
> blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> or
>
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
>
> On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> I like the idea of having a standard for this, that all explorers (and even
>> core, eventually) would understand.
>>
>> I would recommend 2 changes though. First, using a real URI scheme,
>> blockchain:// so that we can just use normal URL parsing libraries. The
>> bitcoin: thing leads to additional code to mutate it into a proper URI
>> before passing it to URL parsing. And I think it would be fine to include
>> the type looking up. For example:
>>
>> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> blockchain://block/189000
>> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>>
>> I think this would help the URI be more human understandable as well as give
>> the explorers the ability to optimize a bit what they are looking for when
>> hitting various databases.
>>
>> A possible future path could also include blockchain://tx/123000/4 for block
>> height, tx index... Another possibility could be blockchain://version which
>> would return a list of supported paths, version of the BIP supported, etc.
>>
>> The BIP should also specify little endian searching. I'm not sure, but would
>> it also make sense for this BIP to include what the return results should
>> look like? Maybe another, related BIP.
>>
>> RicMoo
>>
>> Sent from my self-aware iPhone
>>
>> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>>
>> Richard Moore ~ Founder
>> Genetic Mistakes Software Inc.
>> phone: (778) 882-6125
>> email: ricmoo@geneticmistakes•com
>> www: http://GeneticMistakes.com
>>
>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Hi!
>> My first post here, hope I'm following the right conventions.
>> I had this humble idea for a while, so I thought to go ahead and propose
>> it.
>>
>> BIP: XX
>> Title: URI scheme for Blockchain exploration
>> Author: Marco Pontello
>> Status: Draft
>> Type: Standards Track
>> Created: 29 August 2015
>>
>> Abstract
>> ========
>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>> addresses on a Blockchain explorer.
>>
>> Motivation
>> ==========
>> The purpose of this URI scheme is to enable users to handle all the
>> requests for details about blocks, transactions, etc. with their preferred
>> tool (being that a web service or a local application).
>>
>> Currently a Bitcoin client usually point to an arbitrary blockchain
>> explorer when the user look for the details of a transaction (es. Bitcoin
>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> Other times resorting to cut&paste is needed.
>> The same happens with posts and messages that reference some particular
>> txs or blocks, if they provide links at all.
>>
>> Specification
>> =============
>> The URI follow this simple form:
>>
>> blockchain: <hash/string>
>>
>> Examples:
>>
>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain:001949
>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>
>> Rationale
>> =========
>> I thought about using some more complex scheme, or adding qualifiers to
>> distinguish blocks from txs, but in the end I think that keeping it simple
>> should be practical enough. Blockchain explorers can apply the same
>> disambiguation rules they are already using to process the usual search
>> box.
>>
>> From the point of view of a wallet developer (or other tool that need to
>> show any kind of Blockchain references), using this scheme mean that he
>> can simply make it a blockchain: link and be done with it, without having
>> to worry about any specific Blockchain explorer or provide a means for the
>> user to select one.
>>
>> Blockchain explorers in turn will simply offer to handle the blockchain:
>> URI, the first time the user visit their website, or launch/install the
>> application, or even set themselves if there isn't already one.
>>
>> Users get the convenience of using always their preferred explorer, which
>> can be especially handy on mobile devices, where juggling with cut&paste
>> is far from ideal.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 19:01 ` Matt Whitlock
@ 2015-08-29 20:10 ` Jorge Timón
2015-08-30 2:02 ` Chun Wang
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: Jorge Timón @ 2015-08-29 20:10 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> That's still not right, since "mainnet" and "testnet" are not host names.
>
> You'd have to do something like:
>
> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
I would really prefer chain=<chainID> over network=<chainPetnameStr>
By chainID I mean the hash of the genesis block, see
https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
I'm completely fine with doing that using an optional parameter (for
backwards compatibility).
I agree with Andreas Schildbach that respecting the most commonly used
schemes is desirable.
So my preference would be:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
(a tx in testnet)
/block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
(a block in bitcoin's mainnet)
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 20:10 ` Jorge Timón
@ 2015-08-30 2:02 ` Chun Wang
2015-08-30 2:20 ` Jorge Timón
2015-09-01 14:49 ` Marco Pontello
2015-09-01 16:12 ` Danny Thorpe
2 siblings, 1 reply; 32+ messages in thread
From: Chun Wang @ 2015-08-30 2:02 UTC (permalink / raw)
Cc: Bitcoin Dev
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Some altcoins (LTC and FTC for example) have the same genesis block hash.
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> That's still not right, since "mainnet" and "testnet" are not host names.
>>
>> You'd have to do something like:
>>
>> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I would really prefer chain=<chainID> over network=<chainPetnameStr>
> By chainID I mean the hash of the genesis block, see
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
> I agree with Andreas Schildbach that respecting the most commonly used
> schemes is desirable.
> So my preference would be:
>
> /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
> /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> (a block in bitcoin's mainnet)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-30 2:02 ` Chun Wang
@ 2015-08-30 2:20 ` Jorge Timón
2015-09-01 22:56 ` Btc Drak
0 siblings, 1 reply; 32+ messages in thread
From: Jorge Timón @ 2015-08-30 2:20 UTC (permalink / raw)
To: Chun Wang; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
On Aug 29, 2015 7:02 PM, "Chun Wang via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
> >
> > (a tx in testnet)
> >
> >
/block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> Some altcoins (LTC and FTC for example) have the same genesis block hash.
That's obviously a design mistake in FTC, but it's not unsolvable. FTC
could move their genesis block to the next block (or the first one that is
not identical to LTC's).
Bitcoin and all its test chains have different genesis blocks, so I'm not
sure FTC should be a concern for a BIP anyway...
[-- Attachment #2: Type: text/html, Size: 1204 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 18:07 ` Andreas Schildbach
@ 2015-09-01 14:33 ` Marco Pontello
0 siblings, 0 replies; 32+ messages in thread
From: Marco Pontello @ 2015-09-01 14:33 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
That surely make sense.
A URI like that perfectly readable, unambiguous and simple enough.
And nice to see a Wallet developer showing interest for this! :)
On Sat, Aug 29, 2015 at 8:07 PM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 08/29/2015 06:31 PM, Richard Moore via bitcoin-dev wrote:
>
> > I like the idea of having a standard for this, that all explorers (and
> > even core, eventually) would understand.
> >
> > I would recommend 2 changes though. First, using a real URI scheme,
> > blockchain:// so that we can just use normal URL parsing libraries. The
> > bitcoin: thing leads to additional code to mutate it into a proper URI
> > before passing it to URL parsing. And I think it would be fine to
> > include the type looking up. For example:
> >
> >
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> > blockchain://block/189000
> > blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> Good thinking! It might make sense to look at the existing de-facto
> standard (e.g. blockexplorer.com, blockchain.info):
>
> /tx/ for transactions
> /block/ for blocks, supports both hash or height
> /address/ for address
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 2551 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 20:10 ` Jorge Timón
2015-08-30 2:02 ` Chun Wang
@ 2015-09-01 14:49 ` Marco Pontello
2015-09-01 21:16 ` Matt Whitlock
2015-09-01 16:12 ` Danny Thorpe
2 siblings, 1 reply; 32+ messages in thread
From: Marco Pontello @ 2015-09-01 14:49 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> I would really prefer chain=<chainID> over network=<chainPetnameStr>
> By chainID I mean the hash of the genesis block, see
>
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
I see that using the genesis block hash would be the perfectly rigorous way
to do it, but what do you think about the possibility of letting also use
the name constants, as a simple / more relaxed alternative? That would
spare a source lookup just to write a correct reference to a tx, maybe in a
forum or a post.
So a reference to a certain tx could be either:
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
(or a different element name maybe)
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 2041 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 19:28 ` Richard Moore
@ 2015-09-01 14:51 ` Marco Pontello
0 siblings, 0 replies; 32+ messages in thread
From: Marco Pontello @ 2015-09-01 14:51 UTC (permalink / raw)
To: Richard Moore; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
On Sat, Aug 29, 2015 at 9:28 PM, Richard Moore <me@ricmoo•com> wrote:
> Yes! Good point, network should be encoded. Not sure I like this format
> yet, but what if it was part of the authority, like block:testnet. Like
> http uses port 80 by default, you could have block by default refer to
> block:mainnet.
>
> Eg.
>
> blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I will read the RFC over more thoroughly tomorrow to get an idea of what
> types of things make more or less sense.
Like this option too!
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 1074 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 20:10 ` Jorge Timón
2015-08-30 2:02 ` Chun Wang
2015-09-01 14:49 ` Marco Pontello
@ 2015-09-01 16:12 ` Danny Thorpe
2015-09-01 22:59 ` Btc Drak
2 siblings, 1 reply; 32+ messages in thread
From: Danny Thorpe @ 2015-09-01 16:12 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
Rather than using an inhumanly long hex string from the genesis hash to
distinguish between mainnet and testnet, why not use the network magic
bytes instead? Much shorter, just as distinct.
I'd still prefer a common network name mapping for the sake of humanity.
Few bitcoin library implementations use the same string names for mainnet
and testnet. This BIP could simply define one string name alias for each
supported network and leave mapping to local lingo to the implementors.
-Danny
On Sat, Aug 29, 2015 at 1:10 PM, Jorge Timón <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > That's still not right, since "mainnet" and "testnet" are not host names.
> >
> > You'd have to do something like:
> >
> >
> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I would really prefer chain=<chainID> over network=<chainPetnameStr>
> By chainID I mean the hash of the genesis block, see
>
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
> I agree with Andreas Schildbach that respecting the most commonly used
> schemes is desirable.
> So my preference would be:
>
>
> /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
>
> /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> (a block in bitcoin's mainnet)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2851 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 14:49 ` Marco Pontello
@ 2015-09-01 21:16 ` Matt Whitlock
2015-09-01 21:25 ` Esteban Ordano
` (2 more replies)
0 siblings, 3 replies; 32+ messages in thread
From: Matt Whitlock @ 2015-09-01 21:16 UTC (permalink / raw)
To: Marco Pontello; +Cc: Bitcoin Dev
Isn't this all backward? The "authority" component of the URL should identify the chain, and the "path" component should identify the particular block, tx, or address in that chain.
So instead of:
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
It should be:
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
And I would agree with allowing well-known chains to register a name, to be used as an alternative to the literal, hash syntax:
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> >
> > I would really prefer chain=<chainID> over network=<chainPetnameStr>
> > By chainID I mean the hash of the genesis block, see
> >
> > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > I'm completely fine with doing that using an optional parameter (for
> > backwards compatibility).
> >
>
> I see that using the genesis block hash would be the perfectly rigorous way
> to do it, but what do you think about the possibility of letting also use
> the name constants, as a simple / more relaxed alternative? That would
> spare a source lookup just to write a correct reference to a tx, maybe in a
> forum or a post.
>
> So a reference to a certain tx could be either:
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
>
> (or a different element name maybe)
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 21:16 ` Matt Whitlock
@ 2015-09-01 21:25 ` Esteban Ordano
2015-09-01 21:38 ` Marco Pontello
2015-09-01 22:46 ` Jorge Timón
2 siblings, 0 replies; 32+ messages in thread
From: Esteban Ordano @ 2015-09-01 21:25 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]
Slightly relevant: standardization of http queries to blockchain explorers.
It's not just about URLs, it's about the query body and response.
https://github.com/common-blockchain
On Tue, Sep 1, 2015 at 6:16 PM, Matt Whitlock via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Isn't this all backward? The "authority" component of the URL should
> identify the chain, and the "path" component should identify the particular
> block, tx, or address in that chain.
>
> So instead of:
>
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> It should be:
>
>
> blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
> And I would agree with allowing well-known chains to register a name, to
> be used as an alternative to the literal, hash syntax:
>
>
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
>
> On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > >
> > > I would really prefer chain=<chainID> over network=<chainPetnameStr>
> > > By chainID I mean the hash of the genesis block, see
> > >
> > >
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > > I'm completely fine with doing that using an optional parameter (for
> > > backwards compatibility).
> > >
> >
> > I see that using the genesis block hash would be the perfectly rigorous
> way
> > to do it, but what do you think about the possibility of letting also use
> > the name constants, as a simple / more relaxed alternative? That would
> > spare a source lookup just to write a correct reference to a tx, maybe
> in a
> > forum or a post.
> >
> > So a reference to a certain tx could be either:
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> >
> >
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> >
> > (or a different element name maybe)
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3848 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 21:16 ` Matt Whitlock
2015-09-01 21:25 ` Esteban Ordano
@ 2015-09-01 21:38 ` Marco Pontello
2015-09-01 21:42 ` Matt Whitlock
2015-09-01 22:46 ` Jorge Timón
2 siblings, 1 reply; 32+ messages in thread
From: Marco Pontello @ 2015-09-01 21:38 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]
I see your point. But I personally like that the chain part could be
optional, given that the vast majority of the references in the end will be
to Bitcoin main net.
On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock <bip@mattwhitlock•name>
wrote:
> Isn't this all backward? The "authority" component of the URL should
> identify the chain, and the "path" component should identify the particular
> block, tx, or address in that chain.
>
> So instead of:
>
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> It should be:
>
>
> blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
> And I would agree with allowing well-known chains to register a name, to
> be used as an alternative to the literal, hash syntax:
>
>
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
>
> On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > >
> > > I would really prefer chain=<chainID> over network=<chainPetnameStr>
> > > By chainID I mean the hash of the genesis block, see
> > >
> > >
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > > I'm completely fine with doing that using an optional parameter (for
> > > backwards compatibility).
> > >
> >
> > I see that using the genesis block hash would be the perfectly rigorous
> way
> > to do it, but what do you think about the possibility of letting also use
> > the name constants, as a simple / more relaxed alternative? That would
> > spare a source lookup just to write a correct reference to a tx, maybe
> in a
> > forum or a post.
> >
> > So a reference to a certain tx could be either:
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> >
> >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> >
> >
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> >
> > (or a different element name maybe)
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 3527 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 21:38 ` Marco Pontello
@ 2015-09-01 21:42 ` Matt Whitlock
2015-09-01 21:43 ` Marco Pontello
0 siblings, 1 reply; 32+ messages in thread
From: Matt Whitlock @ 2015-09-01 21:42 UTC (permalink / raw)
To: Marco Pontello; +Cc: Bitcoin Dev
The authority part in a URI is optional.
blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Notice the lack of a double-slash.
On Tuesday, 1 September 2015, at 11:38 pm, Marco Pontello wrote:
> I see your point. But I personally like that the chain part could be
> optional, given that the vast majority of the references in the end will be
> to Bitcoin main net.
>
> On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock <bip@mattwhitlock•name>
> wrote:
>
> > Isn't this all backward? The "authority" component of the URL should
> > identify the chain, and the "path" component should identify the particular
> > block, tx, or address in that chain.
> >
> > So instead of:
> >
> >
> > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> >
> > It should be:
> >
> >
> > blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> >
> > And I would agree with allowing well-known chains to register a name, to
> > be used as an alternative to the literal, hash syntax:
> >
> >
> > blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> >
> >
> > On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> > > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> > > bitcoin-dev@lists•linuxfoundation.org> wrote:
> > >
> > > >
> > > > I would really prefer chain=<chainID> over network=<chainPetnameStr>
> > > > By chainID I mean the hash of the genesis block, see
> > > >
> > > >
> > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > > > I'm completely fine with doing that using an optional parameter (for
> > > > backwards compatibility).
> > > >
> > >
> > > I see that using the genesis block hash would be the perfectly rigorous
> > way
> > > to do it, but what do you think about the possibility of letting also use
> > > the name constants, as a simple / more relaxed alternative? That would
> > > spare a source lookup just to write a correct reference to a tx, maybe
> > in a
> > > forum or a post.
> > >
> > > So a reference to a certain tx could be either:
> > >
> > >
> > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> > >
> > >
> > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> > >
> > >
> > blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> > >
> > > (or a different element name maybe)
> > >
> > > --
> > > Try the Online TrID File Identifier
> > > http://mark0.net/onlinetrid.aspx
> >
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 21:42 ` Matt Whitlock
@ 2015-09-01 21:43 ` Marco Pontello
0 siblings, 0 replies; 32+ messages in thread
From: Marco Pontello @ 2015-09-01 21:43 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3371 bytes --]
Oh, my bad! Right, sounds pretty good to me then.
On Tue, Sep 1, 2015 at 11:42 PM, Matt Whitlock <bip@mattwhitlock•name>
wrote:
> The authority part in a URI is optional.
>
>
> blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
>
> Notice the lack of a double-slash.
>
>
> On Tuesday, 1 September 2015, at 11:38 pm, Marco Pontello wrote:
> > I see your point. But I personally like that the chain part could be
> > optional, given that the vast majority of the references in the end will
> be
> > to Bitcoin main net.
> >
> > On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock <bip@mattwhitlock•name>
> > wrote:
> >
> > > Isn't this all backward? The "authority" component of the URL should
> > > identify the chain, and the "path" component should identify the
> particular
> > > block, tx, or address in that chain.
> > >
> > > So instead of:
> > >
> > >
> > >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> > >
> > > It should be:
> > >
> > >
> > >
> blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> > >
> > > And I would agree with allowing well-known chains to register a name,
> to
> > > be used as an alternative to the literal, hash syntax:
> > >
> > >
> > >
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> > >
> > >
> > > On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:
> > > > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
> > > > bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > >
> > > > >
> > > > > I would really prefer chain=<chainID> over
> network=<chainPetnameStr>
> > > > > By chainID I mean the hash of the genesis block, see
> > > > >
> > > > >
> > >
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> > > > > I'm completely fine with doing that using an optional parameter
> (for
> > > > > backwards compatibility).
> > > > >
> > > >
> > > > I see that using the genesis block hash would be the perfectly
> rigorous
> > > way
> > > > to do it, but what do you think about the possibility of letting
> also use
> > > > the name constants, as a simple / more relaxed alternative? That
> would
> > > > spare a source lookup just to write a correct reference to a tx,
> maybe
> > > in a
> > > > forum or a post.
> > > >
> > > > So a reference to a certain tx could be either:
> > > >
> > > >
> > >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
> > > >
> > > >
> > >
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> > > >
> > > >
> > >
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
> > > >
> > > > (or a different element name maybe)
> > > >
> > > > --
> > > > Try the Online TrID File Identifier
> > > > http://mark0.net/onlinetrid.aspx
> > >
> >
> >
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 4908 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 21:16 ` Matt Whitlock
2015-09-01 21:25 ` Esteban Ordano
2015-09-01 21:38 ` Marco Pontello
@ 2015-09-01 22:46 ` Jorge Timón
2015-09-01 23:25 ` Matt Whitlock
2 siblings, 1 reply; 32+ messages in thread
From: Jorge Timón @ 2015-09-01 22:46 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
On Tue, Sep 1, 2015 at 4:49 PM, Marco Pontello <marcopon@gmail•com> wrote:
>
> On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>
>> I would really prefer chain=<chainID> over network=<chainPetnameStr>
>> By chainID I mean the hash of the genesis block, see
>>
>> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
>> I'm completely fine with doing that using an optional parameter (for
>> backwards compatibility).
>
>
> I see that using the genesis block hash would be the perfectly rigorous way
> to do it, but what do you think about the possibility of letting also use
> the name constants, as a simple / more relaxed alternative? That would spare
> a source lookup just to write a correct reference to a tx, maybe in a forum
> or a post.
>
> So a reference to a certain tx could be either:
>
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
I'm fine with each explorer using whatever chain they prefer as default.
> blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
>
> (or a different element name maybe)
It would need to be a different argument, for example chainPetName.
On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> And I would agree with allowing well-known chains to register a name, to be used as an alternative to the literal, hash syntax:
>
> blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
But who is the central authority that registers the mnemonic names?
That's why I say petname, because no dictionary of supported chains
should be considered universally accepted and thus it will always be
just a local registry.
If we're chainPetName is supported, there should be an additional call
to query that local list. For example:
blockchain:/chains
JSON response:
{ "main": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
"test": "000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943",
"regtest": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206"}
It may be problematic when too many chains are supported. For example,
#6382 introduces std::numeric_limits<uint64_t>::max() new chains.
On Tue, Sep 1, 2015 at 6:12 PM, Danny Thorpe <danny.thorpe@gmail•com> wrote:
> Rather than using an inhumanly long hex string from the genesis hash to
> distinguish between mainnet and testnet, why not use the network magic bytes
> instead? Much shorter, just as distinct.
Obviously 4 bytes is not "as distinct" as 32 bytes. In #6382,
std::numeric_limits<uint64_t>::max() new chains share the same magic
bytes.
And again, there's no central authority to register unique magic
bytes. In contrast, producing a unique genesis block is trivial (look
how I produced std::numeric_limits<uint64_t>::max() new unique genesis
blocks in #6382).
> I'd still prefer a common network name mapping for the sake of humanity. Few
> bitcoin library implementations use the same string names for mainnet and
> testnet. This BIP could simply define one string name alias for each
> supported network and leave mapping to local lingo to the implementors.
There's many altcoins that call "testnet" to their own testnet. In
Bitcoin itself, we've been using "testnet" to refer to the original
testnet, testnet2 and testnet3.
But again, the main issue is that we don't want a central authority to
register unique unique and memorable chain name strings.
Relevant links:
https://en.wikipedia.org/wiki/Zooko%27s_triangle
http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-30 2:20 ` Jorge Timón
@ 2015-09-01 22:56 ` Btc Drak
0 siblings, 0 replies; 32+ messages in thread
From: Btc Drak @ 2015-09-01 22:56 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>> Some altcoins (LTC and FTC for example) have the same genesis block hash.
>
> That's obviously a design mistake in FTC, but it's not unsolvable. FTC could
> move their genesis block to the next block (or the first one that is not
> identical to LTC's).
>
> Bitcoin and all its test chains have different genesis blocks, so I'm not
> sure FTC should be a concern for a BIP anyway...
That's a very sweeping generalisation indeed. Why should two chains
have to have a separate genesis? It's cleaner, but it's certainly not
a necessity. You cant exclude this case just because it doesn't fit
your concept of neat and tidy. Other BIP proposals that account for
alternative chains do not rely on the genesis hash, but instead an
identifier. Why should it be any different here? How would you account
for a world with XTCoin and Bitcoin which would also share the same
genesis hash, but clearly not be the same coin.
When I brought up the issue originally, I deliberately steered away
from altchains choosing to focus on networks like mainnet, testnet
because I think it's easier to repurpose a protocol for an altcoin
than it is to make the proposal work for all cases. Take the payment
protocol for example. The BIP specifies a URI with bitcoin: well it's
just as easy to repurpose that for litecoin: etc than adding something
like ?cointype=litecoin, so that was my reason for not mentioning
altcoins at all.
If the proposal is made to account for altcoins, genesis hash is
definitely not desirable, or at least not genesis hash in isolation,
and if that's the case, better to have an identifier.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 16:12 ` Danny Thorpe
@ 2015-09-01 22:59 ` Btc Drak
2015-09-01 23:57 ` Jorge Timón
0 siblings, 1 reply; 32+ messages in thread
From: Btc Drak @ 2015-09-01 22:59 UTC (permalink / raw)
To: Danny Thorpe; +Cc: Bitcoin Dev
On Tue, Sep 1, 2015 at 5:12 PM, Danny Thorpe via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Rather than using an inhumanly long hex string from the genesis hash to
> distinguish between mainnet and testnet, why not use the network magic bytes
> instead? Much shorter, just as distinct.
There's nothing stopping two coins having the same magic bytes, but
communicating on separate ports.
> I'd still prefer a common network name mapping for the sake of humanity. Few
> bitcoin library implementations use the same string names for mainnet and
> testnet. This BIP could simply define one string name alias for each
> supported network and leave mapping to local lingo to the implementors.
The only sane way to me see to have cointype like BIP44.
See https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#coin-type
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 22:46 ` Jorge Timón
@ 2015-09-01 23:25 ` Matt Whitlock
0 siblings, 0 replies; 32+ messages in thread
From: Matt Whitlock @ 2015-09-01 23:25 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
On Wednesday, 2 September 2015, at 12:46 am, Jorge Timón wrote:
> But again, the main issue is that we don't want a central authority to
> register unique unique and memorable chain name strings.
Why not? There's a central registry of MIME types. And there's a central registry of TCP/UDP port number assignments. The BIP describing the "blockchain" URI scheme is published by a central authority. For cases where assigning names to numbers is uncontroversial, central authorities don't cause any problems.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-09-01 22:59 ` Btc Drak
@ 2015-09-01 23:57 ` Jorge Timón
0 siblings, 0 replies; 32+ messages in thread
From: Jorge Timón @ 2015-09-01 23:57 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev, Matt Corallo
On Wed, Sep 2, 2015 at 12:56 AM, Btc Drak <btcdrak@gmail•com> wrote:
> When I brought up the issue originally, I deliberately steered away
> from altchains choosing to focus on networks like mainnet, testnet
> because I think it's easier to repurpose a protocol for an altcoin
> than it is to make the proposal work for all cases. Take the payment
> protocol for example. The BIP specifies a URI with bitcoin: well it's
> just as easy to repurpose that for litecoin: etc than adding something
> like ?cointype=litecoin, so that was my reason for not mentioning
> altcoins at all.
>
> If the proposal is made to account for altcoins, genesis hash is
> definitely not desirable, or at least not genesis hash in isolation,
> and if that's the case, better to have an identifier
I agree. That's why we don't need to account for altchains other than
testchains (ie sidechains and altcoins).
> On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> Some altcoins (LTC and FTC for example) have the same genesis block hash.
>>
>> That's obviously a design mistake in FTC, but it's not unsolvable. FTC could
>> move their genesis block to the next block (or the first one that is not
>> identical to LTC's).
>>
>> Bitcoin and all its test chains have different genesis blocks, so I'm not
>> sure FTC should be a concern for a BIP anyway...
>
> That's a very sweeping generalisation indeed. Why should two chains
> have to have a separate genesis? It's cleaner, but it's certainly not
> a necessity. You cant exclude this case just because it doesn't fit
> your concept of neat and tidy. Other BIP proposals that account for
> alternative chains do not rely on the genesis hash, but instead an
> identifier. Why should it be any different here?
On Wed, Sep 2, 2015 at 12:59 AM, Btc Drak <btcdrak@gmail•com> wrote:
> The only sane way to me see to have cointype like BIP44.
> See https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#coin-type
We can do it the right way from now on (and as you say altcoins can
trivially adapt to this).
Sorry for having missed bip44 for review but that section is horrible
in my opinion (see the links above). And it seems to be incompatible
with bip001 which says are immutable once accepted (assuming that
document is expected to be the central registry of registered chains).
> How would you account
> for a world with XTCoin and Bitcoin which would also share the same
> genesis hash, but clearly not be the same coin.
Schism hardforks are explicitly renouncing to reach consensus with all
previous users. You're intentionally divorcing 2 chains, and you can
do that without confusing users.
In BIP99 the recommended deployment path for a schism fork is to
simply use the nHeight for activation.
The 95% miner's upgrade confirmation is not used here (like in
uncontroversial hardforks and softforks) because you don't necessarily
expect all miners to move to your side of the schism (and you don't
want to wait for them, specially if it's an "anti-miner" hardfork).
To avoid confusing users, you can define a new "genesis block" to use
for the chain ID, for example, 1000 blocks before the activation
height.
The same applies for potentially pre-mined altcoins that haven't had
the decency/competency of even changing the string in pszTimestamp.
For example, FTC, coins generated with coingen (Matt Corallo or the
current owner may want to correct me on this point) or elements alpha
(https://github.com/ElementsProject/elements/blob/alpha/src/chainparams.cpp#L115).
Fortunately alpha has a unique chain ID because it was changing both
the block and transaction serialization formats anyway. But hopefully
we will fix that for beta and later sidechains.
All chains that want a unique chain ID can have it retroactively. At
worst, they may need to use the hash of a block that is not the
genesis block.
In other words, they may need to move their "genesis checkpoint" upwards.
Terminology may make things more clear. We can replace:
"The chain ID is the hash of the genesis block"
with
"The chain ID is the hash of the genesis checkpoint".
If we want a unique chain ID we can have it: it just cannot be
memorable at the same time.
And each chain and implementation can start using them (in addition to
petname -> chain ID local dictionaries) at any point in time: this is
retroactively (and obviously forwards) compatible.
There can be many competing registries for the name -> chainID
dictionaries (maybe one of them based on namecoin?) but bitcoin/bips
shouldn't maintain one.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-08-29 11:48 [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration Marco Pontello
2015-08-29 16:31 ` Richard Moore
@ 2015-11-15 2:14 ` Marco Pontello
2015-11-15 11:42 ` Jorge Timón
1 sibling, 1 reply; 32+ messages in thread
From: Marco Pontello @ 2015-11-15 2:14 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]
Hi!
To anyone that followed the discussion (from some time ago) about the
proposed new URI for Blockchain references / exploration, I just wanted to
point out that I have collected the feedback provided, reworked the text,
put the BIP on GitHub and created a pull request:
https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
https://github.com/bitcoin/bips/pull/202
The need for an URI for this come to mind again in the last days looking at
Eternity Wall, which IMHO provide a use case that we will see more and more
in the (near) future: http://eternitywall.it/
Using that service, when you want to check for the proof that a specific
message was written in the Blockchain, it let you choose from 5 different
explorer.
Mycelium wallet recently added the option to select one of 15 block
explorers.
And there's the crypto_bot on reddit/r/bitcoin that detect reference to
transaction an add a message with links to 7 different explorers.
I think that's clearly something that's needed.
Bye!
On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com> wrote:
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 5030 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-15 2:14 ` Marco Pontello
@ 2015-11-15 11:42 ` Jorge Timón
2015-11-16 0:59 ` Marco Pontello
0 siblings, 1 reply; 32+ messages in thread
From: Jorge Timón @ 2015-11-15 11:42 UTC (permalink / raw)
To: Marco Pontello; +Cc: Bitcoin Dev
Thank you for incorporating the feedback, specifically thank you for
using the genesis block hash as the unique chain ID.
I wen't through the BIP draft and left a few of comments, but I really
like its simplicity and focus. Good work!
On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi!
>
> To anyone that followed the discussion (from some time ago) about the
> proposed new URI for Blockchain references / exploration, I just wanted to
> point out that I have collected the feedback provided, reworked the text,
> put the BIP on GitHub and created a pull request:
>
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> https://github.com/bitcoin/bips/pull/202
>
> The need for an URI for this come to mind again in the last days looking at
> Eternity Wall, which IMHO provide a use case that we will see more and more
> in the (near) future: http://eternitywall.it/
> Using that service, when you want to check for the proof that a specific
> message was written in the Blockchain, it let you choose from 5 different
> explorer.
> Mycelium wallet recently added the option to select one of 15 block
> explorers.
> And there's the crypto_bot on reddit/r/bitcoin that detect reference to
> transaction an add a message with links to 7 different explorers.
>
> I think that's clearly something that's needed.
>
> Bye!
>
>
> On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com> wrote:
>>
>> Hi!
>> My first post here, hope I'm following the right conventions.
>> I had this humble idea for a while, so I thought to go ahead and propose
>> it.
>>
>> BIP: XX
>> Title: URI scheme for Blockchain exploration
>> Author: Marco Pontello
>> Status: Draft
>> Type: Standards Track
>> Created: 29 August 2015
>>
>> Abstract
>> ========
>> This BIP propose a simple URI scheme for looking up blocks, transactions,
>> addresses on a Blockchain explorer.
>>
>> Motivation
>> ==========
>> The purpose of this URI scheme is to enable users to handle all the
>> requests for details about blocks, transactions, etc. with their preferred
>> tool (being that a web service or a local application).
>>
>> Currently a Bitcoin client usually point to an arbitrary blockchain
>> explorer when the user look for the details of a transaction (es. Bitcoin
>> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> Other times resorting to cut&paste is needed.
>> The same happens with posts and messages that reference some particular
>> txs or blocks, if they provide links at all.
>>
>> Specification
>> =============
>> The URI follow this simple form:
>>
>> blockchain: <hash/string>
>>
>> Examples:
>>
>>
>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> blockchain:001949
>>
>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>>
>> Rationale
>> =========
>> I thought about using some more complex scheme, or adding qualifiers to
>> distinguish blocks from txs, but in the end I think that keeping it simple
>> should be practical enough. Blockchain explorers can apply the same
>> disambiguation rules they are already using to process the usual search
>> box.
>>
>> From the point of view of a wallet developer (or other tool that need to
>> show any kind of Blockchain references), using this scheme mean that he
>> can simply make it a blockchain: link and be done with it, without having
>> to worry about any specific Blockchain explorer or provide a means for the
>> user to select one.
>>
>> Blockchain explorers in turn will simply offer to handle the blockchain:
>> URI, the first time the user visit their website, or launch/install the
>> application, or even set themselves if there isn't already one.
>>
>> Users get the convenience of using always their preferred explorer, which
>> can be especially handy on mobile devices, where juggling with cut&paste
>> is far from ideal.
>>
>>
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-15 11:42 ` Jorge Timón
@ 2015-11-16 0:59 ` Marco Pontello
2015-11-16 14:43 ` Jorge Timón
0 siblings, 1 reply; 32+ messages in thread
From: Marco Pontello @ 2015-11-16 0:59 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5157 bytes --]
Thanks for the comments! Now I fixed the typos (hope to have got them all,
English isn't my first language), clarified the chain part a bit, and fixed
the link. There probably is a better way to reference that source code part
with the genesis blocks hashs, in a way that doesn't need to be changed,
maybe...
Now the main change would be to put in a proper BIP number! :)
On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> Thank you for incorporating the feedback, specifically thank you for
> using the genesis block hash as the unique chain ID.
>
> I wen't through the BIP draft and left a few of comments, but I really
> like its simplicity and focus. Good work!
>
> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Hi!
> >
> > To anyone that followed the discussion (from some time ago) about the
> > proposed new URI for Blockchain references / exploration, I just wanted
> to
> > point out that I have collected the feedback provided, reworked the text,
> > put the BIP on GitHub and created a pull request:
> >
> > https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> > https://github.com/bitcoin/bips/pull/202
> >
> > The need for an URI for this come to mind again in the last days looking
> at
> > Eternity Wall, which IMHO provide a use case that we will see more and
> more
> > in the (near) future: http://eternitywall.it/
> > Using that service, when you want to check for the proof that a specific
> > message was written in the Blockchain, it let you choose from 5 different
> > explorer.
> > Mycelium wallet recently added the option to select one of 15 block
> > explorers.
> > And there's the crypto_bot on reddit/r/bitcoin that detect reference to
> > transaction an add a message with links to 7 different explorers.
> >
> > I think that's clearly something that's needed.
> >
> > Bye!
> >
> >
> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com>
> wrote:
> >>
> >> Hi!
> >> My first post here, hope I'm following the right conventions.
> >> I had this humble idea for a while, so I thought to go ahead and propose
> >> it.
> >>
> >> BIP: XX
> >> Title: URI scheme for Blockchain exploration
> >> Author: Marco Pontello
> >> Status: Draft
> >> Type: Standards Track
> >> Created: 29 August 2015
> >>
> >> Abstract
> >> ========
> >> This BIP propose a simple URI scheme for looking up blocks,
> transactions,
> >> addresses on a Blockchain explorer.
> >>
> >> Motivation
> >> ==========
> >> The purpose of this URI scheme is to enable users to handle all the
> >> requests for details about blocks, transactions, etc. with their
> preferred
> >> tool (being that a web service or a local application).
> >>
> >> Currently a Bitcoin client usually point to an arbitrary blockchain
> >> explorer when the user look for the details of a transaction (es.
> Bitcoin
> >> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> >> Other times resorting to cut&paste is needed.
> >> The same happens with posts and messages that reference some particular
> >> txs or blocks, if they provide links at all.
> >>
> >> Specification
> >> =============
> >> The URI follow this simple form:
> >>
> >> blockchain: <hash/string>
> >>
> >> Examples:
> >>
> >>
> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> blockchain:001949
> >>
> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >>
> >> Rationale
> >> =========
> >> I thought about using some more complex scheme, or adding qualifiers to
> >> distinguish blocks from txs, but in the end I think that keeping it
> simple
> >> should be practical enough. Blockchain explorers can apply the same
> >> disambiguation rules they are already using to process the usual search
> >> box.
> >>
> >> From the point of view of a wallet developer (or other tool that need to
> >> show any kind of Blockchain references), using this scheme mean that he
> >> can simply make it a blockchain: link and be done with it, without
> having
> >> to worry about any specific Blockchain explorer or provide a means for
> the
> >> user to select one.
> >>
> >> Blockchain explorers in turn will simply offer to handle the blockchain:
> >> URI, the first time the user visit their website, or launch/install the
> >> application, or even set themselves if there isn't already one.
> >>
> >> Users get the convenience of using always their preferred explorer,
> which
> >> can be especially handy on mobile devices, where juggling with cut&paste
> >> is far from ideal.
> >>
> >>
> >
> >
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 7083 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-16 0:59 ` Marco Pontello
@ 2015-11-16 14:43 ` Jorge Timón
2015-11-16 22:10 ` Marco Pontello
0 siblings, 1 reply; 32+ messages in thread
From: Jorge Timón @ 2015-11-16 14:43 UTC (permalink / raw)
To: Marco Pontello; +Cc: Bitcoin Dev
Not a native english speaker myself, so I may have missed some things...
Yes, sorry about the link. I guess you can point to #6230 . I can
rebase it if needed but I would close it again because I don't want to
have too many things from #6382 opened at the same time (is noisy and
worse for review). My plan was to not open it independently at least
until after #6907 (and actually after 0.12 assuming #6907 gets in by
0.12). But then I would maybe open a new one and reference the old one
rather than reopening #6230 (which tends to be confusing).
I'm not really sure what's the best answer here...but #6382 is
certainly going to need rebase and the link will be broken again.
Maybe one answer is to copy some text from #6230 or the commit and add
it directly to the BIP instead of referencing to that commit (which
will be, at least until #6907 is merged, a moving target).
On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon@gmail•com> wrote:
> Thanks for the comments! Now I fixed the typos (hope to have got them all,
> English isn't my first language), clarified the chain part a bit, and fixed
> the link. There probably is a better way to reference that source code part
> with the genesis blocks hashs, in a way that doesn't need to be changed,
> maybe...
>
> Now the main change would be to put in a proper BIP number! :)
>
> On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>>
>> Thank you for incorporating the feedback, specifically thank you for
>> using the genesis block hash as the unique chain ID.
>>
>> I wen't through the BIP draft and left a few of comments, but I really
>> like its simplicity and focus. Good work!
>>
>> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> > Hi!
>> >
>> > To anyone that followed the discussion (from some time ago) about the
>> > proposed new URI for Blockchain references / exploration, I just wanted
>> > to
>> > point out that I have collected the feedback provided, reworked the
>> > text,
>> > put the BIP on GitHub and created a pull request:
>> >
>> > https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
>> > https://github.com/bitcoin/bips/pull/202
>> >
>> > The need for an URI for this come to mind again in the last days looking
>> > at
>> > Eternity Wall, which IMHO provide a use case that we will see more and
>> > more
>> > in the (near) future: http://eternitywall.it/
>> > Using that service, when you want to check for the proof that a specific
>> > message was written in the Blockchain, it let you choose from 5
>> > different
>> > explorer.
>> > Mycelium wallet recently added the option to select one of 15 block
>> > explorers.
>> > And there's the crypto_bot on reddit/r/bitcoin that detect reference to
>> > transaction an add a message with links to 7 different explorers.
>> >
>> > I think that's clearly something that's needed.
>> >
>> > Bye!
>> >
>> >
>> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com>
>> > wrote:
>> >>
>> >> Hi!
>> >> My first post here, hope I'm following the right conventions.
>> >> I had this humble idea for a while, so I thought to go ahead and
>> >> propose
>> >> it.
>> >>
>> >> BIP: XX
>> >> Title: URI scheme for Blockchain exploration
>> >> Author: Marco Pontello
>> >> Status: Draft
>> >> Type: Standards Track
>> >> Created: 29 August 2015
>> >>
>> >> Abstract
>> >> ========
>> >> This BIP propose a simple URI scheme for looking up blocks,
>> >> transactions,
>> >> addresses on a Blockchain explorer.
>> >>
>> >> Motivation
>> >> ==========
>> >> The purpose of this URI scheme is to enable users to handle all the
>> >> requests for details about blocks, transactions, etc. with their
>> >> preferred
>> >> tool (being that a web service or a local application).
>> >>
>> >> Currently a Bitcoin client usually point to an arbitrary blockchain
>> >> explorer when the user look for the details of a transaction (es.
>> >> Bitcoin
>> >> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> >> Other times resorting to cut&paste is needed.
>> >> The same happens with posts and messages that reference some particular
>> >> txs or blocks, if they provide links at all.
>> >>
>> >> Specification
>> >> =============
>> >> The URI follow this simple form:
>> >>
>> >> blockchain: <hash/string>
>> >>
>> >> Examples:
>> >>
>> >>
>> >>
>> >> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> >> blockchain:001949
>> >>
>> >>
>> >> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> >>
>> >> Rationale
>> >> =========
>> >> I thought about using some more complex scheme, or adding qualifiers to
>> >> distinguish blocks from txs, but in the end I think that keeping it
>> >> simple
>> >> should be practical enough. Blockchain explorers can apply the same
>> >> disambiguation rules they are already using to process the usual search
>> >> box.
>> >>
>> >> From the point of view of a wallet developer (or other tool that need
>> >> to
>> >> show any kind of Blockchain references), using this scheme mean that he
>> >> can simply make it a blockchain: link and be done with it, without
>> >> having
>> >> to worry about any specific Blockchain explorer or provide a means for
>> >> the
>> >> user to select one.
>> >>
>> >> Blockchain explorers in turn will simply offer to handle the
>> >> blockchain:
>> >> URI, the first time the user visit their website, or launch/install the
>> >> application, or even set themselves if there isn't already one.
>> >>
>> >> Users get the convenience of using always their preferred explorer,
>> >> which
>> >> can be especially handy on mobile devices, where juggling with
>> >> cut&paste
>> >> is far from ideal.
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Try the Online TrID File Identifier
>> > http://mark0.net/onlinetrid.aspx
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-16 14:43 ` Jorge Timón
@ 2015-11-16 22:10 ` Marco Pontello
2015-11-18 11:29 ` Jorge Timón
0 siblings, 1 reply; 32+ messages in thread
From: Marco Pontello @ 2015-11-16 22:10 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6990 bytes --]
OK, adding the relevant code fragment is probably the simplest and direct
option. Done.
On Mon, Nov 16, 2015 at 3:43 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> Not a native english speaker myself, so I may have missed some things...
>
> Yes, sorry about the link. I guess you can point to #6230 . I can
> rebase it if needed but I would close it again because I don't want to
> have too many things from #6382 opened at the same time (is noisy and
> worse for review). My plan was to not open it independently at least
> until after #6907 (and actually after 0.12 assuming #6907 gets in by
> 0.12). But then I would maybe open a new one and reference the old one
> rather than reopening #6230 (which tends to be confusing).
> I'm not really sure what's the best answer here...but #6382 is
> certainly going to need rebase and the link will be broken again.
> Maybe one answer is to copy some text from #6230 or the commit and add
> it directly to the BIP instead of referencing to that commit (which
> will be, at least until #6907 is merged, a moving target).
>
> On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon@gmail•com>
> wrote:
> > Thanks for the comments! Now I fixed the typos (hope to have got them
> all,
> > English isn't my first language), clarified the chain part a bit, and
> fixed
> > the link. There probably is a better way to reference that source code
> part
> > with the genesis blocks hashs, in a way that doesn't need to be changed,
> > maybe...
> >
> > Now the main change would be to put in a proper BIP number! :)
> >
> > On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> >>
> >> Thank you for incorporating the feedback, specifically thank you for
> >> using the genesis block hash as the unique chain ID.
> >>
> >> I wen't through the BIP draft and left a few of comments, but I really
> >> like its simplicity and focus. Good work!
> >>
> >> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> > Hi!
> >> >
> >> > To anyone that followed the discussion (from some time ago) about the
> >> > proposed new URI for Blockchain references / exploration, I just
> wanted
> >> > to
> >> > point out that I have collected the feedback provided, reworked the
> >> > text,
> >> > put the BIP on GitHub and created a pull request:
> >> >
> >> >
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> >> > https://github.com/bitcoin/bips/pull/202
> >> >
> >> > The need for an URI for this come to mind again in the last days
> looking
> >> > at
> >> > Eternity Wall, which IMHO provide a use case that we will see more and
> >> > more
> >> > in the (near) future: http://eternitywall.it/
> >> > Using that service, when you want to check for the proof that a
> specific
> >> > message was written in the Blockchain, it let you choose from 5
> >> > different
> >> > explorer.
> >> > Mycelium wallet recently added the option to select one of 15 block
> >> > explorers.
> >> > And there's the crypto_bot on reddit/r/bitcoin that detect reference
> to
> >> > transaction an add a message with links to 7 different explorers.
> >> >
> >> > I think that's clearly something that's needed.
> >> >
> >> > Bye!
> >> >
> >> >
> >> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com>
> >> > wrote:
> >> >>
> >> >> Hi!
> >> >> My first post here, hope I'm following the right conventions.
> >> >> I had this humble idea for a while, so I thought to go ahead and
> >> >> propose
> >> >> it.
> >> >>
> >> >> BIP: XX
> >> >> Title: URI scheme for Blockchain exploration
> >> >> Author: Marco Pontello
> >> >> Status: Draft
> >> >> Type: Standards Track
> >> >> Created: 29 August 2015
> >> >>
> >> >> Abstract
> >> >> ========
> >> >> This BIP propose a simple URI scheme for looking up blocks,
> >> >> transactions,
> >> >> addresses on a Blockchain explorer.
> >> >>
> >> >> Motivation
> >> >> ==========
> >> >> The purpose of this URI scheme is to enable users to handle all the
> >> >> requests for details about blocks, transactions, etc. with their
> >> >> preferred
> >> >> tool (being that a web service or a local application).
> >> >>
> >> >> Currently a Bitcoin client usually point to an arbitrary blockchain
> >> >> explorer when the user look for the details of a transaction (es.
> >> >> Bitcoin
> >> >> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> >> >> Other times resorting to cut&paste is needed.
> >> >> The same happens with posts and messages that reference some
> particular
> >> >> txs or blocks, if they provide links at all.
> >> >>
> >> >> Specification
> >> >> =============
> >> >> The URI follow this simple form:
> >> >>
> >> >> blockchain: <hash/string>
> >> >>
> >> >> Examples:
> >> >>
> >> >>
> >> >>
> >> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> >> blockchain:001949
> >> >>
> >> >>
> >> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >> >>
> >> >> Rationale
> >> >> =========
> >> >> I thought about using some more complex scheme, or adding qualifiers
> to
> >> >> distinguish blocks from txs, but in the end I think that keeping it
> >> >> simple
> >> >> should be practical enough. Blockchain explorers can apply the same
> >> >> disambiguation rules they are already using to process the usual
> search
> >> >> box.
> >> >>
> >> >> From the point of view of a wallet developer (or other tool that need
> >> >> to
> >> >> show any kind of Blockchain references), using this scheme mean that
> he
> >> >> can simply make it a blockchain: link and be done with it, without
> >> >> having
> >> >> to worry about any specific Blockchain explorer or provide a means
> for
> >> >> the
> >> >> user to select one.
> >> >>
> >> >> Blockchain explorers in turn will simply offer to handle the
> >> >> blockchain:
> >> >> URI, the first time the user visit their website, or launch/install
> the
> >> >> application, or even set themselves if there isn't already one.
> >> >>
> >> >> Users get the convenience of using always their preferred explorer,
> >> >> which
> >> >> can be especially handy on mobile devices, where juggling with
> >> >> cut&paste
> >> >> is far from ideal.
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Try the Online TrID File Identifier
> >> > http://mark0.net/onlinetrid.aspx
> >> >
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists•linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >
> >
> >
> >
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 10039 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-16 22:10 ` Marco Pontello
@ 2015-11-18 11:29 ` Jorge Timón
2015-11-18 12:31 ` Marco Pontello
0 siblings, 1 reply; 32+ messages in thread
From: Jorge Timón @ 2015-11-18 11:29 UTC (permalink / raw)
To: Marco Pontello; +Cc: Bitcoin Dev
I can always link to the BIP when I reopen that commit as independent
instead of the other way around.
Btw, the PR needs rebase (probably the conflict is in the README).
On Mon, Nov 16, 2015 at 11:10 PM, Marco Pontello <marcopon@gmail•com> wrote:
> OK, adding the relevant code fragment is probably the simplest and direct
> option. Done.
>
> On Mon, Nov 16, 2015 at 3:43 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>>
>> Not a native english speaker myself, so I may have missed some things...
>>
>> Yes, sorry about the link. I guess you can point to #6230 . I can
>> rebase it if needed but I would close it again because I don't want to
>> have too many things from #6382 opened at the same time (is noisy and
>> worse for review). My plan was to not open it independently at least
>> until after #6907 (and actually after 0.12 assuming #6907 gets in by
>> 0.12). But then I would maybe open a new one and reference the old one
>> rather than reopening #6230 (which tends to be confusing).
>> I'm not really sure what's the best answer here...but #6382 is
>> certainly going to need rebase and the link will be broken again.
>> Maybe one answer is to copy some text from #6230 or the commit and add
>> it directly to the BIP instead of referencing to that commit (which
>> will be, at least until #6907 is merged, a moving target).
>>
>> On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon@gmail•com>
>> wrote:
>> > Thanks for the comments! Now I fixed the typos (hope to have got them
>> > all,
>> > English isn't my first language), clarified the chain part a bit, and
>> > fixed
>> > the link. There probably is a better way to reference that source code
>> > part
>> > with the genesis blocks hashs, in a way that doesn't need to be changed,
>> > maybe...
>> >
>> > Now the main change would be to put in a proper BIP number! :)
>> >
>> > On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>> >>
>> >> Thank you for incorporating the feedback, specifically thank you for
>> >> using the genesis block hash as the unique chain ID.
>> >>
>> >> I wen't through the BIP draft and left a few of comments, but I really
>> >> like its simplicity and focus. Good work!
>> >>
>> >> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
>> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >> > Hi!
>> >> >
>> >> > To anyone that followed the discussion (from some time ago) about the
>> >> > proposed new URI for Blockchain references / exploration, I just
>> >> > wanted
>> >> > to
>> >> > point out that I have collected the feedback provided, reworked the
>> >> > text,
>> >> > put the BIP on GitHub and created a pull request:
>> >> >
>> >> >
>> >> > https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
>> >> > https://github.com/bitcoin/bips/pull/202
>> >> >
>> >> > The need for an URI for this come to mind again in the last days
>> >> > looking
>> >> > at
>> >> > Eternity Wall, which IMHO provide a use case that we will see more
>> >> > and
>> >> > more
>> >> > in the (near) future: http://eternitywall.it/
>> >> > Using that service, when you want to check for the proof that a
>> >> > specific
>> >> > message was written in the Blockchain, it let you choose from 5
>> >> > different
>> >> > explorer.
>> >> > Mycelium wallet recently added the option to select one of 15 block
>> >> > explorers.
>> >> > And there's the crypto_bot on reddit/r/bitcoin that detect reference
>> >> > to
>> >> > transaction an add a message with links to 7 different explorers.
>> >> >
>> >> > I think that's clearly something that's needed.
>> >> >
>> >> > Bye!
>> >> >
>> >> >
>> >> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon@gmail•com>
>> >> > wrote:
>> >> >>
>> >> >> Hi!
>> >> >> My first post here, hope I'm following the right conventions.
>> >> >> I had this humble idea for a while, so I thought to go ahead and
>> >> >> propose
>> >> >> it.
>> >> >>
>> >> >> BIP: XX
>> >> >> Title: URI scheme for Blockchain exploration
>> >> >> Author: Marco Pontello
>> >> >> Status: Draft
>> >> >> Type: Standards Track
>> >> >> Created: 29 August 2015
>> >> >>
>> >> >> Abstract
>> >> >> ========
>> >> >> This BIP propose a simple URI scheme for looking up blocks,
>> >> >> transactions,
>> >> >> addresses on a Blockchain explorer.
>> >> >>
>> >> >> Motivation
>> >> >> ==========
>> >> >> The purpose of this URI scheme is to enable users to handle all the
>> >> >> requests for details about blocks, transactions, etc. with their
>> >> >> preferred
>> >> >> tool (being that a web service or a local application).
>> >> >>
>> >> >> Currently a Bitcoin client usually point to an arbitrary blockchain
>> >> >> explorer when the user look for the details of a transaction (es.
>> >> >> Bitcoin
>> >> >> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
>> >> >> Other times resorting to cut&paste is needed.
>> >> >> The same happens with posts and messages that reference some
>> >> >> particular
>> >> >> txs or blocks, if they provide links at all.
>> >> >>
>> >> >> Specification
>> >> >> =============
>> >> >> The URI follow this simple form:
>> >> >>
>> >> >> blockchain: <hash/string>
>> >> >>
>> >> >> Examples:
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
>> >> >> blockchain:001949
>> >> >>
>> >> >>
>> >> >>
>> >> >> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>> >> >>
>> >> >> Rationale
>> >> >> =========
>> >> >> I thought about using some more complex scheme, or adding qualifiers
>> >> >> to
>> >> >> distinguish blocks from txs, but in the end I think that keeping it
>> >> >> simple
>> >> >> should be practical enough. Blockchain explorers can apply the same
>> >> >> disambiguation rules they are already using to process the usual
>> >> >> search
>> >> >> box.
>> >> >>
>> >> >> From the point of view of a wallet developer (or other tool that
>> >> >> need
>> >> >> to
>> >> >> show any kind of Blockchain references), using this scheme mean that
>> >> >> he
>> >> >> can simply make it a blockchain: link and be done with it, without
>> >> >> having
>> >> >> to worry about any specific Blockchain explorer or provide a means
>> >> >> for
>> >> >> the
>> >> >> user to select one.
>> >> >>
>> >> >> Blockchain explorers in turn will simply offer to handle the
>> >> >> blockchain:
>> >> >> URI, the first time the user visit their website, or launch/install
>> >> >> the
>> >> >> application, or even set themselves if there isn't already one.
>> >> >>
>> >> >> Users get the convenience of using always their preferred explorer,
>> >> >> which
>> >> >> can be especially handy on mobile devices, where juggling with
>> >> >> cut&paste
>> >> >> is far from ideal.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Try the Online TrID File Identifier
>> >> > http://mark0.net/onlinetrid.aspx
>> >> >
>> >> > _______________________________________________
>> >> > bitcoin-dev mailing list
>> >> > bitcoin-dev@lists•linuxfoundation.org
>> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Try the Online TrID File Identifier
>> > http://mark0.net/onlinetrid.aspx
>
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
2015-11-18 11:29 ` Jorge Timón
@ 2015-11-18 12:31 ` Marco Pontello
0 siblings, 0 replies; 32+ messages in thread
From: Marco Pontello @ 2015-11-18 12:31 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 8205 bytes --]
Right, now it should be ok. Thanks.
On Wed, Nov 18, 2015 at 12:29 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> I can always link to the BIP when I reopen that commit as independent
> instead of the other way around.
> Btw, the PR needs rebase (probably the conflict is in the README).
>
> On Mon, Nov 16, 2015 at 11:10 PM, Marco Pontello <marcopon@gmail•com>
> wrote:
> > OK, adding the relevant code fragment is probably the simplest and direct
> > option. Done.
> >
> > On Mon, Nov 16, 2015 at 3:43 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> >>
> >> Not a native english speaker myself, so I may have missed some things...
> >>
> >> Yes, sorry about the link. I guess you can point to #6230 . I can
> >> rebase it if needed but I would close it again because I don't want to
> >> have too many things from #6382 opened at the same time (is noisy and
> >> worse for review). My plan was to not open it independently at least
> >> until after #6907 (and actually after 0.12 assuming #6907 gets in by
> >> 0.12). But then I would maybe open a new one and reference the old one
> >> rather than reopening #6230 (which tends to be confusing).
> >> I'm not really sure what's the best answer here...but #6382 is
> >> certainly going to need rebase and the link will be broken again.
> >> Maybe one answer is to copy some text from #6230 or the commit and add
> >> it directly to the BIP instead of referencing to that commit (which
> >> will be, at least until #6907 is merged, a moving target).
> >>
> >> On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon@gmail•com>
> >> wrote:
> >> > Thanks for the comments! Now I fixed the typos (hope to have got them
> >> > all,
> >> > English isn't my first language), clarified the chain part a bit, and
> >> > fixed
> >> > the link. There probably is a better way to reference that source code
> >> > part
> >> > with the genesis blocks hashs, in a way that doesn't need to be
> changed,
> >> > maybe...
> >> >
> >> > Now the main change would be to put in a proper BIP number! :)
> >> >
> >> > On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon@jtimon•cc>
> wrote:
> >> >>
> >> >> Thank you for incorporating the feedback, specifically thank you for
> >> >> using the genesis block hash as the unique chain ID.
> >> >>
> >> >> I wen't through the BIP draft and left a few of comments, but I
> really
> >> >> like its simplicity and focus. Good work!
> >> >>
> >> >> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> >> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >> > Hi!
> >> >> >
> >> >> > To anyone that followed the discussion (from some time ago) about
> the
> >> >> > proposed new URI for Blockchain references / exploration, I just
> >> >> > wanted
> >> >> > to
> >> >> > point out that I have collected the feedback provided, reworked the
> >> >> > text,
> >> >> > put the BIP on GitHub and created a pull request:
> >> >> >
> >> >> >
> >> >> >
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> >> >> > https://github.com/bitcoin/bips/pull/202
> >> >> >
> >> >> > The need for an URI for this come to mind again in the last days
> >> >> > looking
> >> >> > at
> >> >> > Eternity Wall, which IMHO provide a use case that we will see more
> >> >> > and
> >> >> > more
> >> >> > in the (near) future: http://eternitywall.it/
> >> >> > Using that service, when you want to check for the proof that a
> >> >> > specific
> >> >> > message was written in the Blockchain, it let you choose from 5
> >> >> > different
> >> >> > explorer.
> >> >> > Mycelium wallet recently added the option to select one of 15 block
> >> >> > explorers.
> >> >> > And there's the crypto_bot on reddit/r/bitcoin that detect
> reference
> >> >> > to
> >> >> > transaction an add a message with links to 7 different explorers.
> >> >> >
> >> >> > I think that's clearly something that's needed.
> >> >> >
> >> >> > Bye!
> >> >> >
> >> >> >
> >> >> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <
> marcopon@gmail•com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi!
> >> >> >> My first post here, hope I'm following the right conventions.
> >> >> >> I had this humble idea for a while, so I thought to go ahead and
> >> >> >> propose
> >> >> >> it.
> >> >> >>
> >> >> >> BIP: XX
> >> >> >> Title: URI scheme for Blockchain exploration
> >> >> >> Author: Marco Pontello
> >> >> >> Status: Draft
> >> >> >> Type: Standards Track
> >> >> >> Created: 29 August 2015
> >> >> >>
> >> >> >> Abstract
> >> >> >> ========
> >> >> >> This BIP propose a simple URI scheme for looking up blocks,
> >> >> >> transactions,
> >> >> >> addresses on a Blockchain explorer.
> >> >> >>
> >> >> >> Motivation
> >> >> >> ==========
> >> >> >> The purpose of this URI scheme is to enable users to handle all
> the
> >> >> >> requests for details about blocks, transactions, etc. with their
> >> >> >> preferred
> >> >> >> tool (being that a web service or a local application).
> >> >> >>
> >> >> >> Currently a Bitcoin client usually point to an arbitrary
> blockchain
> >> >> >> explorer when the user look for the details of a transaction (es.
> >> >> >> Bitcoin
> >> >> >> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info,
> etc.).
> >> >> >> Other times resorting to cut&paste is needed.
> >> >> >> The same happens with posts and messages that reference some
> >> >> >> particular
> >> >> >> txs or blocks, if they provide links at all.
> >> >> >>
> >> >> >> Specification
> >> >> >> =============
> >> >> >> The URI follow this simple form:
> >> >> >>
> >> >> >> blockchain: <hash/string>
> >> >> >>
> >> >> >> Examples:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> >> >> blockchain:001949
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >> >> >>
> >> >> >> Rationale
> >> >> >> =========
> >> >> >> I thought about using some more complex scheme, or adding
> qualifiers
> >> >> >> to
> >> >> >> distinguish blocks from txs, but in the end I think that keeping
> it
> >> >> >> simple
> >> >> >> should be practical enough. Blockchain explorers can apply the
> same
> >> >> >> disambiguation rules they are already using to process the usual
> >> >> >> search
> >> >> >> box.
> >> >> >>
> >> >> >> From the point of view of a wallet developer (or other tool that
> >> >> >> need
> >> >> >> to
> >> >> >> show any kind of Blockchain references), using this scheme mean
> that
> >> >> >> he
> >> >> >> can simply make it a blockchain: link and be done with it, without
> >> >> >> having
> >> >> >> to worry about any specific Blockchain explorer or provide a means
> >> >> >> for
> >> >> >> the
> >> >> >> user to select one.
> >> >> >>
> >> >> >> Blockchain explorers in turn will simply offer to handle the
> >> >> >> blockchain:
> >> >> >> URI, the first time the user visit their website, or
> launch/install
> >> >> >> the
> >> >> >> application, or even set themselves if there isn't already one.
> >> >> >>
> >> >> >> Users get the convenience of using always their preferred
> explorer,
> >> >> >> which
> >> >> >> can be especially handy on mobile devices, where juggling with
> >> >> >> cut&paste
> >> >> >> is far from ideal.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Try the Online TrID File Identifier
> >> >> > http://mark0.net/onlinetrid.aspx
> >> >> >
> >> >> > _______________________________________________
> >> >> > bitcoin-dev mailing list
> >> >> > bitcoin-dev@lists•linuxfoundation.org
> >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Try the Online TrID File Identifier
> >> > http://mark0.net/onlinetrid.aspx
> >
> >
> >
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
>
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
[-- Attachment #2: Type: text/html, Size: 12777 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2015-11-18 12:32 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-29 11:48 [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration Marco Pontello
2015-08-29 16:31 ` Richard Moore
2015-08-29 17:19 ` Matt Whitlock
2015-08-29 19:24 ` Richard Moore
2015-08-29 18:07 ` Andreas Schildbach
2015-09-01 14:33 ` Marco Pontello
2015-08-29 18:58 ` Btc Drak
2015-08-29 19:01 ` Matt Whitlock
2015-08-29 20:10 ` Jorge Timón
2015-08-30 2:02 ` Chun Wang
2015-08-30 2:20 ` Jorge Timón
2015-09-01 22:56 ` Btc Drak
2015-09-01 14:49 ` Marco Pontello
2015-09-01 21:16 ` Matt Whitlock
2015-09-01 21:25 ` Esteban Ordano
2015-09-01 21:38 ` Marco Pontello
2015-09-01 21:42 ` Matt Whitlock
2015-09-01 21:43 ` Marco Pontello
2015-09-01 22:46 ` Jorge Timón
2015-09-01 23:25 ` Matt Whitlock
2015-09-01 16:12 ` Danny Thorpe
2015-09-01 22:59 ` Btc Drak
2015-09-01 23:57 ` Jorge Timón
2015-08-29 19:28 ` Richard Moore
2015-09-01 14:51 ` Marco Pontello
2015-11-15 2:14 ` Marco Pontello
2015-11-15 11:42 ` Jorge Timón
2015-11-16 0:59 ` Marco Pontello
2015-11-16 14:43 ` Jorge Timón
2015-11-16 22:10 ` Marco Pontello
2015-11-18 11:29 ` Jorge Timón
2015-11-18 12:31 ` Marco Pontello
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox