Suggestion: defining a standard prefix and type to use for private keys?

[avl42]

Maybe base32 could also be used for export and import of private keys. It can deal with 256 bit data, so why not also use it for that?

[deadalnix]

I think it is a great idea.

[schancel]

I was talking to another person last night about this. We should probably add another version type for privkeys.

[avl42]

I'd definitely vote for both a new prefix and a new type, to prevent any accidental use of a privkey as a payment target - visibly (by prefix) or technically (even if prefix is stripped).

"bchprivkey" and type=8 , thus the versionbyte would be '43' (bits regrouped by fields: 0 1000 011)

Of course the old base58 formats "5..." and "K..." ought to be still supported as well.

[schancel]

Can you do a pull request for this?

[avl42]

I can, I will, but not yet sure when I'll get to it. One more detail that I forgot to mention before is the aspect of "compressed" versus "uncompressed" keys. Not sure, if the distinction is still a thing nowadays, or if import of a priv-key adds both addresses to the wallet anyway... I'd appreciate some feedback on that point before I start.

[DesWurstes]

Summary:

Uncompressed address: Ripemd160(Sha256(0x04 + X coordinate + Y coordinate))

Compressed address, y is odd: Ripemd160(Sha256(0x03 + X coordinate))

Compressed address, y is even: Ripemd160(Sha256(0x02 + X coordinate))

+ being the array merge operator.

Structure of WIF:

1 Byte Private key version byte + 32 bytes private key (if smaller than 32, fill zeros to the left and then put the privkey)

Structure of WIF for compressed addresses:

1 Byte Private key version byte + 32 bytes private key (if smaller than 32, fill zeros to the left and then put the privkey) + 1 byte of 0x01.

[avl42]

well, i am aware of that... In base58 world, there were two variants of walletformat for *private* keys. That allowed to specify whether that key would be used for a wasteful pubkey 04+X+Y or for the more compact 02/03+X, leading to different addresses. I could define two separate types to reflect the old system, or I could define just one and declare it as compressed key (let the uncompressed ones die die die)... opinions on that? Am 02.02.2018 18:01 schrieb "DesWurstes" <notifications@github.com>:

…

https://bitcoin.stackexchange.com/questions/69315/how-are- compressed-pubkeys-generated Summary: Uncompressed address: Ripemd160(Sha256(0x04 + X coordinate + Y coordinate)) Compressed address, y is odd: Ripemd160(Sha256(0x03 + X coordinate + Y coordinate)) Compressed address, y is odd: Ripemd160(Sha256(0x02 + X coordinate + Y coordinate)) + being the array merge operator. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAwsv0Er51lq2H4EwLQyQ4Q23AWnUowks5tQz1_gaJpZM4Rgoov> .

[Steve132]

One concern here is that while CashAddr allows arbitrarily large keys, the "address space" so to speak of how many "address types" there can be is limited by the current spec to only 16 (4 bits) of space from the version byte. 2 of those (0b0000 and 0b0001) are used for p2pkh and p2sh script addresses, respectively.

If private keys were encoded with CashAddr, then the spec could either reuse 0b0000 and 0b0001 respectively (for compressed and uncompressed), or it could pick new type bits.

If the spec reused 0b0000 and 0b0001, then validating a given address becomes somewhat difficult: If the user omitted the optional prefix, then telling the difference between a private key and a long address requires validating against both prefixes. Without doing that, you wouldn't be able to tell if a given parse failed because it was a private key or if it failed because of a checksum error, which could be bad for user experience. Also, addresses would look visually similar to addresses, which could also be bad for user experience.

If the spec chose new type bits (say 0b00100, then that's using up 7% (or 14% if we include compressed and uncompressed as separate types) of the available number of total types CashAddr can support.

Both options seem to have some significant downsides in some way or another. The first uses less type space but is more complicated for wallets to implement and can provide bad user experience from addresses looking similar. The second seems to be better but uses up a LOT of an already limited resource (CashAddr 'type' space).

My preferred solution would be this: Implement the second solution by allocating new type id 2 to compressed private keys. HOWEVER in the same update change the cashaddr spec to use the reserved first bit as a flag to extend the address space for the version byte..

This can be done in a backwards compatible way by modifying the cashaddr spec to specify that the version byte becomes a version varint. The bottom 3 bits of the version varint are still the size, but now the entire thing is parsed using the varint algorithm used in the rest of bitcoin instead of just reading a single byte.

If the version value (type and size) is any bitpattern currently supported by CashAddr, (0-127) then for types 0-15 and sizes 0-7 it will still have the same representation as it currently does.

However, with this change, using code already likely to be present in any wallet implementation, its possible to read up to 2**61 possible 'types' that will be allowed in CashAddr.

Wallets won't have pressure to implement this change to the spec until type 15 is defined, but it would give us future proofing for other address/data types to be supported when that happens. (which could be sooner than expected if type 2 and 3 are allocated for this purpose).

Even if it's decided to solve this issue by using another prefix and reusing 0-1, this future proofing would help a lot in case BCH actually wants to support a plurality of more complex address types in the future.

[avl42]

I don't really foresee anything like a "continuing trend" towards using type values. (imho, future would more likely get to grow a need for further size-values instead.)

So, my suggestion stays "use one new type value" - eat up a portion of 7% of the type space - and only if rate of type-allocating suggestions increases... 'then' start touching the MSB of the version byte.

It's not like we'd need to prepare that beforehand. We could still do that when the last currently available type value has been put to use and another proposal comes up.

[Steve132]

I don't really foresee anything like a "continuing trend" towards using type values. (imho, future would more likely get to grow a need for further size-values instead.)

Lots of interesting new blockchain uses, including various kinds of opcodes, could eventually supercede the bounds of p2sh, especially if people start signaling what kind of script or contract the address represents, or use CashAddr to represent other primitives (like is being discussed here).

In contrast, BCH is pretty much hard-coded to use 128-bit strong security everywhere, for which the current size support for 512 bits of hash is more than enough, even against birthday attacks. So I see it the opposite way, basically: More types is more likely than larger hash sizes.

It's not like we'd need to prepare that beforehand. We could still do that when the last currently available type value has been put to use and another proposal comes up.

You want to make those kinds of revisions as early and as generically as possible. As adoption of CashAddr grows, upgrades to all of those implementations in the ecosystem becomes exponentially harder over time. It's far better to make the change as soon as possible in the spec and the reference implementations so that we can get ahead of it before the ecosystem grows and copy-pasted implementations spread all over. If we wait to define the change until as late as possible, then there will be more wallets and services who need to implement the change in a very short time than there are if we implement the change now.

It's very easy for a service to have code that says "Parse the extended type bits. If the type bits aren't what is expected here as a valid address, then report that to the user or handle it some how" if the extension spec is well defined, then that code will continue to work with new extended addresses whenever new types are added. If the code doesn't need to validate for a particular type (suppose it's an address book of valid cashaddr formats or a BCH block explorer), then even when new types are introduced that code will continue to work.

In contrast, if we wait on the extension spec, then when a user in the future enters an extended address into one of those services that didn't implement the extension, the address will fail to parse completely because of an invalid payload. Well programmed services will point out to the user that the MSB is invalidly set with no other information regarding address type, (even ones that are otherwise agnostic to type), and careless implementations will inaccurately report a checksum error in the payload.

My point is that it's important for future user experience and maintenance throughout the ecosystem that, if we're going to extend it ever, that we extend it sooner, and preferably in a backwards-compatible way.

I have a proposal over here bitcoincashorg/bitcoincash.org#19 to do that.

[avl42]

• Unlike e.g. block-sizes, any extra need of types is something that emerges from new features and/or opcodes added. It's a self-made need, and as we create the need we can then also add the remedy.

• What you achieve with the "extension spec", namely safe detection of later extensions, is exactly what the "MSB is 0" is already for. If we ever run out of type codes, we can then decide on the new spec (and add another new marker to that new spec, for even later extendability). If we're too eager with conquering the MSB=1 space now, it might turn out that future uses (beyond the one-dimensional type-range) will be confined to really awkward version-prefixes.

PS: I think your proposal is fine in the case that we really end up needing gobs of type values. It's just pre-mature for the actual need. It's easily possible that future extension needs will develop into a completely different direction than just adding more type values.