Significance of random byte at the end of encoded public key hash

[loon3]

To create the 33 byte public key hash you mention that you split the encoded transaction data into 31 byte pieces then add 02 or 03 to the front and a random byte to the end that satisfies the checksum. In all the tests I've run, it seems the public key hash can be converted to a bitcoin address using the byte 00.

Do you know if there's a reason why this byte is chosen randomly? Is it to further obfuscate the XCP data or can I just use 00 if it can be converted to a valid bitcoin address?

[deweller]

Here is the relevant source code in the python code base:
https://github.com/CounterpartyXCP/counterpartyd/blob/5f001aeee2efb7c64a024a8a5e8f7861be1a8348/counterpartylib/lib/script.py#L125-L128

I believe the public key has a checksum built into it. And to satisfy this checksum, it tries every combination.

I haven't researched this fully. What was your method of converting the public key into a bitcoin address?

[loon3]

I'm generating all 256 1-byte possibilities then validating them with Bitcore. Every sample I've tried results in 00 generating a valid public key hash, which is fine I guess, just curious if there is any reasoning why it should be random.

function hex_byte() {

    var hex_digits = "0123456789abcdef";
    var hex_dig_array = hex_digits.split('');

    var hex_byte_array = new Array();

    for (a = 0; a < 16; a++){
        for (b = 0; b < 16; b++){            
            hex_byte_array.push(hex_dig_array[a] + hex_dig_array[b]);           
        }
    }

    return hex_byte_array;

}

function addresses_from_datachunk(datachunk) {

    var hex_byte_array = hex_byte();

    var pubkey_seg1 = datachunk.substring(0, 62);
    var pubkey_seg2 = datachunk.substring(62, 124);
    var first_byte = "02";
    var second_byte;
    var pubkeyhash;

    seg1_loop:
    for (j = 0; j < 2; j++) {

        if (j > 0) {first_byte = "03";}

        for (i = 0; i < 256; i++) {

            second_byte = hex_byte_array[i];

            pubkeyhash = first_byte + pubkey_seg1 + second_byte;

            if (bitcore.PublicKey.isValid(pubkeyhash)){
                console.log(pubkeyhash);
                var address1 = address_from_pubkeyhash(pubkeyhash);
                break seg1_loop;
            }           

        }    

    }

    seg2_loop:
    for (j = 0; j < 2; j++) {

        if (j > 0) {first_byte = "03";}

        for (i = 0; i < 256; i++) {

            second_byte = hex_byte_array[i];

            pubkeyhash = first_byte + pubkey_seg2 + second_byte;

            if (bitcore.PublicKey.isValid(pubkeyhash)){
                console.log(pubkeyhash);
                var address2 = address_from_pubkeyhash(pubkeyhash);
                break seg2_loop;
            }           

        }    

    }

    console.log(address1);
    console.log(address2);

    var data_addresses = [address1, address2];

    return data_addresses;

}

[adamkrellenstein]

There's no checksum in the public key. Rather, not all public keys are on the correct ECDSA curve. It's better to use such 'fully valid' public keys so that they are indistinguishable from others. We just try random nonces until the key is random, because that's simple, reliable and more than fast enough.

[deweller]

Ah. I learned a little cryptography. Here is what I learned:

Bitcoin uses a specific ECDSA curve, specifically a curve designated secp256k1 (https://en.bitcoin.it/wiki/Secp256k1).

While almost any ECSDA public key is valid, only some of them will fall on this specific curve.

So, @loon3, it looks like the bitcore bitcore.PublicKey.isValid method does not actually fully validate the specific curve like python-bitcoinlib does.

[loon3]

Per the documentation, Bitcore is doing just that...

"A public key point should be on the secp256k1 curve, instantiating a new PublicKey will validate this and will throw an error if it’s invalid."

http://bitcore.io/guide/publickey.html

[deweller]

It is entirely possible that bitcore is not doing what it claims to do.

Did you try validating any public keys starting with a 0x02 or 0x03?

[loon3]

It doesn't seem to matter. I changed the function so it selects the last byte randomly and in all the tests I've run it never needs to try more than once to get a valid address.

I've been pushing btc raw tx's created this way using https://github.com/loon3/LTB-Companion-Wallet/blob/master/Chrome%20Extension/test/asset_send.html and it appears to be working fine without any issues related to the validity of the data encoded addresses.

[unsystemizer]

Does 0x00 still work fine?
It seems the signatures are strictly checked (see Bitcoin issue 5939) which is why old multisig dust can't be redeemed.