L1/2

L12.md

Layer 1/2 (L1/2)

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.

Why do you even need a p2p network? From my reading of the OP I'm not sure what problem is solved by a p2p network and the whole system of peer discovery/peer gossiping.

Why can't payjoin instead be implemented by using client-server model, so users pay merchants by paying to to a object that looks like bip21 bitcoin:BITCOIN-ADDRESS?endpoint=payments.merchantdomain.com.

If the user's wallet supports payjoin then it makes a tcp connection to the merchant's server at payments.merchantdomain.com and use that connection to exchange the partial transactions which eventually create a payjoin transaction.

payments.merchantdomain.com in the above example can be a tor hidden service. Merchants already have to run long-lived servers for hosting something like btcpay. There's no spam problem from what I can see, and if there was it's dealt with in the same way spam is dealt with on btcpay.

P2P network is not necessary, but it is desirable to avoid a central point of failure.

Usage of Bitcoin URLs and QR codes are well adopted, but building on those user workflows only covers a subset of Bitcoin users.
You may notice that this argument applies to adoption of scripts those expose public keys, but with Taproot coming along it is not inconceivable that such scripts will replace other scripts eventually.