* [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 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 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 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 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 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-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-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-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-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-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 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: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 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: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 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