BIP 122: URI scheme for Blockchain references / exploration #202

Maybe it would be worth to clarify that when this is not provided, the block explorer will default to some value. Assuming they want to default to the main bitcoin chain, they will usually default to 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.

Also the link seems broken. An updated version of that commit is contained in #6382, in https://github.com/jtimon/bitcoin/commit/599019a9127abb1ada30eaf2c1e7b38e5d4239ec (but that commit will need to be rebased again as 6382's sub-PRs get merged/closed). It was once opened independently as #6230 but it is closed for now.

@jtimon Thanks for your remarks/help. In your opinion, what could be a better way to provide a reference to "where those hashes come out", for that "(see $something)" part?. The direct GitHub reference is indeed probably not the best suited one.

Copied from ml (awaiting moderation):

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).

Third person, s/point/points, s/look/looks.

There's a flaw with the //chain genesis block to specific alt chains. Not all altcoins have a unique genesis block. For example, Feathercoin has the same genesis block as Litecoin and was a deliberate mid-chain fork. If Bitcoin were to experience a chain split into two coins, the same would be true.

Maybe in those instance the hash of the relevant first block after the fork could be used? In a sense that would be a kind of new "genesis" for that chain.

That would work, but you'll have to specify it explicitly in the spec.

OK, perfect.

Maybe in those instance the hash of the relevant first block after the fork could be used?

I think this is the only solution that makes sense. I think it would be good to define this hash as the chain ID to maybe used that notion in other BIPs or documentation.

So the two periods may be changed into: "(optional) to uniquely point to a specific chain, the corresponding chain ID is used (hash of genesis block, or first block after fork for forked chains)." ?

You're just looking for a hash that will be unique, so really you need either the genesis or the "fork genesis" hash. If later feathercoin was to fork again, the new coin would be the next fork hash. This way you have a unique identifier for each chain. I suggest keeping exactly the same format, but just explain what //chain means, i.e. it is usually the genesis hash, but it could also be a fork hash (citing feathercoin as the example).

Yes, I already changed it to explain that, I think.

ACK on defining the chain ID as "the first block hash that uniquely identifies the chain, usually the hash of the genesis block, but it may be the first incompatible block for forked chains" or something of the sort. I just think it would be nice to be able to link to this BIP when someone asks "what do you mean the chain ID?". I'm fine with @MarcoPon's wording too, I'm not sure what's @btcdrak's concern with defining the chain ID (if any).

Can you add the following?

Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010712.html

Sure!

This is not in chainparams.cpp (yet?), and judging from how long the requirement of introducing a factory is getting ( #6907 is just my last attempt, see #5229 for an older failed attempt), by the time something like https://github.com/jtimon/bitcoin/commit/160d874dfdb53c71a07b1bf7bdd0dab571dabefa is merged (hopefully this decade), we will probably be using c++11 (or c++14) and that boost::assign::map_list_of won't have ever touched chainparams.cpp. Maybe you can refer to that commit directly, I plan to close #6382 and replace it with something that introduces a new chain without depending on #6625 (which I have finally decided to abandon), so we won't have the "this branch will be constantly rebased" problem anymore (and #6625 was the part of #6382 that needed rebase more often). Maybe @laanwj and/or @sipa have some other suggestion?

I would drop In principle some kind of alias/mnemonic could also be used, but that is out of the scope of this BIP, and maybe could be developed in another subsequent one. it's not relevant to the specification.

For forked chains, the hash of the relevant first block after fork is used.

Drop "relevant". It is specifically the first block that diverges from the original chain onto the new fork. I would mention Feathercoin's checkpoint forking from Litecoin as an example.

Drop the "In principle ... another subsequent one." text. It only confuses the issue.

What about querying by scriptPubKey?

I used the items generally linked / used on block explorers, but I suppose it could be added. BTW, how about other items that may become relevant when segwit is implemented?

Explorers haven't offered search by scriptPubKey yet. It would be useful to some I'm sure, though even Core declined a PR for arbitrary scriptPubKey indexing.