Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EB88C1161 for ; Sat, 29 Aug 2015 19:01:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [96.114.154.162]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46E90154 for ; Sat, 29 Aug 2015 19:01:26 +0000 (UTC) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-03v.sys.comcast.net with comcast id Aj0w1r00154zqzk01j1Ry3; Sat, 29 Aug 2015 19:01:25 +0000 Received: from crushinator.localnet ([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0]) by resomta-po-11v.sys.comcast.net with comcast id Aj1Q1r0064eLRLv01j1Rem; Sat, 29 Aug 2015 19:01:25 +0000 From: Matt Whitlock To: bitcoin-dev@lists.linuxfoundation.org, Btc Drak Date: Sat, 29 Aug 2015 15:01:23 -0400 Message-ID: <2509151.XgrrNGsCxR@crushinator> User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1440874885; bh=WQEClHqch6hCyWOckhs9M7zEOx76qz59QDc8J5OVn8c=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=HXYw6cBNBuEUHsm6sXBmo3G3IwalhWCMgvOqNSIg1m/CVKWS+njv18NbTbYHHtC8w unPNRjVEezYaTjPduUqh3YjHruOf2w9fXXJTFDgOlqtoG2SOKULlG0Z+dTvwi++AkN 0Y4mVn9ynDcOH52XfxH4xwBxRNePygIM/Is+AkF86zmVMAmLw1+alYqa68dr9eEMye 0AMWhwannyHXr/egPPrTx3C+rt3vSZKWyIyW8meLluROV9nryT6X+3olAioiuh9k7k DgI2hL51/EzYhubmT1817O5583CS4M54iev0+1O+/XAzanLdSKC2yKG8ysWpwca5mK 5ziSER2axE2mQ== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 19:01:27 -0000 That's still not right, since "mainnet" and "testnet" are not host name= s. You'd have to do something like: blockchain:?network=3Dtestnet&txid=3D3b95a766d7a99b87188d6875c8484cb2b3= 10b78459b7816d4dfc3f0f7e04281a 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? >=20 > blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b= 7816d4dfc3f0f7e04281a > blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b= 7816d4dfc3f0f7e04281a >=20 > or >=20 > blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4df= c3f0f7e04281a > blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4df= c3f0f7e04281a?network=3Dtestnet >=20 > On Sat, Aug 29, 2015 at 5: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 i= nclude > > the type looking up. For example: > > > > blockchain://blockhash/00000000000000001003e880d500968d51157f210c63= 2e08a652af3576600198 > > blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4= dfc3f0f7e04281a > > blockchain://block/189000 > > blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn > > > > I think this would help the URI be more human understandable as wel= l as give > > the explorers the ability to optimize a bit what they are looking f= or 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://versi= on which > > would return a list of supported paths, version of the BIP supporte= d, 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 > > > > .=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7= =B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8><(((=BA> > > > > 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 > > 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 pr= opose > > it. > > > > BIP: XX > > Title: URI scheme for Blockchain exploration > > Author: Marco Pontello > > Status: Draft > > Type: Standards Track > > Created: 29 August 2015 > > > > Abstract > > =3D=3D=3D=3D=3D=3D=3D=3D > > This BIP propose a simple URI scheme for looking up blocks, transac= tions, > > addresses on a Blockchain explorer. > > > > Motivation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The purpose of this URI scheme is to enable users to handle all the= > > requests for details about blocks, transactions, etc. with their pr= eferred > > 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. B= itcoin > > 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 partic= ular > > txs or blocks, if they provide links at all. > > > > Specification > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The URI follow this simple form: > > > > blockchain: > > > > Examples: > > > > blockchain:00000000000000001003e880d500968d51157f210c632e08a652af35= 76600198 > > blockchain:001949 > > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f= 7e04281a > > > > Rationale > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > I thought about using some more complex scheme, or adding qualifier= s 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 se= arch > > box. > > > > From the point of view of a wallet developer (or other tool that ne= ed to > > show any kind of Blockchain references), using this scheme mean tha= t 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 blockc= hain: > > 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