From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F13D511C7 for ; Sat, 29 Aug 2015 19:24:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19FEEA7 for ; Sat, 29 Aug 2015 19:24:16 +0000 (UTC) Received: by ioej130 with SMTP id j130so41460244ioe.3 for ; Sat, 29 Aug 2015 12:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DEMHZ37nAJVqnVwGfeu3SgxCokKW3DEbeZd6oPO0tPU=; b=a6o4IZmg0pV2VjCRUuopCEznVSynb0KGI13EWDuunaPJBbegylAMYJMUoddzXpGkVu LmwvOBu4YTNeYaGBecpGgq0OGLeR4CJR8DRKz7n5NSzyW/O0Aw+x5JS3N8ZLeKTHB/Li FZdXHlBKRZWJhebKgR5op2UYL/bhoY5/qJs9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DEMHZ37nAJVqnVwGfeu3SgxCokKW3DEbeZd6oPO0tPU=; b=Tb2famo9HcpQTs1MfQQMl9aSzQktszqXtVnN/n1fNI/E+CHpaOVlDT5rEavUjdbkJ5 KnWMw9hCrQHCQBlQq/A61L+9TgrKzufTuzQsjKu8Wjla95gPaP3ZmncIxJeDvndTIzr7 cZpxOAm1pNQFBc0l3+ahKuFMEZQhEHJpdyN4RzoM3Q/YqkxauKijR8RtJbUYqhOR7F1Y Rjd9v93cRip+m5YCrh+f1iyXSBCwYdg7p/mbqRC1idsfcDnWhmN9OSqCDyOXw9a6VIPJ SD5r+to3kUCeqLgHrcYj4h+3N4USKH9OqD3pbD/jiAWU9MvR+6wxd83NgEQxIc5MC9jn 7uCw== X-Gm-Message-State: ALoCoQn0VIrOQTdajqRgNgl3HL8rO35CP+poJHX1j/nynNanH/sorVlXJVd9lxZyjBlIP7da3slc X-Received: by 10.107.10.162 with SMTP id 34mr19165418iok.139.1440876255521; Sat, 29 Aug 2015 12:24:15 -0700 (PDT) Received: from [25.21.55.173] ([24.114.59.155]) by smtp.gmail.com with ESMTPSA id o23sm5261367ioi.8.2015.08.29.12.24.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Aug 2015 12:24:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Richard Moore X-Mailer: iPhone Mail (12H321) In-Reply-To: <205843673.xtKUGbbkqt@crushinator> Date: Sat, 29 Aug 2015 15:24:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <205843673.xtKUGbbkqt@crushinator> To: Matt Whitlock X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "bitcoin-dev@lists.linuxfoundation.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:24:17 -0000 I apologize, you are correct, I should not have used the word "real".=20 However, if you look at section 3 of the RFC, the first hierarchal level (wh= ich in http is used to describe hosts) can be any "authority", not necessari= ly a hostname. So, you could use tx, block, address, etc. as the authority for their paths.= RicMoo Sent from my self-aware iPhone .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8= .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8= .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=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 1:19 PM, Matt Whitlock wrote: >=20 > bitcoin:12345 *is* a "real" URI. It's just not an absolute, hierarchical U= RI (a.k.a. a URL); rather, it's an opaque URI. >=20 > And your suggestion is actually in violation of the URI spec, since "block= hash", "txid", "block", and "address" are not host names. >=20 > More correct would be: >=20 > blockchain:?blockhash=3D00000000000000001003e880d500968d51157f210c632e08a6= 52af3576600198 > blockchain:?txid=3D3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0= f7e04281a > blockchain:?block=3D189000 > blockchain:?address=3D1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn >=20 > You should read the URI syntax RFC: https://tools.ietf.org/html/rfc3986 >=20 >=20 >> On Saturday, 29 August 2015, at 12:31 pm, Richard Moore via bitcoin-dev w= rote: >> I like the idea of having a standard for this, that all explorers (and ev= en core, eventually) would understand. >>=20 >> I would recommend 2 changes though. First, using a real URI scheme, block= chain:// so that we can just use normal URL parsing libraries. The bitcoin: t= hing leads to additional code to mutate it into a proper URI before passing i= t to URL parsing. And I think it would be fine to include the type looking u= p. For example: >>=20 >> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a6= 52af3576600198 >> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0= f7e04281a >> blockchain://block/189000 >> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn >>=20 >> I think this would help the URI be more human understandable as well as g= ive the explorers the ability to optimize a bit what they are looking for wh= en hitting various databases. >>=20 >> A possible future path could also include blockchain://tx/123000/4 for bl= ock height, tx index... Another possibility could be blockchain://version wh= ich would return a list of supported paths, version of the BIP supported, et= c. >>=20 >> The BIP should also specify little endian searching. I'm not sure, but wo= uld it also make sense for this BIP to include what the return results shoul= d look like? Maybe another, related BIP. >>=20 >>> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev wrote: >>>=20 >>> 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. >>>=20 >>> BIP: XX >>> Title: URI scheme for Blockchain exploration >>> Author: Marco Pontello >>> Status: Draft >>> Type: Standards Track >>> Created: 29 August 2015 >>>=20 >>> Abstract >>> =3D=3D=3D=3D=3D=3D=3D=3D >>> This BIP propose a simple URI scheme for looking up blocks, transactions= , >>> addresses on a Blockchain explorer. >>>=20 >>> 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 preferr= ed >>> tool (being that a web service or a local application). >>>=20 >>> Currently a Bitcoin client usually point to an arbitrary blockchain >>> explorer when the user look for the details of a transaction (es. Bitcoi= n >>> 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. >>>=20 >>> Specification >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> The URI follow this simple form: >>>=20 >>> blockchain: =20 >>>=20 >>> Examples: >>>=20 >>> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600= 198 >>> blockchain:001949 >>> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e042= 81a >>>=20 >>> Rationale >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 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 simp= le >>> should be practical enough. Blockchain explorers can apply the same >>> disambiguation rules they are already using to process the usual search >>> box.=20 >>>=20 >>> =46rom the point of view of a wallet developer (or other tool that need t= o >>> 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 havin= g >>> to worry about any specific Blockchain explorer or provide a means for t= he >>> user to select one. >>>=20 >>> 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. >>>=20 >>> Users get the convenience of using always their preferred explorer, whic= h >>> can be especially handy on mobile devices, where juggling with cut&paste= >>> is far from ideal. >=20