📅 Original date posted:2015-09-01
📝 Original message:Oh, my bad! Right, sounds pretty good to me then.
On Tue, Sep 1, 2015 at 11:42 PM, Matt Whitlock <bip at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/1e897ea9/attachment.html>;
Marco Pontello [ARCHIVE] /
npub12s…wdn3h
2023-06-07 17:39:09
in reply to nevent1q…9e56
Author Public Key
npub12srjs7mc5grqhm86mngax037h3v75wvx8tpd55cfhmkj6dagqxrqmwdn3hPublished at
2023-06-07 17:39:09Event JSON
{
"id": "ba507f2d485c01f5cf4b7cd1fcee048840d9aaa77af95534cd0696cfd5b6b660",
"pubkey": "5407287b78a2060becfadcd1d33e3ebc59ea39863ac2da5309beed2d37a80186",
"created_at": 1686159549,
"kind": 1,
"tags": [
[
"e",
"adae20868ecaee3485c1f73b7cbb076c6c1ffdd38a33c7ea438129dbb9aa31c8",
"",
"root"
],
[
"e",
"9a4a2eca072770e325b397c556b0707695172db1f9e87ca287e7ccb4e9ebb42e",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2015-09-01\n📝 Original message:Oh, my bad! Right, sounds pretty good to me then.\n\nOn Tue, Sep 1, 2015 at 11:42 PM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e\nwrote:\n\n\u003e The authority part in a URI is optional.\n\u003e\n\u003e\n\u003e blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f\n\u003e\n\u003e Notice the lack of a double-slash.\n\u003e\n\u003e\n\u003e On Tuesday, 1 September 2015, at 11:38 pm, Marco Pontello wrote:\n\u003e \u003e I see your point. But I personally like that the chain part could be\n\u003e \u003e optional, given that the vast majority of the references in the end will\n\u003e be\n\u003e \u003e to Bitcoin main net.\n\u003e \u003e\n\u003e \u003e On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e\n\u003e \u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Isn't this all backward? The \"authority\" component of the URL should\n\u003e \u003e \u003e identify the chain, and the \"path\" component should identify the\n\u003e particular\n\u003e \u003e \u003e block, tx, or address in that chain.\n\u003e \u003e \u003e\n\u003e \u003e \u003e So instead of:\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f\n\u003e \u003e \u003e\n\u003e \u003e \u003e It should be:\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f\n\u003e \u003e \u003e\n\u003e \u003e \u003e And I would agree with allowing well-known chains to register a name,\n\u003e to\n\u003e \u003e \u003e be used as an alternative to the literal, hash syntax:\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://bitcoin/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e On Tuesday, 1 September 2015, at 4:49 pm, Marco Pontello wrote:\n\u003e \u003e \u003e \u003e On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón \u003c\n\u003e \u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e I would really prefer chain=\u003cchainID\u003e over\n\u003e network=\u003cchainPetnameStr\u003e\n\u003e \u003e \u003e \u003e \u003e By chainID I mean the hash of the genesis block, see\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39\n\u003e \u003e \u003e \u003e \u003e I'm completely fine with doing that using an optional parameter\n\u003e (for\n\u003e \u003e \u003e \u003e \u003e backwards compatibility).\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e I see that using the genesis block hash would be the perfectly\n\u003e rigorous\n\u003e \u003e \u003e way\n\u003e \u003e \u003e \u003e to do it, but what do you think about the possibility of letting\n\u003e also use\n\u003e \u003e \u003e \u003e the name constants, as a simple / more relaxed alternative? That\n\u003e would\n\u003e \u003e \u003e \u003e spare a source lookup just to write a correct reference to a tx,\n\u003e maybe\n\u003e \u003e \u003e in a\n\u003e \u003e \u003e \u003e forum or a post.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e So a reference to a certain tx could be either:\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e (or a different element name maybe)\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e --\n\u003e \u003e \u003e \u003e Try the Online TrID File Identifier\n\u003e \u003e \u003e \u003e http://mark0.net/onlinetrid.aspx\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Try the Online TrID File Identifier\n\u003e \u003e http://mark0.net/onlinetrid.aspx\n\u003e\n\n\n\n-- \nTry the Online TrID File Identifier\nhttp://mark0.net/onlinetrid.aspx\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/1e897ea9/attachment.html\u003e",
"sig": "7b862394b5e35013e0bbef43dd2ae6df16dde5e4497fa2fa475f11b68f19fcdb044a1d77aae7e8bee18e22d6b6f490cfe0cbad551201d815a41af0e1768505f3"
}