[bitcoin-dev] Payjoin2swap: Enabling Payjoin Without Merchant Purchases
ZmnSCPxj at protonmail.com
Mon Apr 22 17:06:43 UTC 2019
Good morning list,
I observe that if the Lightning Network supports:
1. Wumbo channels (>167.772215mBTC channels)
2. Dual-funded channels
Then payjoin2swap is implementable using LN operations.
Given two UTXOs V and W you want to transfer some value S from V to W.
1. Connect to an LN node on Tor and listen to gossip, then disconnect.
2. Create two fake node addresses (A and B) and assign a unique Tor hidden service to each.
3. Select two actual LN nodes with long uptime (use the lifetime of the channels they have as a rough estimate) and a short distance between them with good capacity and many alternate routes between them.
4. Connect A to one node and create a channel using V.
Indicate that the channel should be unpublished (the LN protocol has a flag existing for this already).
Publishing channels is good for privacy if you intend to stay long on LN (it invites "normal" traffic to hide your own payments in), but we do not intend to stay long on LN here, so keep the channels unpublished.
5. Connect B to the other node and create a channel with dual-funding, requesting at least S from the other node to put in the channel, using W as your own UTXO.
Again indicate the channel should be unpublished.
6. Transfer S satoshi over LN from the channel of A to the channel of B.
7. Cooperatively close both channels.
It is possible to time the closes to be some blocks apart to make them harder for blockchain analysis to link.
This rides payjoin2swap on top of existing infrastructure.
The drawback is that it is unlikely that existing LN implementations will apply ZeroLink for onchain funds, since much of the privacy on LN is with paying over the long-lived offchain channels.
This can erode privacy if either of the nodes you connect to uses the result of the cooperative closes to later fund a published channel, possibly mixing it with other coins of their own.
More information about the bitcoin-dev