Re: [bitcoin-dev] Block compression
Hi Jeff! On Mon, Nov 27, 2017 at 3:11 AM, Jeff Johnson via bitcoin-dev < bitcoin-dev@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! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making AsicBoost irrelevant
On Tue, May 10, 2016 at 8:57 PM, Peter Todd via bitcoin-dev < bitcoin-dev@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! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP numbers
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! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Right, now it should be ok. Thanks. On Wed, Nov 18, 2015 at 12:29 PM, Jorge Timón 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 > 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 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 > >> 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 > 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 > >> >> 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! > >> >> > > >> >
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 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 > 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 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 > >> 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 > >> > 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. w
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 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 > 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 > 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: > >> > >> Examples: > >> > >> > >> > blockchain:1003e880d500968d51157f210c632e08a652af3576600198 > >> 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
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 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: > > Examples: > > blockchain:1003e880d500968d51157f210c632e08a652af3576600198 > 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] request BIP number for: "Support for Datastream Compression"
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@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 ubytescbytesctimedtimecmp_ratio%datapoints > 0-250b 2151890.0010.00012.40 91280 > 250-500b4384040.0010.0007.85 13217 > 500-1KB 7617010.0010.0007.86 > 11434 > 1KB-10KB414935470.0010.000 14.51 52180 > 10KB-100KB 41934326040.0050.00122.25 82890 > 100KB-200KB 1463031080800.0160.00126.1329886 > 200KB-300KB 2432991792810.0250.00226.3125066 > 300KB-400KB 3446362661770.0360.00322.774956 > 400KB-500KB 4632013568620.0460.00422.963167 > 500KB-600KB 5451234298540.0560.00521.15366 > 600KB-700KB 6477365109310.0650.00621.12254 > 700KB-800KB 7465405872870.0730.00821.33294 > 800KB-900KB 8681216826500.0870.00821.36199 > 900KB-1MB 9457477263070.0910.01023.20304 > > 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@lists.linuxfoundation.org> wrote: > >> >> >> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper < >> peter.tschip...@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 improveme
Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Try the Online TrID File Identifier http://mark0.net/onlinetrid.aspx ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
Oh, my bad! Right, sounds pretty good to me then. On Tue, Sep 1, 2015 at 11:42 PM, Matt Whitlock 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 > > 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=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > > > > > It should be: > > > > > > > > > > blockchain://0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/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@lists.linuxfoundation.org> wrote: > > > > > > > > > > > > > > I would really prefer chain= over > network= > > > > > 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=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > > > > > > > > > > > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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 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=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > It should be: > > > blockchain://0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f/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@lists.linuxfoundation.org> wrote: > > > > > > > > I would really prefer chain= over network= > > > 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=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f > > > > > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
On Sat, Aug 29, 2015 at 9:28 PM, Richard Moore 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I would really prefer chain= over network= > 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=0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f blockchain://ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f?chain=main (or a different element name maybe) -- Try the Online TrID File Identifier http://mark0.net/onlinetrid.aspx ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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@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/1003e880d500968d51157f210c632e08a652af3576600198 > > > 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Try the Online TrID File Identifier http://mark0.net/onlinetrid.aspx ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration
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: Examples: blockchain:1003e880d500968d51157f210c632e08a652af3576600198 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
