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.

3. S broadcasts HA to the Bitcoin P2P network with his public key (SPK).

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?

4. R recognizes HA and encrypts a message to SPK with an endpoint.

The same criticism: what prevents Mallory from sending messages to herself from herself, wasting the network's bandwidth?

How does this network deal with spam?

It doesn't.

Also to gather all the issues under here, there is privacy leak with exposing address hash to the public, when it is a layer 1 fallback transaction, due to the sender not being compatible with L1/2 protocol, but the receiver is.
In that case a network observer can hash all the addresses on the blockchain and pair them with the broadcasted hashes.

I updated the model with Taproot in mind. This fixes the privacy leak. The spam issue is still not addressed.

@AdamISZ's Snicker suggests 4 solutions to the spam issue: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#anti-spam-prevention

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.