Hi Alfred,
Thanks for all the effort.
Note that in the previous thread I mentioned[0] that this proposal introduces a scanning requirement in order to detect incoming notifications (complicating light client implementation). I recommend that you put this information in the BIP, as this is an important downside that readers should be aware of.
I'm also now realizing that your proposal is actually *very* similar to the BIP47 protocol improvement suggestions that were made in Prague:
As far as I can tell, the one difference is that you added an extra ECDH calculation to hide the recipient payment code. Uncoincidentally, this is also exactly what causes the downside of having a scanning requirement, and it seems the only benefit you get in return is that you don't have to outsource the notification (as is the case in the Prague protocol) and can broadcast it yourself instead. I'm personally unsure whether this is a net improvement, but that is certainly open to debate. I'd say it's worth having this discussion prior to finalizing the BIP, as otherwise it could potentially result in yet another incompatible standard further down the line.
Considering the similarity, perhaps you could consider crediting the participants of the Prague discussion (namely Alekos Filini, Martin Habovštiak, and myself). And I imagine Silent Payments[1] may have served as an inspiration as well. I also recommend taking another look at the "Allowing collisions" paragraph from the Prague discussion, as it can potentially shave off up to 28 bytes.
I hope you find this feedback reasonable and it doesn't discourage you. There's way too much work to be done on Bitcoin, so I'm happy to see you are actively putting in the effort to move things forward. Working out the details such as how to handle address formats is also very much appreciated. Keep it up.
Cheers,
Ruben