Motivation. By building out P2P encrypted communication between the sender and the receiver of a payment without changing the existing base layer user workflow, the learning curve of Lightning Network, PayJoin, merge avoidance and some other schemes would be radically reduced, because the user experience would be unified, the robots would handle the heavy lifting.
Background A taproot script exposes the public key, which is essential for this scheme.
Expected Existing Workflow. Receiver gives Sender a taproot Bitcoin address, which has a corresponding public key. Sender sends bitcoins to the address.
Problem. How can we build up P2P encrypted communication between receiver and sender without disrupting the existing workflow?
Solution.
The receiver starts listening to messages on the Bitcoin P2P network.
Sender instead of creating a transaction, creates an encrypted message to Receiver's public key and broadcasts it to the Bitcoin P2P network.
The message contains an endpoint, which can be can be anything that both the S and the R are compatible with, IP address, onion address, domain, etc...
If the receiver isn't compatible with L1/2 or isn't online when the message was broadcasted to him, after some reasonable timeout the sender falls back to normal send.
If a P2P connection is established, the parties can negotiate the transaction.
Issues.
This system does not deal with spam.
The SNICKER proposal has the same kind of spam issue and suggested 4 possible solutions for it.
How does this network deal with spam? E.g., what prevents Mallory from just generating an unlimited number of random strings the same length as the hashes and public keys, and then sending them to one node supporting this protocol and letting it waste its bandwidth and every other node's bandwidth by relaying those junk messages across the network?
The same criticism: what prevents Mallory from sending messages to herself from herself, wasting the network's bandwidth?