Skip to content

bip122/caip350 address examples are placeholders, not test vectors #196

Description

@recxodus

The address examples table in bip122/caip350.md describes the binary column in prose instead of giving bytes:

Text (Bitcoin mainnet) Binary (hex, after type byte)
P2SH 35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N 0x01 + base58btc-decoded payload (version + 20-byte hash)
SegWit bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk 0x02 + 0x00 + 20-byte witness program

eip155, solana and starknet all give concrete hex, and bip122 is the profile that most needs it: it's the only one defining a binary encoding that isn't inherited from anywhere else (the 0x01 P2SH / 0x02 witness type byte is specific to this profile), so there's nothing to check an implementation against.

The values are easy enough to fill in — these decode with valid checksums:

Text Binary (Address field)
P2SH 35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N 0x01052880c9ccd39581ea618053a558485452e8d1b80b
SegWit bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk 0x02007095fbe2af81d648fe924443f0b331247e7518bf

i.e. P2SH = type 0x01 + version 0x05 + 20-byte script hash; SegWit = type 0x02 + witness version 0x00 + 20-byte program.

Deliberately leaving out the taproot row, since #176 is already replacing that address. Using the valid one from that PR it'd be:

| Taproot bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0 | 0x020179be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 |

Happy to open a PR once #176 lands, if that ordering suits.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions