Hello,

BIP-BM01 says that "the keys must satisfy the condition that [formula] contains a leading zero when the public keys are expressed in uncompressed X9.62 format". I spoke about this with Jonathan Warren some time ago for other reason, and he said that this is merely a convention to make the address shorter and not a mandatory part of the protocol. I looked at PyBitmessage and while it's true that when generating new addresses it will iterate until there is a leading zero (affecting things like deterministic private addresses and chans), it looks like removing it will not break anything else. Sending messages to people whose addresses' ripemd160 do not begin with a leading zero will probably still work (admittedly, I haven't tested it). When you generate multiple deterministic addresses from the same seed in PyBitmessage, it also requires the leading zero in all, making it behave similarly than the proposal in BIP-BM01.

While I don't mind making this condition mandatory, I think that in such a case we should make an explicit agreement/proclamation that this is the case and notify devs of other implementations.

Another issue that I noticed is that for encryption key iteration, how it's implemented in Daniel's bmutil btcsuite's btcutil, it uses a numerical addition of a 4-byte integer and iterates by one. Deterministic addresses in PyBitmessage, however, iterate both the seed by initial offset 0 for signing and itial offset 1 for encryption, iterates both by 2, and uses a string concatenation of the seed and varint of the offset. So BIP-BM01 is not compatible with PyBitmessage's deterministic addresses.

The reason why I'm opening this issue is that I would like to add a first level of forward secrecy into the protocol and would like to avoid inventing new standards. How it would work is by using a time-based iteration combined with a starting time and starting key. As time goes on, the recipient will iterate the encryption private key, and the sender the encryption private key, discarding the old ones. Signing key can remain unchanged. This will allow imperfect forward secrecy, the imperfection depending on the granularity of the iterator. On protocol level, you'd need a new address version (or a pubkey bitfield, but I'd prefer a new address version), and a new pubkey object version. Maybe also message version, I'm not sure yet if that's necessary. Later, additional methods can be added.

However, it looks like neither BIP-BM01 nor the old PyBitmessage deterministic addresses will be able to provide forward secrecy, because in order to iterate, they both need the master seed, so they cannot discard it. Please correct me if I'm wrong, this is very important to get right.