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 064E6CF2 for ; Sat, 29 Aug 2015 16:31:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A7BAA7 for ; Sat, 29 Aug 2015 16:31:48 +0000 (UTC) Received: by igui7 with SMTP id i7so33909806igu.1 for ; Sat, 29 Aug 2015 09:31:48 -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=svBVJ/HLpQms3hQO9Z0tyChl+8nBhq1wcnTBqhspNbY=; b=agnXmCJMeQeZMrGw+bpb20sGVUI8swwXcaAYG4K61nStkbqeT8Psn8NWFu0OmKpV02 tsl68LIZlJFOAxSFfcnE+nG5Y3DPuU6/P2U79SA9wQ9Yu1Es4ZMFzkVuM7Z0s6rqrDdL YbQqBOA2EctKlDvUckXh01QG+qcxKxAYa9/K8= 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=svBVJ/HLpQms3hQO9Z0tyChl+8nBhq1wcnTBqhspNbY=; b=ink7csZxAWMTXdjB4nyyqUf4fGSxHeRSr+IdIp4BDa2j1kbznOTex7hy3gnMvdlyL4 2T5/owdi5vpoemR5n5v2aWSvhmL1mBHytw0WX60NwWHV14V39VHdXEUZKEecHlxCDupH s8zurYs7wruKzpK7SGLhvFjUSZweh0pK9J77P6xiZLzaVnZRZ/9Z5tbNhWgQGGFS9/la vBhLd35vw6SG3a1Vqp7sipMV9EQWQzbl72eFC/VlEhgM6GIuBQaizcqb3k3zH6Kt39qf 0476o7rUI8EEc70bNlYWllJCcRMQaS5yYp9Dr316Re+Rpq9XGcwy8H+CCuZtU9Hmc4U5 KsGQ== X-Gm-Message-State: ALoCoQnTlhetnTHVnQx3+uWyglvrkDrRuQqsqZI5hcVWbUoASETX2/RY4asUfY6y1EeYEx0UTP/W X-Received: by 10.50.79.130 with SMTP id j2mr7428550igx.80.1440865908379; Sat, 29 Aug 2015 09:31:48 -0700 (PDT) Received: from [25.21.55.173] ([24.114.58.46]) by smtp.gmail.com with ESMTPSA id hv9sm6015439igb.7.2015.08.29.09.31.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 29 Aug 2015 09:31:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E53F70BF-81CD-4538-BEF8-94BBA346D429 Mime-Version: 1.0 (1.0) From: Richard Moore X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Sat, 29 Aug 2015 12:31:45 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Marco Pontello X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, 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 16:31:50 -0000 --Apple-Mail-E53F70BF-81CD-4538-BEF8-94BBA346D429 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I like the idea of having a standard for this, that all explorers (and even c= ore, eventually) would understand. I would recommend 2 changes though. First, using a real URI scheme, blockcha= in:// so that we can just use normal URL parsing libraries. The bitcoin: thi= ng 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/00000000000000001003e880d500968d51157f210c632e08a652a= f3576600198 blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e= 04281a 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 h= itting 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 l= ook like? Maybe another, related BIP. 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 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 preferred= > 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. 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. >=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:00000000000000001003e880d500968d51157f210c632e08a652af357660019= 8 > blockchain:001949 > blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281= a >=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 simple= > 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 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. >=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, which > can be especially handy on mobile devices, where juggling with cut&paste > is far from ideal. >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-E53F70BF-81CD-4538-BEF8-94BBA346D429 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I like th= e idea of having a standard for this, that all explorers (and even core, eve= ntually) would understand.

I would recommend 2 chan= ges though. First, using a real URI scheme, blockchain:// so that we can jus= t use normal URL parsing libraries. The bitcoin: thing leads to additional c= ode to mutate it into a proper URI before passing it to URL parsing. And I t= hink it would be fine to include the type looking up. For example:

blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3= 576600198
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4= dfc3f0f7e04281a
blockchain://block/189000
blockch= ain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

I think this would help the URI be more human understandable as well a= s 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 blockcha= in://version which would return a list of supported paths, version of the BI= P supported, etc.

The BIP should also s= pecify little endian searching. I'm not sure, but would it also make sense f= or this BIP to include what the return results should look like? Maybe anoth= er, related BIP.

RicMoo

Sent from my self-a= ware 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

On Aug 29, 2015, at 7:48 AM, Marco Pontello via= bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:

Hi!
My first post here, ho= pe I'm following the right conventions.
I had this humble idea for= a while, so I thought to go ahead and propose
it.

<= /div>
BIP: XX
Title: URI scheme for Blockchain exploratio= n
Author: Marco Pontello
Status: Draft
Type: S= tandards Track
Created: 29 August 2015

Ab= stract
=3D=3D=3D=3D=3D=3D=3D=3D
This BIP propose a simpl= e URI scheme for looking up blocks, transactions,
addresses on a B= lockchain explorer.

Motivation
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
The purpose of this URI scheme is to enable use= rs to handle all the
requests for details about blocks, transactio= ns, etc. with their preferred
tool (being that a web service or a l= ocal application).

Currently a Bitcoin client usual= ly point to an arbitrary blockchain
explorer when the user look fo= r the details of a transaction (es. Bitcoin
Wallet use BitEasy, My= celium or Electrum use Blockchain.info, etc.).
Other times resorti= ng to cut&paste is needed.
The same happens with posts and mes= sages that reference some particular
txs or blocks, if they provid= e links at all.

Specification
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
The URI follow this simple form:
=

blockchain: <hash/string>  

Examples:

blockchain:00000000000000001003e8= 80d500968d51157f210c632e08a652af3576600198
blockchain:001949
=
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04= 281a

Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D=
I thought about using some more complex scheme, or adding qualifi= ers to
distinguish blocks from txs, but in the end I think that ke= eping it simple
should be practical enough. Blockchain explorers c= an apply the same
disambiguation rules they are already using to p= rocess the usual search
box. 

=46rom= 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 h= aving
to worry about any specific Blockchain explorer or provide a= means for the
user to select one.

Blockc= hain 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 preferre= d explorer, which
can be especially handy on mobile devices, where= juggling with cut&paste
is far from ideal.


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-E53F70BF-81CD-4538-BEF8-94BBA346D429--