Stealth addresses versions are bothering me. I ran into a similar issue
in the handling of BIP38 altchain encodings. It was too late to prevent
that, but I would like to avoid it in stealth.

Some information on this site is dated (specifically the format of the
null-data script), but it's currently the best reference:

https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

The stealth address encoding calls for a "version" byte of 42 for
mainnet and 43 for testnet. These are of course completely arbitrary
choices, but based on my observations they shouldn't be.

The generation of the output tuple by the payer is somewhat complex.

The null-data output requires generation of an ephemeral secret that has
an even-y-valued public key, and, when double-sha256-hashed, the output
script contains the prefix specified by the stealth address. Both of
these steps require iteration over a nonced initial seed.

The spendable output requires a standard script - specifically p2pkh or
p2sh (for payments to multisig addresses). [The libbitcoin 3.0 client
and server stack will fully support multisig.]

So the portion of the process that requires generation of the spendable
output is the same as for non-stealth payments. As such it would be
ideal if this payment could be generated from a non-stealth payment
address that can be derived from the stealth payment address. This is
currently possible, but only if one hardwires a mapping as follows:

stealth address => payment address
==================================
0x2a|single     => 0x00
0x2a|multisig   => 0x05
0x2b|single     => 0x6f
0x2b|multisig   => 0xc4
...

This of course is complicated by the addition of chains in addition to
mainnet and testnet. Certainly (if it is not already the case) the
stealth address version byte will continue to be used as a chain
identifier. Note that there is also an "options" byte which serves to
identify true versioning information.

So for a general purpose application to derive the proper chain from a
stealth address, one must embed knowledge of the full set of stealth
address version bytes with the chain mapping of each. Eventually the
domain of 256 version bytes, for both stealth and payment addresses,
will be filled (and even overloaded). The mapping between them will be
arbitrary and the source of perpetual confusion, especially since they
are necessarily correlated.

Things would get quite a bit simpler if we would eliminate this
arbitrary misalignment and instead adopt the convention that the stealth
address version is required to be the same as the payment address
version. This would allow software (and people) to identify the
appropriate chain using without a secondary mapping.

So, in the interest of clarity, I would like feedback on the following
proposal:

stealth address => payment address
==================================
0x00|single     => 0x00
0x05|multisig   => 0x05
0x6f|single     => 0x6f
0xc4|multisig   => 0xc4
...

The stealth address is quite a bit longer than a payment address, so
there is no risk of confusion between the two.

Finally, the multisig prefix is unnecessary in the case of stealth
addresses, as the multisig nature of the address is determinable from
its payload. It is however not unreasonable that the prefix should
expose this differentiation.

Thoughts?

e