Discussion:
[bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Marco Pontello via bitcoin-dev
2015-08-29 11:48:58 UTC
Permalink
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.
Richard Moore via bitcoin-dev
2015-08-29 16:31:45 UTC
Permalink
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: ***@geneticmistakes.com
www: http://GeneticMistakes.com
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matt Whitlock via bitcoin-dev
2015-08-29 17:19:17 UTC
Permalink
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
Post by Richard Moore via bitcoin-dev
I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
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.
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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.
Richard Moore via bitcoin-dev
2015-08-29 19:24:12 UTC
Permalink
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: ***@geneticmistakes.com
www: http://GeneticMistakes.com
Post by Matt Whitlock via bitcoin-dev
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.
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
Post by Richard Moore via bitcoin-dev
I like the idea of having a standard for this, that all explorers (and even core, eventually) would understand.
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.
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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.
Andreas Schildbach via bitcoin-dev
2015-08-29 18:07:26 UTC
Permalink
Post by Richard Moore via bitcoin-dev
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
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
Marco Pontello via bitcoin-dev
2015-09-01 14:33:59 UTC
Permalink
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 <
Post by Richard Moore via bitcoin-dev
Post by Richard Moore via bitcoin-dev
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
blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
Post by Richard Moore via bitcoin-dev
blockchain://block/189000
blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
Good thinking! It might make sense to look at the existing de-facto
/tx/ for transactions
/block/ for blocks, supports both hash or height
/address/ for address
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
Btc Drak via bitcoin-dev
2015-08-29 18:58:23 UTC
Permalink
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
Post by Richard Moore via bitcoin-dev
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
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
www: http://GeneticMistakes.com
On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matt Whitlock via bitcoin-dev
2015-08-29 19:01:23 UTC
Permalink
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
Post by Btc Drak via 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
Post by Richard Moore via bitcoin-dev
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
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
www: http://GeneticMistakes.com
On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2015-08-29 20:10:48 UTC
Permalink
On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
That's still not right, since "mainnet" and "testnet" are not host names.
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)
Chun Wang via bitcoin-dev
2015-08-30 02:02:01 UTC
Permalink
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
<bitcoin-***@lists.linuxfoundation.org> wrote:
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
Post by Jorge Timón via bitcoin-dev
(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
Post by Jorge Timón via bitcoin-dev
On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
That's still not right, since "mainnet" and "testnet" are not host names.
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.
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
(a tx in testnet)
/block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
(a block in bitcoin's mainnet)
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2015-08-30 02:20:17 UTC
Permalink
On Aug 29, 2015 7:02 PM, "Chun Wang via bitcoin-dev" <
On Sun, Aug 30, 2015 at 4:10 AM, Jorge Timón
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
Post by Jorge Timón via bitcoin-dev
(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...
Btc Drak via bitcoin-dev
2015-09-01 22:56:32 UTC
Permalink
On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
Post by Chun Wang via bitcoin-dev
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.
Marco Pontello via bitcoin-dev
2015-09-01 14:49:47 UTC
Permalink
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
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
Matt Whitlock via bitcoin-dev
2015-09-01 21:16:37 UTC
Permalink
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 Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
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.
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
Esteban Ordano via bitcoin-dev
2015-09-01 21:25:59 UTC
Permalink
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 <
Post by Matt Whitlock via 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.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
And I would agree with allowing well-known chains to register a name, to
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Post by Marco Pontello via bitcoin-dev
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
forum or a post.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
Post by Marco Pontello via bitcoin-dev
(or a different element name maybe)
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Marco Pontello via bitcoin-dev
2015-09-01 21:38:58 UTC
Permalink
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.
Post by Matt Whitlock via 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.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
And I would agree with allowing well-known chains to register a name, to
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Post by Marco Pontello via bitcoin-dev
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
forum or a post.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
Post by Marco Pontello via bitcoin-dev
(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
Matt Whitlock via bitcoin-dev
2015-09-01 21:42:09 UTC
Permalink
The authority part in a URI is optional.

blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f

Notice the lack of a double-slash.
Post by Marco Pontello via bitcoin-dev
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.
Post by Matt Whitlock via 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.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
And I would agree with allowing well-known chains to register a name, to
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
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
Post by Jorge Timón via bitcoin-dev
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.
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
Marco Pontello via bitcoin-dev
2015-09-01 21:43:39 UTC
Permalink
Oh, my bad! Right, sounds pretty good to me then.
Post by Matt Whitlock via bitcoin-dev
The authority part in a URI is optional.
blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Notice the lack of a double-slash.
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
to Bitcoin main net.
Post by Matt Whitlock via 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
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
block, tx, or address in that chain.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
And I would agree with allowing well-known chains to register a name,
to
blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón <
Post by Jorge Timón via bitcoin-dev
I would really prefer chain=<chainID> over
network=<chainPetnameStr>
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
By chainID I mean the hash of the genesis block, see
https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
I'm completely fine with doing that using an optional parameter
(for
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
backwards compatibility).
I see that using the genesis block hash would be the perfectly
rigorous
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
way
Post by Marco Pontello via bitcoin-dev
to do it, but what do you think about the possibility of letting
also use
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
the name constants, as a simple / more relaxed alternative? That
would
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
spare a source lookup just to write a correct reference to a tx,
maybe
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
in a
Post by Marco Pontello via bitcoin-dev
forum or a post.
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f
blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main
Post by Marco Pontello via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
(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
Jorge Timón via bitcoin-dev
2015-09-01 22:46:46 UTC
Permalink
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón
Post by Jorge Timón via bitcoin-dev
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.
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.
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.
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
Matt Whitlock via bitcoin-dev
2015-09-01 23:25:33 UTC
Permalink
Post by Jorge Timón via bitcoin-dev
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.
Danny Thorpe via bitcoin-dev
2015-09-01 16:12:42 UTC
Permalink
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 <
Post by Jorge Timón via bitcoin-dev
On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
Post by Matt Whitlock via bitcoin-dev
That's still not right, since "mainnet" and "testnet" are not host names.
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.
/tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
(a tx in testnet)
/block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
(a block in bitcoin's mainnet)
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Btc Drak via bitcoin-dev
2015-09-01 22:59:36 UTC
Permalink
On Tue, Sep 1, 2015 at 5:12 PM, Danny Thorpe via bitcoin-dev
Post by Danny Thorpe via bitcoin-dev
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.
Post by Danny Thorpe via bitcoin-dev
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
Jorge Timón via bitcoin-dev
2015-09-01 23:57:16 UTC
Permalink
Post by Btc Drak via bitcoin-dev
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).
Post by Btc Drak via bitcoin-dev
On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
Post by Chun Wang via bitcoin-dev
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?
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).
Post by Btc Drak via bitcoin-dev
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.
Richard Moore via bitcoin-dev
2015-08-29 19:28:17 UTC
Permalink
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: ***@geneticmistakes.com
www: http://GeneticMistakes.com
Post by Btc Drak via 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
Post by Richard Moore via bitcoin-dev
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
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
www: http://GeneticMistakes.com
On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Marco Pontello via bitcoin-dev
2015-09-01 14:51:52 UTC
Permalink
Post by Richard Moore via 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.
Like this option too!
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
Jorge Timón via bitcoin-dev
2015-11-16 14:43:44 UTC
Permalink
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).
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! :)
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
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,
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!
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
Marco Pontello via bitcoin-dev
2015-11-16 22:10:49 UTC
Permalink
OK, adding the relevant code fragment is probably the simplest and direct
option. Done.
Post by Jorge Timón via 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).
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! :)
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
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,
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!
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
txs or blocks, if they provide links at all.
Specification
=============
blockchain: <hash/string>
blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
Post by Marco Pontello via bitcoin-dev
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
Post by Marco Pontello via bitcoin-dev
Rationale
=========
I thought about using some more complex scheme, or adding qualifiers
to
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
the
user to select one.
URI, the first time the user visit their website, or launch/install
the
Post by Marco Pontello via bitcoin-dev
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
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
Jorge Timón via bitcoin-dev
2015-11-18 11:29:13 UTC
Permalink
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).
Post by Marco Pontello via bitcoin-dev
OK, adding the relevant code fragment is probably the simplest and direct
option. Done.
Post by Jorge Timón via 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).
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! :)
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
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,
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!
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
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.
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
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
Marco Pontello via bitcoin-dev
2015-11-18 12:31:46 UTC
Permalink
Right, now it should be ok. Thanks.
Post by Jorge Timón via 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).
Post by Marco Pontello via bitcoin-dev
OK, adding the relevant code fragment is probably the simplest and direct
option. Done.
Post by Jorge Timón via 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).
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,
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
maybe...
Now the main change would be to put in a proper BIP number! :)
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
like its simplicity and focus. Good work!
On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
Hi!
To anyone that followed the discussion (from some time ago) about
the
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
proposed new URI for Blockchain references / exploration, I just wanted
to
point out that I have collected the feedback provided, reworked the
text,
https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
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 <
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
explorer when the user look for the details of a transaction (es. Bitcoin
Wallet use BitEasy, Mycelium or Electrum use Blockchain.info,
etc.).
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
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
=============
blockchain: <hash/string>
blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
Rationale
=========
I thought about using some more complex scheme, or adding
qualifiers
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
to
distinguish blocks from txs, but in the end I think that keeping
it
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
simple
should be practical enough. Blockchain explorers can apply the
same
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
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
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
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.
URI, the first time the user visit their website, or
launch/install
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
the
application, or even set themselves if there isn't already one.
Users get the convenience of using always their preferred
explorer,
Post by Marco Pontello via bitcoin-dev
Post by Jorge Timón via bitcoin-dev
Post by Marco Pontello via bitcoin-dev
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
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
Loading...