diff options
| author | Dan Gould <d@ngould.dev> | 2023-05-10 15:26:38 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-10 15:33:32 +0000 |
| commit | 637298bc129602fd2a6e1e4f8dc94a0bf6580cdb (patch) | |
| tree | 27d5a53826aa4d476393679f60ae91c45d1f1ff9 /bf | |
| parent | b705e5e671801a1d05c32706e0bf7b0215673d8a (diff) | |
| download | pi-bitcoindev-637298bc129602fd2a6e1e4f8dc94a0bf6580cdb.tar.gz pi-bitcoindev-637298bc129602fd2a6e1e4f8dc94a0bf6580cdb.zip | |
[bitcoin-dev] Interactive Payment Batching w/ Payjoin
Diffstat (limited to 'bf')
| -rw-r--r-- | bf/01bb0b56d078f39becdbd03a8f3b095f07f233 | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/bf/01bb0b56d078f39becdbd03a8f3b095f07f233 b/bf/01bb0b56d078f39becdbd03a8f3b095f07f233 new file mode 100644 index 000000000..93a07ff35 --- /dev/null +++ b/bf/01bb0b56d078f39becdbd03a8f3b095f07f233 @@ -0,0 +1,338 @@ +Return-Path: <d@ngould.dev> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A8E66C002A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 15:33:32 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 8435581376 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 15:33:32 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8435581376 +Authentication-Results: smtp1.osuosl.org; + dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev + header.a=rsa-sha256 header.s=protonmail header.b=MDCR6mL6 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.102 +X-Spam-Level: +X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id erGDkov8e1Qw + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 15:33:29 +0000 (UTC) +X-Greylist: delayed 00:06:32 by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E220480C34 +Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch + [185.70.41.103]) + by smtp1.osuosl.org (Postfix) with ESMTPS id E220480C34 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 15:33:28 +0000 (UTC) +Date: Wed, 10 May 2023 15:26:38 +0000 +Authentication-Results: mail-41103.protonmail.ch; + dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev + header.b="MDCR6mL6" +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev; + s=protonmail; t=1683732404; x=1683991604; + bh=ngSfVzy3aBho9www6g9ecnUvdNb5wkWvf5tE9CaQFQ8=; + h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: + Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; + b=MDCR6mL6Krz3LRYVzidM81Nku9BnmfiGurUrAeQ3rMMH4eKDNXqmS0p4JM89C6MX0 + 2u97TorlVBUIstGVFVDNSLj4Wwd/7QIAVHpuaxHRxnZct+d1Hc9NFTXYHku1qhYqCb + quLRo0Z+2ktlVM7ELeDP9NSBZrreLqILn9sjQLBI= +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 +X-Mailman-Approved-At: Wed, 10 May 2023 15:38:39 +0000 +Subject: [bitcoin-dev] Interactive Payment Batching w/ Payjoin +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 10 May 2023 15:33:32 -0000 + +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. + + + + |