Marco Pontello [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-29 to 2017-11-27
💬 Posted a total of 15 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:07:55

- reply

📅 Original date posted:2017-11-27
📝 Original message:Hi Jeff!
On Mon, Nov 27, 2017 at 3:11 AM, Jeff Johnson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Raw block
> 998,198 bytes
>
> Gzip
> 521,212 bytes (52% ratio)
> (needs 2MB to decompress).
>
I don't know how you got that raw block, but it seems a bit odd.
If you look at it in an hex editor, you'll notice that every odd byte is 0,
and that explain the unusual high compression ratio.
Bye!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171127/4d19aa95/attachment.html>

2023-06-07 17:50:34

- reply

📅 Original date posted:2016-05-10
📝 Original message:On Tue, May 10, 2016 at 8:57 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As part of the hard-fork proposed in the HK agreement(1) we'd like to make
> the
> patented AsicBoost optimisation useless, and hopefully make further similar
> optimizations useless as well.
>
Just in the interest of clarity, I think you should clarify who you are
including in the "we".
Bye!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/2edd63b6/attachment.html>

2023-06-07 17:47:27

- reply

📅 Original date posted:2015-12-30
📝 Original message:Sorry to ask again but... what's up with the BIP number assignments?
I thought that it was just more or less a formality, to avoid conflicts and
BIP spamming. And that would be perfectly fine.
But since I see that it's a process that can take months (just looking at
the PR request list), it seems that something different is going on. Maybe
it's considered something that give an aura of officiality of sorts? But
that would make little sense, since that should come eventually with
subsequents steps (like adding a BIP to the main repo, and eventual
approvation).
Having # 333 assigned to a BIP, should just mean that's easy to refer to a
particular BIP.
That seems something that could be done quick and easily.
What I'm missing? Probably some historic context?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/e6b4259e/attachment.html>

2023-06-07 17:45:00

- reply

📅 Original date posted:2015-11-18
📝 Original message:Right, now it should be ok. Thanks.
On Wed, Nov 18, 2015 at 12:29 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I can always link to the BIP when I reopen that commit as independent
> instead of the other way around.
> Btw, the PR needs rebase (probably the conflict is in the README).
>
> On Mon, Nov 16, 2015 at 11:10 PM, Marco Pontello <marcopon at gmail.com>
> wrote:
> > OK, adding the relevant code fragment is probably the simplest and direct
> > option. Done.
> >
> > On Mon, Nov 16, 2015 at 3:43 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >> Not a native english speaker myself, so I may have missed some things...
> >>
> >> Yes, sorry about the link. I guess you can point to #6230 . I can
> >> rebase it if needed but I would close it again because I don't want to
> >> have too many things from #6382 opened at the same time (is noisy and
> >> worse for review). My plan was to not open it independently at least
> >> until after #6907 (and actually after 0.12 assuming #6907 gets in by
> >> 0.12). But then I would maybe open a new one and reference the old one
> >> rather than reopening #6230 (which tends to be confusing).
> >> I'm not really sure what's the best answer here...but #6382 is
> >> certainly going to need rebase and the link will be broken again.
> >> Maybe one answer is to copy some text from #6230 or the commit and add
> >> it directly to the BIP instead of referencing to that commit (which
> >> will be, at least until #6907 is merged, a moving target).
> >>
> >> On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon at gmail.com>
> >> wrote:
> >> > Thanks for the comments! Now I fixed the typos (hope to have got them
> >> > all,
> >> > English isn't my first language), clarified the chain part a bit, and
> >> > fixed
> >> > the link. There probably is a better way to reference that source code
> >> > part
> >> > with the genesis blocks hashs, in a way that doesn't need to be
> changed,
> >> > maybe...
> >> >
> >> > Now the main change would be to put in a proper BIP number! :)
> >> >
> >> > On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon at jtimon.cc>
> wrote:
> >> >>
> >> >> Thank you for incorporating the feedback, specifically thank you for
> >> >> using the genesis block hash as the unique chain ID.
> >> >>
> >> >> I wen't through the BIP draft and left a few of comments, but I
> really
> >> >> like its simplicity and focus. Good work!
> >> >>
> >> >> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> >> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >> > Hi!
> >> >> >
> >> >> > To anyone that followed the discussion (from some time ago) about
> the
> >> >> > proposed new URI for Blockchain references / exploration, I just
> >> >> > wanted
> >> >> > to
> >> >> > point out that I have collected the feedback provided, reworked the
> >> >> > text,
> >> >> > put the BIP on GitHub and created a pull request:
> >> >> >
> >> >> >
> >> >> >
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> >> >> > https://github.com/bitcoin/bips/pull/202
> >> >> >
> >> >> > The need for an URI for this come to mind again in the last days
> >> >> > looking
> >> >> > at
> >> >> > Eternity Wall, which IMHO provide a use case that we will see more
> >> >> > and
> >> >> > more
> >> >> > in the (near) future: http://eternitywall.it/
> >> >> > Using that service, when you want to check for the proof that a
> >> >> > specific
> >> >> > message was written in the Blockchain, it let you choose from 5
> >> >> > different
> >> >> > explorer.
> >> >> > Mycelium wallet recently added the option to select one of 15 block
> >> >> > explorers.
> >> >> > And there's the crypto_bot on reddit/r/bitcoin that detect
> reference
> >> >> > to
> >> >> > transaction an add a message with links to 7 different explorers.
> >> >> >
> >> >> > I think that's clearly something that's needed.
> >> >> >
> >> >> > Bye!
> >> >> >
> >> >> >
> >> >> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <
> marcopon at gmail.com>
> >> >> > 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
> >> >> >> propose
> >> >> >> it.
> >> >> >>
> >> >> >> BIP: XX
> >> >> >> Title: URI scheme for Blockchain exploration
> >> >> >> Author: Marco Pontello
> >> >> >> Status: Draft
> >> >> >> Type: Standards Track
> >> >> >> Created: 29 August 2015
> >> >> >>
> >> >> >> Abstract
> >> >> >> ========
> >> >> >> This BIP propose a simple URI scheme for looking up blocks,
> >> >> >> transactions,
> >> >> >> addresses on a Blockchain explorer.
> >> >> >>
> >> >> >> Motivation
> >> >> >> ==========
> >> >> >> 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).
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >> Specification
> >> >> >> =============
> >> >> >> The URI follow this simple form:
> >> >> >>
> >> >> >> blockchain: <hash/string>
> >> >> >>
> >> >> >> Examples:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> >> >> blockchain:001949
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >> >> >>
> >> >> >> Rationale
> >> >> >> =========
> >> >> >> 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.
> >> >> >>
> >> >> >> From 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.
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Try the Online TrID File Identifier
> >> >> > http://mark0.net/onlinetrid.aspx
> >> >> >
> >> >> > _______________________________________________
> >> >> > bitcoin-dev mailing list
> >> >> > bitcoin-dev at lists.linuxfoundation.org
> >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 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/20151118/95640aa5/attachment-0001.html>

2023-06-07 17:44:59

- reply

📅 Original date posted:2015-11-16
📝 Original message:OK, adding the relevant code fragment is probably the simplest and direct
option. Done.
On Mon, Nov 16, 2015 at 3:43 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Not a native english speaker myself, so I may have missed some things...
>
> Yes, sorry about the link. I guess you can point to #6230 . I can
> rebase it if needed but I would close it again because I don't want to
> have too many things from #6382 opened at the same time (is noisy and
> worse for review). My plan was to not open it independently at least
> until after #6907 (and actually after 0.12 assuming #6907 gets in by
> 0.12). But then I would maybe open a new one and reference the old one
> rather than reopening #6230 (which tends to be confusing).
> I'm not really sure what's the best answer here...but #6382 is
> certainly going to need rebase and the link will be broken again.
> Maybe one answer is to copy some text from #6230 or the commit and add
> it directly to the BIP instead of referencing to that commit (which
> will be, at least until #6907 is merged, a moving target).
>
> On Mon, Nov 16, 2015 at 1:59 AM, Marco Pontello <marcopon at gmail.com>
> wrote:
> > Thanks for the comments! Now I fixed the typos (hope to have got them
> all,
> > English isn't my first language), clarified the chain part a bit, and
> fixed
> > the link. There probably is a better way to reference that source code
> part
> > with the genesis blocks hashs, in a way that doesn't need to be changed,
> > maybe...
> >
> > Now the main change would be to put in a proper BIP number! :)
> >
> > On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >> Thank you for incorporating the feedback, specifically thank you for
> >> using the genesis block hash as the unique chain ID.
> >>
> >> I wen't through the BIP draft and left a few of comments, but I really
> >> like its simplicity and focus. Good work!
> >>
> >> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > Hi!
> >> >
> >> > To anyone that followed the discussion (from some time ago) about the
> >> > proposed new URI for Blockchain references / exploration, I just
> wanted
> >> > to
> >> > point out that I have collected the feedback provided, reworked the
> >> > text,
> >> > put the BIP on GitHub and created a pull request:
> >> >
> >> >
> https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> >> > https://github.com/bitcoin/bips/pull/202
> >> >
> >> > The need for an URI for this come to mind again in the last days
> looking
> >> > at
> >> > Eternity Wall, which IMHO provide a use case that we will see more and
> >> > more
> >> > in the (near) future: http://eternitywall.it/
> >> > Using that service, when you want to check for the proof that a
> specific
> >> > message was written in the Blockchain, it let you choose from 5
> >> > different
> >> > explorer.
> >> > Mycelium wallet recently added the option to select one of 15 block
> >> > explorers.
> >> > And there's the crypto_bot on reddit/r/bitcoin that detect reference
> to
> >> > transaction an add a message with links to 7 different explorers.
> >> >
> >> > I think that's clearly something that's needed.
> >> >
> >> > Bye!
> >> >
> >> >
> >> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon at gmail.com>
> >> > 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
> >> >> propose
> >> >> it.
> >> >>
> >> >> BIP: XX
> >> >> Title: URI scheme for Blockchain exploration
> >> >> Author: Marco Pontello
> >> >> Status: Draft
> >> >> Type: Standards Track
> >> >> Created: 29 August 2015
> >> >>
> >> >> Abstract
> >> >> ========
> >> >> This BIP propose a simple URI scheme for looking up blocks,
> >> >> transactions,
> >> >> addresses on a Blockchain explorer.
> >> >>
> >> >> Motivation
> >> >> ==========
> >> >> 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).
> >> >>
> >> >> 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.
> >> >>
> >> >> Specification
> >> >> =============
> >> >> The URI follow this simple form:
> >> >>
> >> >> blockchain: <hash/string>
> >> >>
> >> >> Examples:
> >> >>
> >> >>
> >> >>
> >> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> >> blockchain:001949
> >> >>
> >> >>
> >> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >> >>
> >> >> Rationale
> >> >> =========
> >> >> 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.
> >> >>
> >> >> From 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.
> >> >>
> >> >> 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.
> >> >>
> >> >> 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.
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Try the Online TrID File Identifier
> >> > http://mark0.net/onlinetrid.aspx
> >> >
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev at lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >
> >
> >
> >
> >
> > --
> > 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/20151116/88c6c760/attachment-0001.html>

2023-06-07 17:44:58

- reply

📅 Original date posted:2015-11-15
📝 Original message:Thanks for the comments! Now I fixed the typos (hope to have got them all,
English isn't my first language), clarified the chain part a bit, and fixed
the link. There probably is a better way to reference that source code part
with the genesis blocks hashs, in a way that doesn't need to be changed,
maybe...
Now the main change would be to put in a proper BIP number! :)
On Sun, Nov 15, 2015 at 12:42 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Thank you for incorporating the feedback, specifically thank you for
> using the genesis block hash as the unique chain ID.
>
> I wen't through the BIP draft and left a few of comments, but I really
> like its simplicity and focus. Good work!
>
> On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hi!
> >
> > To anyone that followed the discussion (from some time ago) about the
> > proposed new URI for Blockchain references / exploration, I just wanted
> to
> > point out that I have collected the feedback provided, reworked the text,
> > put the BIP on GitHub and created a pull request:
> >
> > https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
> > https://github.com/bitcoin/bips/pull/202
> >
> > The need for an URI for this come to mind again in the last days looking
> at
> > Eternity Wall, which IMHO provide a use case that we will see more and
> more
> > in the (near) future: http://eternitywall.it/
> > Using that service, when you want to check for the proof that a specific
> > message was written in the Blockchain, it let you choose from 5 different
> > explorer.
> > Mycelium wallet recently added the option to select one of 15 block
> > explorers.
> > And there's the crypto_bot on reddit/r/bitcoin that detect reference to
> > transaction an add a message with links to 7 different explorers.
> >
> > I think that's clearly something that's needed.
> >
> > Bye!
> >
> >
> > On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon at gmail.com>
> 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 propose
> >> it.
> >>
> >> BIP: XX
> >> Title: URI scheme for Blockchain exploration
> >> Author: Marco Pontello
> >> Status: Draft
> >> Type: Standards Track
> >> Created: 29 August 2015
> >>
> >> Abstract
> >> ========
> >> This BIP propose a simple URI scheme for looking up blocks,
> transactions,
> >> addresses on a Blockchain explorer.
> >>
> >> Motivation
> >> ==========
> >> 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).
> >>
> >> 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.
> >>
> >> Specification
> >> =============
> >> The URI follow this simple form:
> >>
> >> blockchain: <hash/string>
> >>
> >> Examples:
> >>
> >>
> >>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >> blockchain:001949
> >>
> >>
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> >>
> >> Rationale
> >> =========
> >> 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.
> >>
> >> From 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>
> >
> >
> >
> > --
> > Try the Online TrID File Identifier
> > http://mark0.net/onlinetrid.aspx
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
--
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/20151116/978ce25b/attachment-0001.html>

2023-06-07 17:44:57

- reply

📅 Original date posted:2015-11-15
📝 Original message:Hi!
To anyone that followed the discussion (from some time ago) about the
proposed new URI for Blockchain references / exploration, I just wanted to
point out that I have collected the feedback provided, reworked the text,
put the BIP on GitHub and created a pull request:
https://github.com/MarcoPon/bips/blob/master/bip-MarcoPon-01.mediawiki
https://github.com/bitcoin/bips/pull/202
The need for an URI for this come to mind again in the last days looking at
Eternity Wall, which IMHO provide a use case that we will see more and more
in the (near) future: http://eternitywall.it/
Using that service, when you want to check for the proof that a specific
message was written in the Blockchain, it let you choose from 5 different
explorer.
Mycelium wallet recently added the option to select one of 15 block
explorers.
And there's the crypto_bot on reddit/r/bitcoin that detect reference to
transaction an add a message with links to 7 different explorers.
I think that's clearly something that's needed.
Bye!
On Sat, Aug 29, 2015 at 1:48 PM, Marco Pontello <marcopon at gmail.com> 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 propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> 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).
>
> 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.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> 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.
>
> From 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.
>
> 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.
>
> 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.
>
>
>
--
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/20151115/0a084af7/attachment.html>

2023-06-07 17:44:25

- reply

📅 Original date posted:2015-11-11
📝 Original message:A random thought: aren't most communication over a data link already
compressed, at some point?
When I used a modem, we had the V.42bis protocol. Now, nearly all ADSL
connections using PPPoE, surely are. And so on.
I'm not sure another level of generic, data agnostic kind of compression
will really give us some real-life practical advantage over that.
Something that could take advantage of of special knowledge of the specific
data, instead, would be an entirely different matter.
Just my 2c.
On Wed, Nov 11, 2015 at 7:35 PM, Peter Tschipper via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Here are the latest results on compression ratios for the first 295,000
> blocks, compressionlevel=6. I think there are more than enough datapoints
> for statistical significance.
>
> Results are very much similar to the previous test. I'll work on getting
> a comparison between how much time savings/loss in time there is when
> syncing the blockchains: compressed vs uncompressed. Still, I think it's
> clear that serving up compressed blocks, at least historical blocks, will
> be of benefit for those that have bandwidth caps on their internet
> connections.
>
> The proposal, so far is fairly simple:
> 1) compress blocks with some compression library: currently zlib but I can
> investigate other possiblities
> 2) As a fall back we need to advertise compression as a service. That way
> we can turn off compression AND decompression completely if needed.
> 3) Do the compression at the datastream level in the code. CDataStream is
> the obvious place.
>
>
> Test Results:
>
> range = block size range
> ubytes = average size of uncompressed blocks
> cbytes = average size of compressed blocks
> ctime = average time to compress
> dtime = average time to decompress
> cmp_ratio% = compression ratio
> datapoints = number of datapoints taken
>
> range ubytes cbytes ctime dtime cmp_ratio% datapoints
> 0-250b 215 189 0.001 0.000 12.40 91280
> 250-500b 438 404 0.001 0.000 7.85 13217
> 500-1KB 761 701 0.001 0.000 7.86
> 11434
> 1KB-10KB 4149 3547 0.001 0.000 14.51 52180
> 10KB-100KB 41934 32604 0.005 0.001 22.25 82890
> 100KB-200KB 146303 108080 0.016 0.001 26.13 29886
> 200KB-300KB 243299 179281 0.025 0.002 26.31 25066
> 300KB-400KB 344636 266177 0.036 0.003 22.77 4956
> 400KB-500KB 463201 356862 0.046 0.004 22.96 3167
> 500KB-600KB 545123 429854 0.056 0.005 21.15 366
> 600KB-700KB 647736 510931 0.065 0.006 21.12 254
> 700KB-800KB 746540 587287 0.073 0.008 21.33 294
> 800KB-900KB 868121 682650 0.087 0.008 21.36 199
> 900KB-1MB 945747 726307 0.091 0.010 23.20 304
>
> On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
>
> Comments:
>
> 1) cblock seems a reasonable way to extend the protocol. Further wrapping
> should probably be done at the stream level.
>
> 2) zlib has crappy security track record.
>
> 3) A fallback path to non-compressed is required, should compression fail
> or crash.
>
> 4) Most blocks and transactions have runs of zeroes and/or highly common
> bit-patterns, which contributes to useful compression even at smaller
> sizes. Peter Ts's most recent numbers bear this out. zlib has a
> dictionary (32K?) which works well with repeated patterns such as those you
> see with concatenated runs of transactions.
>
> 5) LZO should provide much better compression, at a cost of CPU
> performance and using a less-reviewed, less-field-tested library.
>
>
>
>
>
> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev <
> <bitcoin-dev at lists.linuxfoundation.org>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper <
>> <peter.tschipper at gmail.com>peter.tschipper at gmail.com> wrote:
>>
>>> There are better ways of sending new blocks, that's certainly true but
>>> for sending historical blocks and seding transactions I don't think so.
>>> This PR is really designed to save bandwidth and not intended to be a huge
>>> performance improvement in terms of time spent sending.
>>>
>>
>> If the main point is for historical data, then sticking to just blocks is
>> the best plan.
>>
>> Since small blocks don't compress well, you could define a "cblocks"
>> message that handles multiple blocks (just concatenate the block messages
>> as payload before compression).
>>
>> The sending peer could combine blocks so that each cblock is compressing
>> at least 10kB of block data (or whatever is optimal). It is probably worth
>> specifying a maximum size for network buffer reasons (either 1MB or 1 block
>> maximum).
>>
>> Similarly, transactions could be combined together and compressed
>> "ctxs". The inv messages could be modified so that you can request groups
>> of 10-20 transactions. That would depend on how much of an improvement
>> compressed transactions would represent.
>>
>> More generally, you could define a message which is a compressed message
>> holder. That is probably to complex to be worth the effort though.
>>
>>
>>
>>>
>>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev <
>>> <bitcoin-dev at lists.linuxfoundation.org>
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev <
>>>> <bitcoin-dev at lists.linuxfoundation.org>
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>
>>>>> I think 25% bandwidth savings is certainly considerable, especially
>>>>> for people running full nodes in countries like Australia where internet
>>>>> bandwidth is lower and there are data caps.
>>>>>
>>>>
>>>> This reinforces the idea that such trade-off decisions should be be
>>>> local and negotiated between peers, not a required feature of the network
>>>> P2P.
>>>>
>>>>
>>>> --
>>>> Johnathan Corgan
>>>> Corgan Labs - SDR Training and Development Services
>>>> <http://corganlabs.com>http://corganlabs.com
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
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/20151111/0430cab2/attachment-0001.html>

2023-06-07 17:39:29

- reply

📅 Original date posted:2015-09-03
📝 Original message:None that I can see.
In fact I was just about to ask for some details about this part of the
process, so this come just at the right time.
On Fri, Sep 4, 2015 at 1:18 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The process in BIP01 was written when we used a different solution for
> storing and presenting BIPs.
>
> I'm thinking of suggesting that the number request process be changed
> to opening a pull req with BIP text with no number (e.g. just using
> the authors name and an index as the number) as the mechenism to
> request number assignment.
>
> Is there any reason that anyone would find this objectionable?
>
> (Please do not respond to this message with anything but a strictly
> directed answer to that question, start a new thread for a different
> subject. Thanks!)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
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/20150904/ba32510a/attachment.html>

2023-06-07 17:39:10

- reply

📅 Original date posted:2015-09-01
📝 Original message:On Sat, Aug 29, 2015 at 9:28 PM, Richard Moore <me at ricmoo.com> wrote:
> Yes! Good point, network should be encoded. Not sure I like this format
> yet, but what if it was part of the authority, like block:testnet. Like
> http uses port 80 by default, you could have block by default refer to
> block:mainnet.
>
> Eg.
>
> blockchain://tx:testnet3/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I will read the RFC over more thoroughly tomorrow to get an idea of what
> types of things make more or less sense.
Like this option too!
--
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/ff752f04/attachment.html>

2023-06-07 17:39:09

- reply

📅 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>

2023-06-07 17:39:08

- reply

📅 Original date posted:2015-09-01
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/fa329e12/attachment.html>

2023-06-07 17:39:07

- reply

📅 Original date posted:2015-09-01
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/68c31b7b/attachment.html>

2023-06-07 17:39:07

- reply

📅 Original date posted:2015-09-01
📝 Original message:That surely make sense.
A URI like that perfectly readable, unambiguous and simple enough.
And nice to see a Wallet developer showing interest for this! :)
On Sat, Aug 29, 2015 at 8:07 PM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 08/29/2015 06: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
> > include the type looking up. For example:
> >
> >
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> >
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> > blockchain://block/189000
> > blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> Good thinking! It might make sense to look at the existing de-facto
> standard (e.g. blockexplorer.com, blockchain.info):
>
> /tx/ for transactions
> /block/ for blocks, supports both hash or height
> /address/ for address
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
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/0b36091b/attachment.html>

2023-06-07 17:38:25

- reply

📅 Original date posted:2015-08-29
📝 Original message: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.
BIP: XX
Title: URI scheme for Blockchain exploration
Author: Marco Pontello
Status: Draft
Type: Standards Track
Created: 29 August 2015
Abstract
========
This BIP propose a simple URI scheme for looking up blocks, transactions,
addresses on a Blockchain explorer.
Motivation
==========
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).
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.
Specification
=============
The URI follow this simple form:
blockchain: <hash/string>
Examples:
blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
blockchain:001949
blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
Rationale
=========
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.
>From 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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/2c19c922/attachment.html>