Date: Wed, 10 May 2023 15:26:38 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Dan Gould <d@ngould.dev>
Message-ID: <A8AC6028-2B20-4D0E-934B-03CC228A9CCC@ngould.dev>
Feedback-ID: 13175031:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Interactive Payment Batching w/ Payjoin
Precedence: list

Hi list, The following message details a number of examples using payjoin P=
2EP to coordinate payment batches. I stray from the original shape of steno=
graphic payjoin, what I call "canonical payjoin" with 2 inputs and many out=
puts, to describe what I believe are novel structures that break heuristics=
 used to track batched payments. The later examples match typical batch str=
ucture while breaking common input heuristic.

I'm curious to hear any feedback or concerns with these methods. This work =
is written in a less technical register than this list may be used to, but =
bitcoin-dev is the best forum to request for a critique of the thinking.

Thanks,
Dan

=E2=80=94

INTERACTIVE PAYMENT BATCHING IS BETTER

## Payjoin for More Than Privacy

A high fee bitcoin always [triggers](https://twitter.com/BTCsessions/status=
/1655733065426296832) a [search](https://twitter.com/w_s_bitcoin/status/165=
5885695762808832) for more efficient use of blockspace. Blockchain is a slo=
w database, and batching has got to be one of the oldest ways to optimize a=
 database. Lightning is interactive payment batching based on intermittent =
settlement. Payjoin is interactive settlement batching. Merchant to custome=
r payjoin is what led to the formal spec. No surprise then that a merchant =
/ customer frame stuck versus a frame payment batching like lightning. Ligh=
tning has been batching for scaling all along. The following outlines how p=
ayjoin fits into batched transfer settlement infrastructure and how it help=
s prepare for the next wave of blockspace scarcity.

The term "payjoin" is used to describe both an interactive way to build tra=
nsactions between peers on the web, aka Pay-to-Endpoint (P2EP), and an ambi=
guous transaction structure, typically with many inputs and two outputs tha=
t I dub *canonical payjoin*. Canonical payjoin looks like transaction behav=
ior that any wallet could make, but its inputs actually come from more than=
 one person. Breaking the assumption that all transaction inputs belong to =
the same person breaks the foundation of blockchain surveillance and the so=
le privacy problem left open in Satoshi's whitepaper. In an effort to impro=
ve bitcoin's privacy through payjoin adoption, I outline a number of ways p=
ayjoin can significantly reduce fee expenditure and blockchain throughput i=
n individual and enterprise circumstances. Some of these new techniques pre=
serve privacy for transactions otherwise thought of as unambiguous and cert=
ainly traceable. The examples mostly ignore mining fees for the sake of sim=
plicity.

## Before the Batch

### Paying Naively

Payjoin without the joi is just payn. ouch.

```
A's input0:    2 btc
A's input1:    3 btc
---
B's output0:   4 btc B's address0
A's output1:   1 btc A's change
```

A typical bitcoin transfer from `A`lice to `B`ob looks like this. Note that=
 only the addresses and amounts are posted to chain with no further relatio=
n between inputs and outputs. The named labels are not. Third party analyst=
s assume both inputs come from the same entity (because they usually do). T=
hey also assume `output0` is the payment because neither input is alone suf=
ficient to make a payment of 4 btc.

### Canonical Payjoin

Payjoin foils that assumption because it lets Alice and Bob both contribute=
 inputs. What would be interpreted as a naive payment might actually be a p=
ayjoin. Assuming both inputs always come from either Bob or Alice is wrong.

```pre
A's input0:      2 btc
B's input1:     3 btc
---
A's output1:   1 btc A's change
B's output0:   4 btc B's address0
```


Alice only paid 1 btc to `output0`'s 4 btc while merging it with Bob's 3 bt=
c input txo too. Bob's 4 btc is not the 1 btc amount Alice paid, which is n=
ot visible.

## Enter Output Substitution

Payjoin [payment output substitution](https://github.com/bitcoin/bips/blob/=
master/bip-0078.mediawiki#payment-output-substitution) (`pjos`) lets a rece=
iver like Bob substitute a proposed output with any outputs of equal amount=
. BIP 78 `pjos` is insecure over relayed communications and thus forbidden.=
 BIP 78 receivers must run their own authenticated server to use `pjos`. [S=
erverless Payjoin](https://gist.github.com/DanGould/243e418752fff760c9f6b23=
bba8a32f9) secures relayed `pjos`.

The following examines the use of this technique to prevent address reuse, =
redirect funds to cold storage, forward payments, and batch transactions fo=
r massive fee savings.

### The Minimum Effective Interaction

Let's make not-quite-payjoin but something still fun. Call that Payjoi. Get=
 it? Joy again? Hah =F0=9F=A5=81=F0=9F=92=A5.

If Bob's wallet is empty or he's using a cold wallet this would still work.

Imagine Bob's a bartender who posts the QR code for `bitcoin:address0?pj=3D=
https://payjoin.bob.cash` on an the wall at the bar.

Alice would scan it to propose the transaction as before, but Bob returns t=
he payjoin proposal with one tiny change. In this way he keeps his tip priv=
ate from nosy neighbors at the bar.

```pre
A's input0:    2 btc
A's input1:    3 btc
---
B's output0:   4 btc B's address1
A's output1:   1 btc A's change

```

See, Bob swapped `output0`'s `address0` for `address1`. Other patrons do no=
t know of `address1` since Bob sent it online as a payjoin proposal. They c=
an't look up what they don't know.

### Payment forwarding

Toys aside, substitution is powerful. What if Bob planned to pay his `C`lou=
d provider next time he got paid. He could substitute `C`loudy's address in=
stead of his `address1`.

```pre
A's input0:    2 btc
A's input1:    3 btc
---
C's output0:   4 btc C's address
A's output1:   1 btc A's change

```

Alice only sees `C`'s address as unique, and the payjoin proposal is authen=
ticated by Bob, so both of them agree that this payjoin pays Bob. Since tra=
nsactions are atomic, Bob takes no custody of the funds going to `C`loudy e=
ither.

Bob could also turn this into a canonical payjoin by adding input. Or inste=
ad, Bob could forward funds to his cold storage rather than to Cloudy. That=
 could be valuable if Bob's payjoin server hot wallet had more funds than h=
e was comfortable with keeping online. Alice even still pays the miner fee =
as she would in any case. Bob saves the blockspace, time, money and hassle =
of a making separate transaction to forward.

### Receiver side Payment Batching

We're going to make this more complex, because it scales bitcoin and it's f=
un.

Imagine Bob is an exchange sitting on a few low-priority withdrawal orders =
from `D`an of 0.6 btc and and `E`rin of 0.4 btc. When Alice proposes a depo=
sit, Bob may substitute a single output with many, spreading the inbound am=
ount across multiple addresses. Instead of just *address* substitution he s=
ubstitutes the entire output with new ones.

```
A's input0:    2 btc
A's input1:    3 btc
---
B's output0:   0.99 btc B's address0
A's output1:   3 btc A's change
D's output2:   0.4 btc D's address
E's output3:   0.6 btc E's address

```

Batching saves mining fees for Bob since Alice already pays for some transa=
ction fee. Bob can take any remaining mining fee costs from his increased t=
ransaction's size out of his own output, `address0` shown here receiving 0.=
99 btc to pay an additional 0.01 btc fee. Not shown, Bob could even split C=
loudy's output from the prior example to forward Cloudy an exact invoice am=
ount and keep the change.

[Prior](https://www.bullbitcoin.com/blog/announcing-batcher-by-bull-bitcoin=
-open-source-non-custodial-on-chain-wallet-batching-plugin-for-high-volume-=
bitcoin-enterprise-users) [art](https://blog.bitgo.com/utxo-management-for-=
enterprise-wallets-5357dad08dd1) [all](https://medium.com/@hasufly/an-analy=
sis-of-batching-in-bitcoin-9bdf81a394e0) [explores](https://bitcoinops.org/=
en/payment-batching/) sender-batched transactions. It follows that inputs t=
o batched transactions are assumed to belong to the cluster of the entity m=
aking payments (Bob, in this case). Receiver side payment batching kills th=
is heuristic analysis, providing multiple new interpretations for payments =
of few inputs and many outputs.

### Lightning Channels

Yes, even [lightning channel payjoin](https://chaincase.app/words/lightning=
-payjoin) outputs are viable. Lightning channels are posted as 2-of-2 P2SH =
or P2TR addresses.

```
A's input0:    5 btc
---
B's output0:   2 btc B & his peer's =E2=9A=A1=EF=B8=8F channel
A's output1:   3 btc A's change

```

Bob's lightning output helps preserve privacy even moreso because it belong=
s to two parties, both Bob and his channel peer. When P2TR channels are the=
 norm, a stranger would not even know that `output0` is for lightning. New =
standard lightning protocols allow for payjoin output splicing and dual fun=
ded channels to achieve the common input assumption-busting result even wit=
hout BIP 78 as well.

### Mix and Batch =F0=9F=A5=A3

Combining it all forces multiple ambiguous interpretations of the transacti=
on graph. With basic networking, and no coordinator, Both Alice and Bob can=
 pay multiple parties beyond themselves, combine inputs and consolidate fun=
ds without fear for being censored.

Interaction lets multiple ambiguous possibilities converge to preserve bitc=
oin's inherent fungibility. No inconvenient, fee intensive, pre-scheduled, =
time consuming mixing step required.

#### Batch Sender and Receiver Transactions to Put a Cherry on Top =
=F0=9F=8D=B0

```
A's input0:    2 btc
B's input1:    4 btc
B's input2:    3 btc
---
B's output0:   1.5 btc B's address1
A's output1:   2 btc A's change
B's output2:   0.4 btc B's =E2=9A=A1=EF=B8=8F channel
C's output3:   2.5 btc C's address
E's output4:   1 btc E's address
D's output5:   0.6 btc D's address
F's output6:   1 btc F's address

```

Even though amounts aren't equal, these new payjoin constructions provide s=
ignificant ambiguity to foil vast swaths of heuristic analysis being done t=
oday by breaking their most basic assumptions. Because of payjoin's intra-t=
ransaction transfers from Alice to Bob, [CoinJoin sudoku](http://www.coinjo=
insudoku.com/advisory/) analysis does not apply.

Even Alice and Bob preserve some privacy in the other's view. Even though o=
ne knows the other's inputs, they cannot be certain that any of their count=
erpart's outputs will end up in their counterpart's wallet or if output sub=
stitution has been used.

## Progress before rainbows =F0=9F=8C=88 and unicorns =F0=9F=A6=84

Bob and Alice still know the subtransactions of their counterpart. As of to=
day, Bob still needs to run a server. They each know which inputs belong to=
 which counterpart. While p2p can do a lot, an adversarial counterparty cou=
ld still report the other's chosen inputs and outputs to build a cluster wi=
th an analysis firm. I know those problems need to be solved, but look how =
far ahead a simple HTTP interaction can take us.

**Thanks** to Hunter Beast, Andrew "Kukks" Camilleri, Ishi, Kexkey, Francis=
 Pouliot, and Yashraj for reading drafts of this.