Future-proof address format by adding reserved bytes

[bitcartel]

via https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-November/000513.html

Please consider reserving a few extra bytes, as part of either the

• address type
• or the payload.

This would help future-proof the address format for new features which wallets can choose to implement.

How these bytes are used can be specified by the community at a later date.

One example is address flags.

As implemented in the CoinSpark colored coin protocol, address flags [1] help sending wallets know what features the recipient's wallet supports.

For example, if the sender is transferring OP_RETURN based assets, the sending wallet can verify that the recipient's address supports assets, to avoid a non-supporting wallet from accidentally sending on those assets.

Another example is a feature like out-of-band messaging, where not all wallets support messaging, so the sending wallet would only enable the message UI field if the recipient address indicated it supported messages.

[1] https://coinspark.org/developers/coinspark-addresses/

[schancel]

This can be implemented effectively on the cashaddr spec. There's no need to reserve additional bytes that I can see. Feel free to reopen if I am confused.