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 6A3C4ECC for ; Tue, 1 Sep 2015 21:42:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [96.114.154.167]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE2FA1A6 for ; Tue, 1 Sep 2015 21:42:11 +0000 (UTC) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with comcast id Bxho1r0034yXVJQ01xiBty; Tue, 01 Sep 2015 21:42:11 +0000 Received: from crushinator.localnet ([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0]) by resomta-po-06v.sys.comcast.net with comcast id BxiA1r0074eLRLv01xiBsr; Tue, 01 Sep 2015 21:42:11 +0000 From: Matt Whitlock To: Marco Pontello Date: Tue, 01 Sep 2015 17:42:09 -0400 Message-ID: <1842396.ZYjkpCDfSt@crushinator> User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <5546682.RnG4VcateO@crushinator> 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=1441143731; bh=eCkuhigVnBoZR24gaWjWoNrlp5tAj18U+NlLsXVELco=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Cp07LJbngK63PHG7snZqjOaS7ceBqEa0HWyKMYvx6KBCSljTHQGvr2Qt014gUagM+ BtKfCmeST5W++c91h/befWFrC1ACBn8uzMrvkyKry3+Ad/+VmWWc/U229daCJf/DnI r2D9hfgh7g5JMPXsiEyi3Qzgq7UfxyMdZ3hmRAkRO243ADC5H/GbJpoDHiucjAwaCd OzBevKpEDfJ7hIahjPKOuDiN3yhwd0LJhukvWvEdYKHkX/VqTwP+HK0o6fEMcVrI12 cm3XyXv6uioneyOJjeYmvOl42XSy4VGdBc0G9u9yM9hL7sSlrf29WCk6rQ6ZWC4Qjk VnA8+Zo6jDQ9A== 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 Cc: Bitcoin Dev 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: Tue, 01 Sep 2015 21:42:12 -0000 The authority part in a URI is optional. blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd391= 8f76c17f 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 w= ill be > to Bitcoin main net. >=20 > On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock > wrote: >=20 > > Isn't this all backward? The "authority" component of the URL shoul= d > > identify the chain, and the "path" component should identify the pa= rticular > > block, tx, or address in that chain. > > > > So instead of: > > > > > > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24e= cd3918f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c17= 2b3f1b60a8ce26f > > > > It should be: > > > > > > blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1= b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918= f76c17f > > > > And I would agree with allowing well-known chains to register a nam= e, to > > be used as an alternative to the literal, hash syntax: > > > > > > blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f= 6ad2f24ecd3918f76c17f > > > > > > On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote: > > > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Tim=F3n < > > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > > > > > > > I would really prefer chain=3D over network=3D > > > > By chainID I mean the hash of the genesis block, see > > > > > > > > > > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4= c70bdc04809d39 > > > > 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 ri= gorous > > 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/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24e= cd3918f76c17f > > > > > > > > blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24e= cd3918f76c17f?chain=3D000000000019d6689c085ae165831e934ff763ae46a2a6c17= 2b3f1b60a8ce26f > > > > > > > > blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3= 918f76c17f?chain=3Dmain > > > > > > (or a different element name maybe) > > > > > > -- > > > Try the Online TrID File Identifier > > > http://mark0.net/onlinetrid.aspx > > >=20 >=20 >=20 > --=20 > Try the Online TrID File Identifier > http://mark0.net/onlinetrid.aspx