Matching bare-pubkey P2PK/P2MS (prev)txouts with 1-starting P2PKH address #19156

issue andronoob opened this issue on June 3, 2020
  1. andronoob commented at 11:37 AM on June 3, 2020: none

    Is your feature request related to a problem? Please describe.

    <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->

    Firstly it's not really an issue of Bitcoin Core only, it's about the entire bitcoin ecosystem :-)

    I don't really know the historical context. I have learned that displaying P2PK/P2MS as 1-starting P2PKH address is criticized as "non-standard" or "incorrect" etc, so that some block explorers like Blockstream.info have refused to display these bare-pubkey (previous) transaction outputs as 1-starting P2PKH addresses.

    IMHO this only creates confusion, that even the famous Satoshi genesis address cannot be clearly displayed.

    Describe the solution you'd like

    <!-- A clear and concise description of what you want to happen. -->

    I think it's really reasonable to make a compromise, to make matching P2PK/P2MS with 1-starting P2PKH address possible.

    The confusion/ambiguity between P2PKH and P2PK/P2MS has already been there. I agree that ambiguity is not good, but mentions/referrings (in the old historical posts/writtings etc) of those 1-starting addresses simply can't be eradicated :-( Therefore a compromise might be actually necessary.

    However, I agree that the distinction between P2PKH and P2PK/P2MS should always be taken good care of, by means of displaying notes (on the web-based block explorer) and extending the functions of output descriptors.

    Describe alternatives you've considered

    <!-- A clear and concise description of any alternative solutions or features you've considered. -->

    Honestly I don't know... "keep the status quo", probably? :-)

    Additional context

    <!-- Add any other context or screenshots about the feature request here. -->

    Aug.31th 2020: Note that BTC.COM has changed its behavoir (I don't know when they did this) that P2PK is no longer represented with 1-starting P2PKH address, it shows an error message instead.

    https://github.com/Blockstream/esplora/issues/14 https://btc.com/581d30e2a73a2db683ac2f15d53590bd0cd72de52555c2722d9d6a78e9fea510 https://www.blockchain.com/btc/block/0 https://btc.com/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f https://blockstream.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

  2. andronoob added the label Feature on Jun 3, 2020
  3. MarcoFalke commented at 11:59 AM on June 3, 2020: member

    Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. Keep in mind that general bitcoin discussions are best directed to the bitcoin-dev mailing list (if they are bitcoin development related) or the #bitcoin IRC channel on freenode.

  4. MarcoFalke closed this on Jun 3, 2020

  5. MarcoFalke commented at 12:01 PM on June 3, 2020: member

    As far as Bitcoin Core is affected by this, please see #16725.

  6. andronoob commented at 5:05 AM on June 4, 2020: none

    @MarcoFalke

    Actually it's not only about getrawtransaction/decoderawtransaction RPC calls (and besides, the GUI), it's also an usability issue of the output descriptor - to me it's so obvious that matching a P2PK output with P2PKH pubkey hash is totally viable, however I don't know how could the current output descriptors design cover this.


    Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.

    Obviously, Bitcoin Core itself is affected. I just meant it would be a good first step towards the appropriate handling of this problem - rather than simply ignoring or even denying it.

  7. MarcoFalke commented at 9:28 AM on June 4, 2020: member

    by means of displaying notes (on the web-based block explorer) and extending the functions of output descriptors.

    Bitcoin Core can't change what block explorers display. If you have any ideas on how to improve output descriptors, then please let us know. But the document you linked to shows that they already support raw pubkey destinations: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#examples . So I am not sure what your feature request is.

  8. andronoob commented at 10:00 AM on June 4, 2020: none

    Bitcoin Core can't change what block explorers display.

    It's true, my apologies. However, maybe Bitcoin Core could change how itself displays P2PK outputs in its GUI?


    raw pubkey destinations

    Honestly I'm not quite sure either... What I see is as follows:

    pk(KEY) (anywhere): P2PK output for the given public key.

    it seemed that only the public key, instead of the hash of the public key, could be placed in parentheses.

  9. andronoob commented at 10:11 AM on June 4, 2020: none

    I agree that ambiguity is not good. I'm also aware that P2PK is ancient thing, which is (almostly) not used any more. However, AFAIK, it has penetrated into the culture of Bitcoin community so deeply, and meanwhile it doesn't seem to be as bad as "incorrect", as a P2PK output has exactly the same ownership with the corresponding P2PKH address.

  10. DrahtBot locked this on Feb 15, 2022
Labels

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-25 00:14 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me