Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrepancies between address types in Bitcoin Core and Blocksci #112

Closed
satwo opened this issue May 22, 2018 · 1 comment
Closed

Discrepancies between address types in Bitcoin Core and Blocksci #112

satwo opened this issue May 22, 2018 · 1 comment
Labels
enhancement fixed-in-v0.6 This issue has been resolved in the development version (available on the v0.6 branch)
Milestone

Comments

@satwo
Copy link

satwo commented May 22, 2018

I've noticed a couple of discrepancies between the address types parsed in Bitcoin Core (https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp) and those in Blocksci (https://citp.github.io/BlockSci/reference/addresses/types.html):

  1. The "witness_unknown" type in Bitcoin Core (mostly in place for backwards compatibility for new versions of segwit scripts). Will this be supported in future versions of Blocksci?
  2. The "Multisig_Pubkey" address type in Blocksci (distinguished from "plain" Multisig and Pubkey), which doesn't have a direct analogue in Core that I can see. Is there any documentation for this?

Thanks for the great work on this fantastic project!

@hkalodner
Copy link
Collaborator

Hi @satwo,

I'm glad you're enjoying using BlockSci. We definitely need to increase the amount of documentation since most of it is just an API reference currently The multisig pubkey type is a special type for describing the pubkey addresses that are components of a multisig address. Bitcoin Core doesn't need any representation of this since it doesn't handle them at all. BlockSci uses them to allow you to find multisig addresses containing a given pubkey.

The "witness_unknown" type is just an oversight. BlockSci should add this. I'll include this in the next data format update. I don't think that existed when I added segwit support initially though I could have just missed it. It's not to big an issue since they're currently just treated as nonstandard addresses and I don't know how many of them there are, but it'd be good to support them.

@maltemoeser maltemoeser added this to the v0.6 milestone Oct 22, 2018
@maltemoeser maltemoeser added the fixed-in-v0.6 This issue has been resolved in the development version (available on the v0.6 branch) label May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement fixed-in-v0.6 This issue has been resolved in the development version (available on the v0.6 branch)
Projects
None yet
Development

No branches or pull requests

3 participants