Add BIP34 height to `parentblock` decoded JSON object
JeremyRand opened this issue · 5 comments
Is your feature request related to a problem? Please describe.
Namecoin has many parent chains used in production, e.g. Bitcoin, BCH, BSV, and DigiByte. I need an easy way to determine the parent chain of a given sidechain block.
Describe the solution you'd like
Comparing the difficulty and timestamp of a given parent block to the difficulty and timestamp of a given parent chain at the same height is an easy way to determine if the sidechain block used that chain as a parent. See namecoin/nmc-rpc-explorer#6 . BIP34 makes it easy to determine the parent block's height, but Namecoin Core does not expose this as a JSON field, so manually parsing the parent coinbase is needed right now. Adding a height JSON field to parentblock would solve this.
Describe alternatives you've considered
Right now I'm building an index mapping timestamps to difficulties for each parent chain, but this is much more resource-intensive and bandwidth-intensive.
Additional context
N/A.
Hm, that's an interesting idea - however it seems a bit out of scope for something that Namecoin Core does? As you say, it is kind of easy to do by an external data consumer, in case they have a use for it. I think this is something that should probably be handled externally (e.g. on the explorer side instead of Core).
@domob1812 I'm not sure I see why it's out of scope. The getblock RPC method includes a height field in its response; I don't see any reason (from a high-level user's point of view) why the parent block should be different. Implementation-wise, it's calculated using different logic, but I don't think that kind of implementation detail should matter to the user. (It's also nontrivial for some external applications to do, since they would need a partial Bitcoin script parser in order to read the BIP34 height from the coinbase string, whereas Namecoin Core already has a parser for that built in and can do so trivially.)
I guess that can be debated. The height of blocks is definitely something far more important to far more users than the parent-chain-height of an auxpow block. But then if you think that is something we should have, I don't think there are strong reasons against it, assuming any implementation is done properly and well tested.
Of course, it should also properly handle edge cases where the parent block isn't actually a real block, or doesn't include a BIP34 height for some reason.
Do you realize that side-chains do not use the same coins as the main-chain?
When you talk about side-chains in Bitcoin, you're referring to a completely different coin that must be exchanged for the main coin when spending it. Side-chains are a total sham.
In theory, Bitcoins can be created out of thin air and then transferred from the side-chain to the main-chain.
Blockstream Inc., a for-profit corporation, developed and implemented the entire side-chain concept.
@redarmyfaction You're thinking of pegged sidechains, which have nothing to do with this issue (which is about the merge-mined sidechains protocol that Namecoin implemented in 2011). If you want to talk about issues with pegged sidechains, that belongs in a separate issue (but I don't think anyone at Namecoin is currently working on anything related to pegged sidechains, so there's not much point trying to convince us that they're problematic).