Dan Gould [ARCHIVE] / is on Nostr

Last Notes

2023-08-16 00:45:53

- reply

📅 Original date posted:2023-08-13
🗒️ Summary of this message: The BIP has been updated to use a DH cryptosystem, ensuring that leaked BIP 21 URIs do not pose a risk of funds loss.
📝 Original message:
Thanks for weighing in Dave,
> On Aug 13, 2023, at 8:00 AM, bitcoin-dev-request at lists.linuxfoundation.org wrote:
>
>
> The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, posting them where evesdroppers can see
>
> …
>
> I don't think it would be practical to change that expectation, and I think a protocol where evesdropping didn't create a risk of funds loss would be much better than one where that risk was created.
>
> dave at dtrt.org
The BIP has changed to adopt a DH cryptosystem where the receiver only shares a public key in the BIP 21 as part of the pj= endpoint since Adam posted comments. I agree enabling the simplest asynchronous experience while, as I gather you’re thinking, keeping the UX expectation that leaked BIP 21 URIs pose no risk for loss of funds is the right set of tradeoffs.
Dan

2023-08-13 14:32:58

- reply

📅 Original date posted:2023-08-12
🗒️ Summary of this message: Blockchain Commons UR is suggested as the best choice for encoding pub keys in the `pj=` endpoint, and a v2 upgrade is needed for JavaScript ur library support.
📝 Original message:
Blockchain Commons UR seems to be the most elegant choice since QRs are commonplace. This suggestion, along with Adam’s to reconsider DH over symmetric crypto would let us encode a pub key directly in the `pj=` endpoint rather than with a separate am somewhat concerned that some payjoin implementations are written in JavaScript and would benefit most from a v2 upgrade in order to support receiving, but no JavaScript ur library exists yet. Perhaps one could be bound from the rust implementation.
I have updated the draft to include these suggestions and posted it to the bips repo: https://github.com/bitcoin/bips/pull/1483
The biggest change is that symmetric crypto is replaced with a Noise IK-based cryptosystem using Secp256k1/Sha256/ChaChaPoly1305 to address the problems waxwing helped uncover.
I hope also to hear more input on the transport protocol. I know many developers are interested in Nostr for its censorship resistant properties and would like to see that discussion play out within the BIP process to reach rough consensus before deployment. This hope is a key reason I’ve written here first instead of developing and deploying a complete reference implementation.
Thanks list,
Dan
> On Aug 11, 2023, at 9:05 PM, Christopher Allen <ChristopherA at lifewithalacrity.com> wrote:
>
>
>
> On Fri, Aug 11, 2023 at 3:29 PM symphonicbtc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Quick little nit I noticed as well, are you sure base64 encoding is the best choice for the psk in the URI? You may find that having to urlencode the special characters in base64 it impacts readability and adds a layer of complexity if a human wanted to extract the psk from the URI for some reason. I suggest using something like [base64url](https://datatracker.ietf.org/doc/html/rfc4648#section-5) which modifies base64 slightly to be more suited to this purpose.
>
> Yes, the URI version of base64 is better.
> However, If you plan to display these via QRs, either will double the density of the QR as QR libraries treat them as binary data (like hex of hex data). Thus you may want to use UR encoding, which is what over a dozen bitcoin wallets use to encode PSBTs. URs are very efficient with QRs, and have the optional benefit that if the data carried becomes too large, they can be animated. The have other advantages.
>
> * A top level link about URs:
> https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/README.md#uniform-resources-urs
>
> * About the base64 encoding with QRs problem:
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md
>
> * The base UR tech spec:
> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md
>
> * List of bitcoin wallets using UR for PSBTs:
> https://github.com/blockchaincommons/gordian-developer-community#urs
>
> * List of UR libraries:
> https://github.com/BlockchainCommons/crypto-commons#bc-ur
>
> Let me know if you’re interested.
>
> — Christopher Allen

2023-08-12 09:56:45

- reply

📅 Original date posted:2023-08-11
🗒️ Summary of this message: The sender pointed out a flaw in the protocol regarding the security of the Payjoin PSBT. The issue has been fixed in the draft. The sender also suggested using DH for securely sharing the secret key, but the author chose to use a symmetric key for convenience. The author proposed a solution to mitigate the attack by using ephemeral keys.
📝 Original message:
Hi waxwing
thanks for the detailed response. You've identified a number of flaws both in the protocol and the document that can be fixed. I sincerely appreciate it. If more comes to mind, fire away.
> I wanted to immediately "nit" a point I saw as I was reading:
>
>> Because BIP 78 messages are neither authenticated nor encrypted a malicious unsecured payjoin server is able to modify the Payjoin PSBT in flight,
>
> Taken as is - i.e. out of context! - this is just wrong. The BIP explicitly states:
>
> "The sender must ensure that the url refers to a scheme or protocol using authenticated encryption, for example TLS with certificate validation, or a .onion link to a hidden service whose public key identifier has already been communicated via a TLS connection. Senders SHOULD NOT accept a url representing an unencrypted or unauthenticated connection. "
Nice Catch. I've fixed it in the draft.
> Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key.
> You're sending the symmetric secret key out of band; but isn't this obscuring the question of securely sharing the secret key? Did you consider DH-ing this as other protocols do? At the very least I would claim that it's likely that implementers might be sloppy here; at the most I would claim this is just insecure full stop.
At first I thought this would be secure because the relay itself would need to discover the key only to uncover privacy, but because of output substitution it would actually open the protocol to a loss of funds attack: If the ask-containing bip21 were discovered by the relay, then the relay would have enough information to both find the buffer and forge a Payjoin PSBT paying itself rather than the receiver, and the sender would send it because output substitution is allowed. Even though I handle bip21s and addresses as secret, I know many people post them in unencrypted channels and so they should not be assumed secure to pass secrets.
I have certainly considered the security trade offs of using a symmetric key vs DH. The main reason I chose to use the symmetric psk over DH is because I thought DH would require another round of communication to establish receiver authentication, which is a huge inconvenience in an asynchronous setting. The attack I’ve described can be mitigated inside the same message pattern by having receiver share a public key of a per-request keypair Instead, approximately following the NKpsk0 pattern, the sender may pass an ephemeral secret session key under which the Payjoin PSBT response would be encrypted and authenticated so no malicious adversary with knowledge of the bip21 would be unable to read or forge. Stowaway uses BIP 47 codes for this purpose, but I see no reason to tie buffer identity to the underlying wallet. Using ephemeral keys also allows a single receiver to enroll multiple buffers at a relay simultaneously.
> About attack vectors:
>
> Since relays store arbitrary encrypted payloads to the tragedy of the commons and denial of service attacks. Relay operators may impose an authentication requirement before they provide relay service to receivers to mitigate such attacks.
>
> Isn't the most obvious concern with this architecture, that the relays have metadata - most obviously, they can time correlate messages, with bitcoin network events, so at the least they could tie transactions to clients. *If* both parties use anonymised network connections then this is ameliorated (though not removed) as a vector, but then we'd need to be clear that we *require* those (e.g. Tor). Not sure if it's palatable to do this if otherwise, i.e. if we think the relays can tie network addresses to transactions? Well, not sure, but I'd expect it to be mentioned?
The most obvious concern with this architecture is indeed that the relays would have metadata that could be used for timing attacks correlating to a Payjoin PSBT buffer being cleared from the relay and a potential payjoin transaction being broadcast. If a sufficient number of steganographic transactions are broadcast per quantum, then requiring a sender to broadcast only after a random delay based on a poisson distribution could mitigate this problem somewhat. According to S. Ghesmati 2020 research, between 27% and 42% of all transactions conform to the type of unnecessary input heuristic that payjoins conform to (UIH2). So it wouldn’t take long for multiple steganographic candidates to enter the Mempool at any given time.
I'm extremely reluctant to require Tor because it severely limits the number of environments where this proposal could be deployed. If we were to require Tor, we should then just ignore this proposal and focus on deploying hidden service based v1 receivers as in JoinMarket. I'm more inclined to require Oblivious HTTP but even that seems overkill when the threat would be for the relay to correlate steganographic transactions, which don't have a single clear sender/receiver interpretation, to two ip addresses.
> It just occurred to me that while timing correlation itself might not be much (in usual circumstances, there are tons of other transactions), it's, as usual with metadata, the intersection of more than one thing that could hurt: I know when the tx happens (say within a time window of 10 seconds), but also I might know the *size* of the message. Perhaps consider random padding of the Payjoin PSBT message size (iirc chacha is a stream cipher so lengths are arbitrary).
The biggest intersection attack is timing correlation of two linked potential payjoin transactions related to one IP address. Again, a specified delay may help mitigate this concern.
I agree that padding ought to be a requirement. 4M block size limit with base64 encoding overhead seems like a resonable buffer size, but PSBTs have significant overhead compared to consensus transactions, so the exact size of a buffer needs more attention.
Thanks for the feedback,
Dan
> On Aug 10, 2023, at 12:21 PM, <bitcoin-dev-request at lists.linuxfoundation.org> <bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: BIP for Serverless Payjoin (AdamISZ)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Aug 2023 15:46:18 +0000
> From: AdamISZ <AdamISZ at protonmail.com>
> To: Dan Gould <d at ngould.dev>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin
> Message-ID:
> <qLcrxFA7z6NkweC9HhZS7g9dcchQfVpjClR-nrMvjYmBobfYzbRrF37QztsuAVdM6HSZJ8UHl27QKYAWq0zYQMmYnBmg0YE-7HO9S6A1Rxs=@protonmail.com>
>
> Content-Type: text/plain; charset=utf-8
>
> Sorry for yet another message but:
>
> It just occurred to me that while timing correlation itself might not be much (in usual circumstances, there are tons of other transactions), it's, as usual with metadata, the intersection of more than one thing that could hurt: I know when the tx happens (say within a time window of 10 seconds), but also I might know the *size* of the message. Perhaps consider random padding of the Payjoin PSBT message size (iirc chacha is a stream cipher so lengths are arbitrary).
>
> Cheers,
> AdamISZ/waxwing
>
>> Isn't the most obvious concern with this architecture, that the relays have metadata - most obviously, they can time correlate messages, with bitcoin network events, so at the least they could tie transactions to clients. If both parties use anonymised network connections then this is ameliorated (though not removed) as a vector, but then we'd need to be clear that we require those (e.g. Tor). Not sure if it's palatable to do this if otherwise, i.e. if we think the relays can tie network addresses to transactions? Well, not sure, but I'd expect it to be mentioned?
>>
>> Cheers,
>> AdamISZ/waxwing
>>
>>
>> Sent with Proton Mail secure email.
>>
>>
>> ------- Original Message -------
>> On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>>
>>
>>
>>> Hi all,
>>>
>>> The Serverless Payjoin idea has come a long way toward formal specification of a Payjoin version 2. In the spirit of BIP 2, I?m sharing an intermediate draft of the BIP here before opening a draft on GitHub for the BIP editors, and before this exact specification has a complete reference implementation. The draft does reference two proof of concept payjoin implementations, one demonstrating use of symmetric cryptography, and the other asynchronous messaging and backwards compatibility.
>>>
>>> I?ve updated the Serverless Payjoin gist to reflect this draft specification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9 in order to preserve the edit history before opening a bips PR.
>>>
>>> The specifics have changed significantly compared to the first mailing list post to reflect feedback. Looking forward to hear your thoughts.
>>>
>>> Dan
>>>
>>> <pre>
>>>
>>> BIP: ???
>>> Layer: Applications
>>> Title: Payjoin Version 2: Serverless Payjoin
>>> Author: Dan Gould d at ngould.dev
>>>
>>> Status: Draft
>>> Replaces: 78
>>> Type: Standards Track
>>> Created: 2023-08-08
>>> License: BSD-2-Clause
>>> </pre>
>>>
>>> ==Abstract==
>>>
>>> This document proposes a backwards-compatible second version of the payjoin protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete payjoin receiver functionality including payment output substitution without requiring them to host a secure public endpoint. This requirement is replaced with an untrusted third-party relay and streaming clients which communicate using an asynchronous protocol and authenticated encrypted payloads.
>>>
>>> ==Copyright==
>>>
>>> This BIP is licensed under the 2-clause BSD license.
>>>
>>> ==Motivation==
>>>
>>> Payjoin solves the sole privacy problem left open in the bitcoin paper, that transactions with multiple inputs "necessarily reveal that their inputs were owned by the same owner." Breaking that common-input ownership assumption and others requires input from multiple owners. Cooperative transaction construction also increases transaction throughput by providing new opportunity for payment batching and transaction cut-through.
>>>
>>> Version 1 coordinates payjoins over a public server endpoint secured by either TLS or Tor onion hidden service hosted by the receiver. Version 1 is synchronous, so both sender and reciever must be online simultaneously to payjoin. Both requirements present significant barriers for all but sophisticated server operators or those wallets with complex Tor integration. These barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018358.html|regarded]] as limits to payjoin adoption.
>>>
>>> The primary goal of this proposal is to provide a practical coordination mechanism to be adopted in a vast majority of wallet environments. This is realized as a simple protocol built on bitcoin URI requests, web standards, common crypto, and minimal dependencies.
>>>
>>> ===Relation to BIP 78 (Payjoin version 1)===
>>>
>>> The message payloads in this version parrallel those used in BIP 78 while being encapsulated in authenticated encryption, forgoing HTTP messaging for WebTransport streaming of asynchronus interactions, and leveraging PSBT version 2.
>>>
>>> The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server|]] to operate separately from the so-called "payment server" responsible for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] request URIs. Because BIP 78 messages are neither authenticated nor encrypted a malicious unsecured payjoin server is able to modify the Payjoin PSBT in flight, thus requiring [[payment output substitition]] to be disabled. Output substitition is useful for a number of block space optimizations, including payment batching and transaction cut-through. This proposal introduces authentication and encryption to secure output substition while using a relay without compromising sender or receiver privacy.
>>>
>>> Although unsecured payjoin server separation is mentioned in BIP 78, no known specification or implementation of one exists. This document specifies one to be backwards compatible with version 1 senders. Receivers responding to version 1 senders must disable output substitution their payloads are plaintext so they may payjoin without the risk of the relay stealing funds.
>>>
>>> The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fallback PSBT timeout parameter is introduced which may also help coordinate the synchronous version 1 protocol.
>>>
>>> ===Relation to Stowaway===
>>>
>>> [[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends on Tor, a third-party relay, and the [[https://samouraiwallet.com/paynym|PayNym]] [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP 47]] Payment codes directory for subdirectory identification and encryption. The payjoin version 2 protocol uses one-time symmetric keys for relay subdirectory identification, authentication, and encryption instead of BIP 47 public keys derived from the wallet. Payjoin version 2 also supports asynchronous messaging, in contrast to online Stowaway's synchronous HTTP-based messaging. Offline stowaway may depends on manual message passing rather than an asynchronous network protocol. Successful Stowaway execution results in 2-output transactions, while BIP 79, 78, and this work may produce batched transactions with many outputs.
>>>
>>> ==Specification==
>>>
>>> ===Overview===
>>>
>>> Payjoin requests are made using familiar BIP 21 URIs. Instead of a public HTTP endpoint, this scheme allows a WebTransport client to enroll with a relay server to receive payjoin. Relays may optionally require an authorization credential before allocating resources in order to prevent DoS attacks. Sender and receiver payloads are buffered at the relay to support asynchronous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEAD) prevents the relay from snooping on message contents or forging messages. Aside from a pre-shared secret and relayed asynchronus networking, the version 2 messaging takes much the same form as the existing BIP 78 specification.
>>>
>>> ===Basic scheme===
>>>
>>> The recipient first generates a 256-bit key <code>psk</code>. This pre-shared key will be the basis of end-to-end authenticated encryption and identification of a particular payjoin over the relay.
>>>
>>> Rather than hosting a public server, they start a streaming session to receive messages and allocate a subdirectory from which to relay messages. The first message must include the first 4 bytes of the Sha256 hash of their <code>psk</code> to be enrolled as a subdirectory identifier. The next message streamed from the relay to sender includes the enrolled subdirectory payjoin endpoint. After enrollment, they await a payjoin request on a session identified by the subdirectory. Out of band, the receiver shares a [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin uri including the relay endpoint in the <code>pj=</code> query parameter and the pre-shared key in a new <code>psk=</code> query parameter.
>>>
>>> The sender constructs an encrypted and authenticated payload containing a PSBT and optional parameters similar to BIP 78. The resulting ciphertext ensures message secrecy and integrity when streamed to the recipient by the relay-hosted subdirectory <code>pj=</code> endpoint.
>>>
>>> The sender's request is relayed to the receiver over a streaming session at the subdirectory identified by the hash of <code>psk</code>. Messages are secured by symmetric cipher rather than TLS or Onion routing session key. Sender and receiver may experience network interruption and proceed with the protocol since their request and response are buffered at the Payjoin relay subdirectory.
>>>
>>> ===Payjoin version 2 messaging===
>>>
>>> Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation.
>>>
>>> The payjoin version 2 protocol takes the following steps:
>>>
>>> * The recipient sends the first 4 bytes of <code>H(psk)</code> and optional authentication credential according to [[#receiver-relay-enrollment|receiver relay enrollment]] protocol. It may go offline and replay enrollment to come back online.
>>>
>>> * Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key. To support version 1 senders the relay acts as an unsecured payjoin server so <code>pjos=0</code> must be specified in the URI. Version 2 senders may safely allow output substitution regardless.
>>>
>>> * The sender creates a valid PSBT according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver checklist]] formatted as PSBTv2. We call this the <code>Fallback PSBT</code>. This Fallback PSBT and optional sender parameters are encrypted and authenticated with the <code>psk</code> using ChaCha20Poly1305 and streamed to the relay subdirectory endpoint.
>>>
>>> * The sender awaits a response from the relay stream containing an encrypted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT</code> to request a response if it goes offline.
>>>
>>> * The request is stored in the receiver's subdirectory buffer.
>>> * Once the receiver is online, it awaits a stream of request updates from the relay. The receiver decrypts aund authenticates the payload then checks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver checklist]]. It updates it to include new signed inputs and outputs invalidating sender signatures, and may adjust the fee. We call this the <code>Payjoin PSBT</code>.
>>>
>>> * It responds with the <code>Payjoin PSBT</code> encrypted then authenticated under <code>psk</code> using ChaCha20Poly1305.
>>>
>>> * The relay awaits a connection from the sender if it goes offline. Upon connection, it relays the encrypted <code>Payjoin PSBT</code> to the sender.
>>>
>>> * The sender validates the <code>Payjoin PSBT</code> according to [[#senders-payjoin-psbt-checklist|the sender checklist]], signs its inputs and broadcasts the transaction to the Bitcoin network.
>>>
>>> The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes.
>>>
>>> The Fallback PSBT MUST:
>>>
>>> * Include complete UTXO data.
>>> * Be signed.
>>> * Exclude unnecessary fields such as global xpubs or keypath information. 
>>>
>>> * Set input and output Transaction Modifiable Flags to 1
>>> * Be broadcastable.
>>>
>>> The Fallback PSBT MAY:
>>>
>>> * Include outputs unrelated to the sender-receiver transfer for batching purposes.
>>> * Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1
>>>
>>> The Payjoin PSBT MUST:
>>>
>>> * Include all inputs from the Fallback PSBT.
>>> * Include all outputs which do not belong to the receiver from the Fallback PSBT.
>>> * Include complete UTXO data.
>>>
>>> The Payjoin PSBT sender MAY:
>>>
>>> * Add, remove or modify Fallback PSBT outputs under the control of the receiver (i.e. not sender change).
>>>
>>> The Payjoin PSBT MUST NOT:
>>>
>>> * Shuffle the order of inputs or outputs; the additional outputs or additional inputs must be inserted at a random index.
>>> * Decrease the absolute fee of the original transaction.
>>>
>>> ===Receiver's Payjoin PSBT checklist===
>>>
>>> Other than requiring PSBTv2 the receiver checklist is the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist|the BIP 78 receiver checklist]]
>>>
>>> ===Sender's Payjoin PSBT checklist===
>>>
>>> The version 2 sender's checklist is largely the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklist|the BIP 78 checklist]] with the exception that it expects ALL utxo data to be filled in. BIP 78 required sender inputs UTXO data to be excluded from the PSBT which has caused many headaches since it required the sender to add them back to the Payjoin proposal PSBT. Version 2 has no such requirement.
>>>
>>> ===Relay interactions===
>>>
>>> The Payjoin Relay provides a rendezvous point for sender and receiver to meet. It stores Payjoin payloads to support asynchronous communication. It is available on the open internet over HTTPS to accept both WebTransport for Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.1 to support backwards compatible Payjoin version 1 requests.
>>>
>>> ===Receiver interactions===
>>>
>>> ====Relay enrollment====
>>>
>>> Receivers must enroll to have resources allocated on a relay. Sessions may begin by having a receiver send the first 4 bytes of the Sha256 hash of their <code>psk</code> to the relay. The receiver returns the subdirectory endpoint url. Enrollment may be replayed in case the receiver goes offline.
>>>
>>> Optionally, before returning the uri the receiver may request an authentication token by presenting a message containing only the word <code>Authenticate: <description></code> after which the receiver is required to submit an <code>Authenticate: <token></code> including the token from the Relay out of band. If authentication fails an error is returned.
>>>
>>> In the case a relay is operated by an exchange, it may give out authentication tokens for users of its app, or may require some proof of work out of band. Tokens should be anonymous credentials from the relay describing the parameters of their authorization. Specific credentialing is out of the scope of this proposal.
>>>
>>> ====Receiver Payjoin PSBT response====
>>>
>>> The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaCha20Poly1305 under <code>psk</code>.
>>>
>>> ===Sender interactions===
>>>
>>> The sender starts a WebTransport session with the relay at the Payjoin endpoint URI provided by the receiver. It sends the following payload and awaits a relayed response payload from the receiver.
>>>
>>> ====Version 2 Fallback PSBT request====
>>>
>>> The version 2 Fallback PSBT Payload is constructed in JSON before being encrypted as follows.
>>>
>>> <pre>
>>>
>>> {
>>> "psbt": "<fallback_psbt_data_base64>",
>>>
>>> "params": {
>>> "param1": "<value1>",
>>>
>>> "param2": "<value1>",
>>>
>>> ...
>>> }
>>> }
>>> </pre>
>>>
>>> The payload must be encrypted using ChaCha20Poly1305 by the sender using the <code>psk</code>.
>>>
>>> ====Version 1 Fallback PSBT request====
>>>
>>> The message should be the same as version 2 but unencrypted, as version 1 is unaware of encryption when using an unsecured payjoin server. The Relay should convert the PSBT to PSBTv2 and construct the JSON payload from the HTTP request body and optional query parameters. Upon receiving an unencrypted PSBTv2 response from a receiver, it should convert it to PSBTv0 for compatibility with BIP 78.
>>>
>>> ===Asynchronous relay buffers===
>>>
>>> Each receiver subdirectory on the relay server has a buffer for requests and one for responses. Each buffer updates listeners through awaitable events so that updates are immediately apparent to relevant client sessions.
>>>
>>> ===BIP 21 receiver parameters===
>>>
>>> A major benefit of BIP 78 payjoin over other coordination mechanisms is its compatibility with the universal BIP 21 bitcoin URI standard.
>>>
>>> This proposal defines the following new [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:
>>>
>>> * <code>psk</code>: the pre-shared symmetric key for encryption and authentication with ChaCha20-Poly1305
>>>
>>> * <code>exp</code>: represents a request expiration after which the receiver reserves the right to broadcast the Fallback and ignore requests.
>>>
>>> BIP 78's BIP 21 payjoin parameters are also valid for version 2.
>>>
>>> ===Optional sender parameters===
>>>
>>> When the payjoin sender posts the original PSBT to the receiver, it can optionally specify the following HTTP query string parameters:
>>>
>>> * <code>v</code>: represents the version number of the payjoin protocol that the sender is using. This version is <code>2</code>.
>>>
>>> BIP 78's optional query parameters are also valid as version 2 parameters.
>>>
>>> ==Rationale==
>>>
>>> ===Request expiration & fallback===
>>>
>>> The relay may hold a request for an offline payjoin peer until that peer comes online. However, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty. Doing so exposes a na?ve, surveillance-vulnerable transaction which payjoin intends to avoid.
>>>
>>> The existing BIP 78 protocol has to be synchronous only for automated endpoints which may be vulnerable to probing attacks. It can cover this tradeoff by demanding a fallback transaction that would not preserve privacy the same way as a payjoin. BIP 21 URI can communicate a request expiration to alleviate both of these problems. Receivers may specify a deadline after which they will broadcast this fallback with a new expiration parameter <code>exp=</code>. 
>>>
>>> ===WebTransport===
>>>
>>> Many transport protocols are good candidates for Serverless Payjoin functionality, but WebTransport stands out in its ability to stream and take advantage of QUIC's performance in mobile environments. In developing this BIP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the relay to have more granular and asynchronous understanding of the state of the peers, and this protcol is designed specifically to address the shortcomings of an HTTP protocol's requirement to receive from a reliable, always-online connection.
>>>
>>> While WebTransport and HTTP/3 it is built on are relatively new, widespread support across browsers assures me that it is being accepted as a standard and even has a fallback to HTTP/2 environments. Being built on top of QUIC allows it to multiplex connections from a relay to multiple peers which may prove advantageous for later payjoin protocols between more than two participants contributing inputs, such as those used to fund a lightning node with channels from multiple sources in one transaction, or those with threat models more similar to ZeroLink CoinJoin.
>>>
>>> While Nostr is fascinating from the perspective of censorship resistance, the backwards compatibility with Payjoin v1 would mean only custom Nostr Payjoin relays exposing an https endpoint would be suitable. Nostr transport is also limited by the performance of WebSockets, being an abstraction on top of that protocol. If Nostr authentication were used instead of a symmetric <code>psk</code> then those keys would also need to be communicated out of band and complicate the protocol. There is nothing stopping a new version of this protocol or a NIP making Payjoin version 2 possible over Nostr should Payjoin censorship become a bottleneck in the way of adoption.
>>>
>>> WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, and all popular languages. There is also [[https://w3c.github.io/p2p-webtransport/|a working draft for full P2P WebTransport]] without any relay, which a future payjoin protocol may make use of.
>>>
>>> ===ChaCha20Poly1305 AEAD===
>>>
>>> This authenticated encryption with additional data [[https://en.wikipedia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has high performance. ChaCha20Poly1305 AEAD seems to be making its way into bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki|BIP 324]] as well. The protocol has widespread support in browsers, OpenSSL and libsodium. AES-GCM is more widespread but is both older, slower, and not a dependency in bitcoin software.
>>>
>>> secp256k1 asymmetric cryptography could be used, but symmetric encryption allows for many fewer messages to be sent, a single ephemeral key, and seems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin already requires base64 encoding for PSBTs, so we have it available to encode the 256-bit <code>psk</code> in the BIP 21 parameter.
>>>
>>> ===PSBT Version 2===
>>>
>>> The PSBT version 1 protocol was replaced because it was not designed to have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 uses a hack where a new PSBT is created by the receiver instead of mutating it. This can cause some strange behaviors from signers who don't know where to look to find the scripts that they are accountable for. PSBT version 2 makes mutating a PSBT's inputs and outputs trivial. It also eliminates the transaction finalization step. Receivers who do not understand PSBT version 1 may choose to reject Payjoin version 1 requests and only support PSBT version 2.
>>>
>>> ===Attack vectors===
>>>
>>> Since relays store arbitrary encrypted payloads to the tragedy of the commons and denial of service attacks. Relay operators may impose an authentication requirement before they provide relay service to receivers to mitigate such attacks.
>>>
>>> Since <code>psk</code> is a symmetric key, the first message containing the sender's original PSBT does not have forward secrecy. Since relay buffers are associated with a single ephemeral relay directory, to support request-response simplicity of version 1, this seems appropriate.
>>>
>>> Since the Fallback PSBT is valid, even where <code>exp=</code> is specified, the receiver may broadcast it and lose out on ambiguous privacy protection from payjoin at any time. Though unfortunate, this is the typical bitcoin transaction flow today anyhow.
>>>
>>> ===Network privacy===
>>>
>>> Unlike BIP 78 implementations, sender and receiver peers will only see the IP address of the relay, not their peer's. Relays may be made available via Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow either of the peers to protect their IP from the relay with without requiring both peers to use additional network security dependencies.
>>>
>>> ==Backwards compatibility==
>>>
>>> The receivers advertise payjoin capabilities through [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
>>>
>>> Senders not supporting payjoin will just ignore the <code>pj=</code> parameter and proceed to typical address-based transaction flows. <code>req-pj=</code> may be used to compel payjoin.
>>>
>>> Receivers may choose to support version 1 payloads. Version 2 payjoin URIs should enable <code>pjos=0</code> so that these v1 senders disable output substitution since the v1 messages are neither encrypted nor authenticated, putting them at risk for man-in-the-middle attacks otherwise. The relay protocol should carry on as normal, validating based on HTTP headers and constructing an unencrypted Version 2 payload from optional query parameters, and PSBT in the body.
>>>
>>> The BIP 78 error messages are already JSON formatted, so it made sense to rely on the same dependency for these payloads and error messages.
>>>
>>> ==Reference implementation==
>>>
>>> An early proof of concept draft reference implementation can be found at https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchronous payment flow using WebSockets using PSBTv1 without encryption. Another reference can be found at https://github.com/payjoin/rust-payjoin/pull/21 which uses HTTP long polling for transport and Noise NNpsk0 for crypto. Recently, I've come to realize the rationale for WebTransport, PSBTv2, and ChaCha20-Poly1305 AEAD substitutions and am working on an implementation including this exact specification, but wanted to get early feedback on this design in the spirit of BIP 2.
>>>
>>> ==Acknowledgements==
>>>
>>> Thank you to OpenSats for funding this pursuit, to Human Rights Foundation for putting a bounty on it and funding invaluable BOB Space space support, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas Dorier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike Schmidt, Murch, D?vid Moln?r, Lucas Ontiviero, and uncountable twitter plebs for feedback that has turned this idea from concept into draft, to Mike Jarmuz for suggesting that I write a BIP, and to Satsie for writing the "All About BIPS" zine which I've referenced a number of times in the drafting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hacking on the first iOS Payjoin receiver and uncovering the problem that this solves in the first place.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 99, Issue 25
> *******************************************

2023-08-10 23:09:39

- reply

📅 Original date posted:2023-08-09
🗒️ Summary of this message: The Serverless Payjoin idea has progressed towards a formal specification of Payjoin version 2, allowing payjoin receiver functionality without a secure public endpoint.
📝 Original message:
Hi all,
The Serverless Payjoin idea has come a long way toward formal specification of a Payjoin version 2. In the spirit of BIP 2, I’m sharing an intermediate draft of the BIP here before opening a draft on GitHub for the BIP editors, and before this exact specification has a complete reference implementation. The draft does reference two proof of concept payjoin implementations, one demonstrating use of symmetric cryptography, and the other asynchronous messaging and backwards compatibility.
I’ve updated the Serverless Payjoin gist to reflect this draft specification https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9 in order to preserve the edit history before opening a bips PR.
The specifics have changed significantly compared to the first mailing list post to reflect feedback. Looking forward to hear your thoughts.
Dan
<pre>
BIP: ???
Layer: Applications
Title: Payjoin Version 2: Serverless Payjoin
Author: Dan Gould <d at ngould.dev>
Status: Draft
Replaces: 78
Type: Standards Track
Created: 2023-08-08
License: BSD-2-Clause
</pre>
==Abstract==
This document proposes a backwards-compatible second version of the payjoin protocol described in [[bip-0078.mediawiki|BIP 78]], allowing complete payjoin receiver functionality including payment output substitution without requiring them to host a secure public endpoint. This requirement is replaced with an untrusted third-party relay and streaming clients which communicate using an asynchronous protocol and authenticated encrypted payloads.
==Copyright==
This BIP is licensed under the 2-clause BSD license.
==Motivation==
Payjoin solves the sole privacy problem left open in the bitcoin paper, that transactions with multiple inputs "necessarily reveal that their inputs were owned by the same owner." Breaking that common-input ownership assumption and others requires input from multiple owners. Cooperative transaction construction also increases transaction throughput by providing new opportunity for payment batching and transaction cut-through.
Version 1 coordinates payjoins over a public server endpoint secured by either TLS or Tor onion hidden service hosted by the receiver. Version 1 is synchronous, so both sender and reciever must be online simultaneously to payjoin. Both requirements present significant barriers for all but sophisticated server operators or those wallets with complex Tor integration. These barriers are [[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018358.html|regarded]] as limits to payjoin adoption.
The primary goal of this proposal is to provide a practical coordination mechanism to be adopted in a vast majority of wallet environments. This is realized as a simple protocol built on bitcoin URI requests, web standards, common crypto, and minimal dependencies.
===Relation to BIP 78 (Payjoin version 1)===
The message payloads in this version parrallel those used in BIP 78 while being encapsulated in authenticated encryption, forgoing HTTP messaging for WebTransport streaming of asynchronus interactions, and leveraging PSBT version 2.
The BIP 78 standard allows for an [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#unsecured-payjoin-server|unsecured payjoin server|]] to operate separately from the so-called "payment server" responsible for generating [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] request URIs. Because BIP 78 messages are neither authenticated nor encrypted a malicious unsecured payjoin server is able to modify the Payjoin PSBT in flight, thus requiring [[payment output substitition]] to be disabled. Output substitition is useful for a number of block space optimizations, including payment batching and transaction cut-through. This proposal introduces authentication and encryption to secure output substition while using a relay without compromising sender or receiver privacy.
Although unsecured payjoin server separation is mentioned in BIP 78, no known specification or implementation of one exists. This document specifies one to be backwards compatible with version 1 senders. Receivers responding to version 1 senders must disable output substitution their payloads are plaintext so they may payjoin without the risk of the relay stealing funds.
The protocols in this document reuse BIP 78's BIP 21 URI parameters. A Fallback PSBT timeout parameter is introduced which may also help coordinate the synchronous version 1 protocol.
===Relation to Stowaway===
[[https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/doc/cahoots/STOWAWAY.md|Stowaway]] is a payjoin coordination mechanism which depends on Tor, a third-party relay, and the [[https://samouraiwallet.com/paynym|PayNym]] [[https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki|BIP 47]] Payment codes directory for subdirectory identification and encryption. The payjoin version 2 protocol uses one-time symmetric keys for relay subdirectory identification, authentication, and encryption instead of BIP 47 public keys derived from the wallet. Payjoin version 2 also supports asynchronous messaging, in contrast to online Stowaway's synchronous HTTP-based messaging. Offline stowaway may depends on manual message passing rather than an asynchronous network protocol. Successful Stowaway execution results in 2-output transactions, while BIP 79, 78, and this work may produce batched transactions with many outputs.
==Specification==
===Overview===
Payjoin requests are made using familiar BIP 21 URIs. Instead of a public HTTP endpoint, this scheme allows a WebTransport client to enroll with a relay server to receive payjoin. Relays may optionally require an authorization credential before allocating resources in order to prevent DoS attacks. Sender and receiver payloads are buffered at the relay to support asynchronous interaction. Symmetric authenticated encryption (ChaCha20-Poly1305 AEAD) prevents the relay from snooping on message contents or forging messages. Aside from a pre-shared secret and relayed asynchronus networking, the version 2 messaging takes much the same form as the existing BIP 78 specification.
===Basic scheme===
The recipient first generates a 256-bit key <code>psk</code>. This pre-shared key will be the basis of end-to-end authenticated encryption and identification of a particular payjoin over the relay.
Rather than hosting a public server, they start a streaming session to receive messages and allocate a subdirectory from which to relay messages. The first message must include the first 4 bytes of the Sha256 hash of their <code>psk</code> to be enrolled as a subdirectory identifier. The next message streamed from the relay to sender includes the enrolled subdirectory payjoin endpoint. After enrollment, they await a payjoin request on a session identified by the subdirectory. Out of band, the receiver shares a [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21]] payjoin uri including the relay endpoint in the <code>pj=</code> query parameter and the pre-shared key in a new <code>psk=</code> query parameter.
The sender constructs an encrypted and authenticated payload containing a PSBT and optional parameters similar to BIP 78. The resulting ciphertext ensures message secrecy and integrity when streamed to the recipient by the relay-hosted subdirectory <code>pj=</code> endpoint.
The sender's request is relayed to the receiver over a streaming session at the subdirectory identified by the hash of <code>psk</code>. Messages are secured by symmetric cipher rather than TLS or Onion routing session key. Sender and receiver may experience network interruption and proceed with the protocol since their request and response are buffered at the Payjoin relay subdirectory.
===Payjoin version 2 messaging===
Payjoin v2 messages use [[https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki|BIP 370 PSBT v2]] format to fascilitate PSBT mutation.
The payjoin version 2 protocol takes the following steps:
* The recipient sends the first 4 bytes of <code>H(psk)</code> and optional authentication credential according to [[#receiver-relay-enrollment|receiver relay enrollment]] protocol. It may go offline and replay enrollment to come back online.
* Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key. To support version 1 senders the relay acts as an unsecured payjoin server so <code>pjos=0</code> must be specified in the URI. Version 2 senders may safely allow output substitution regardless.
* The sender creates a valid PSBT according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver checklist]] formatted as PSBTv2. We call this the <code>Fallback PSBT</code>. This Fallback PSBT and optional sender parameters are encrypted and authenticated with the <code>psk</code> using ChaCha20Poly1305 and streamed to the relay subdirectory endpoint.
* The sender awaits a response from the relay stream containing an encrypted <code>Payjoin PSBT</code>. It can replay the <code>Fallback PSBT</code> to request a response if it goes offline.
* The request is stored in the receiver's subdirectory buffer.
* Once the receiver is online, it awaits a stream of request updates from the relay. The receiver decrypts aund authenticates the payload then checks it according to [[https://github.com/bitcoin/bips/blob/master/bip-0078#receivers-original-psbt-checklist|the receiver checklist]]. It updates it to include new signed inputs and outputs invalidating sender signatures, and may adjust the fee. We call this the <code>Payjoin PSBT</code>.
* It responds with the <code>Payjoin PSBT</code> encrypted then authenticated under <code>psk</code> using ChaCha20Poly1305.
* The relay awaits a connection from the sender if it goes offline. Upon connection, it relays the encrypted <code>Payjoin PSBT</code> to the sender.
* The sender validates the <code>Payjoin PSBT</code> according to [[#senders-payjoin-psbt-checklist|the sender checklist]], signs its inputs and broadcasts the transaction to the Bitcoin network.
The encrypted Fallback PSBT and Payjoin PSBT payloads are sent as bytes.
The Fallback PSBT MUST:
* Include complete UTXO data.
* Be signed.
* Exclude unnecessary fields such as global xpubs or keypath information. 
* Set input and output Transaction Modifiable Flags to 1
* Be broadcastable.
The Fallback PSBT MAY:
* Include outputs unrelated to the sender-receiver transfer for batching purposes.
* Set SIGHASH_SINGLE Transaction Modifiable Flags flags to 1
The Payjoin PSBT MUST:
* Include all inputs from the Fallback PSBT.
* Include all outputs which do not belong to the receiver from the Fallback PSBT.
* Include complete UTXO data.
The Payjoin PSBT sender MAY:
* Add, remove or modify Fallback PSBT outputs under the control of the receiver (i.e. not sender change).
The Payjoin PSBT MUST NOT:
* Shuffle the order of inputs or outputs; the additional outputs or additional inputs must be inserted at a random index.
* Decrease the absolute fee of the original transaction.
===Receiver's Payjoin PSBT checklist===
Other than requiring PSBTv2 the receiver checklist is the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#receivers-original-psbt-checklist|the BIP 78 receiver checklist]]
===Sender's Payjoin PSBT checklist===
The version 2 sender's checklist is largely the same as the [[https://github.com/bitcoin/bips/blob/master/bip-0078#senders-payjoin-proposal-checklist|the BIP 78 checklist]] with the exception that it expects ALL utxo data to be filled in. BIP 78 required sender inputs UTXO data to be excluded from the PSBT which has caused many headaches since it required the sender to add them back to the Payjoin proposal PSBT. Version 2 has no such requirement.
===Relay interactions===
The Payjoin Relay provides a rendezvous point for sender and receiver to meet. It stores Payjoin payloads to support asynchronous communication. It is available on the open internet over HTTPS to accept both WebTransport for Payjoin version 2, accepting encrypted payloads, and optionally HTTP/1.1 to support backwards compatible Payjoin version 1 requests.
===Receiver interactions===
====Relay enrollment====
Receivers must enroll to have resources allocated on a relay. Sessions may begin by having a receiver send the first 4 bytes of the Sha256 hash of their <code>psk</code> to the relay. The receiver returns the subdirectory endpoint url. Enrollment may be replayed in case the receiver goes offline.
Optionally, before returning the uri the receiver may request an authentication token by presenting a message containing only the word <code>Authenticate: <description></code> after which the receiver is required to submit an <code>Authenticate: <token></code> including the token from the Relay out of band. If authentication fails an error is returned.
In the case a relay is operated by an exchange, it may give out authentication tokens for users of its app, or may require some proof of work out of band. Tokens should be anonymous credentials from the relay describing the parameters of their authorization. Specific credentialing is out of the scope of this proposal.
====Receiver Payjoin PSBT response====
The receiver streams the base64 Payjoin PSBT as encrypted bytes from ChaCha20Poly1305 under <code>psk</code>.
===Sender interactions===
The sender starts a WebTransport session with the relay at the Payjoin endpoint URI provided by the receiver. It sends the following payload and awaits a relayed response payload from the receiver.
====Version 2 Fallback PSBT request====
The version 2 Fallback PSBT Payload is constructed in JSON before being encrypted as follows.
<pre>
{
"psbt": "<fallback_psbt_data_base64>",
"params": {
"param1": "<value1>",
"param2": "<value1>",
...
}
}
</pre>
The payload must be encrypted using ChaCha20Poly1305 by the sender using the <code>psk</code>.
====Version 1 Fallback PSBT request====
The message should be the same as version 2 but unencrypted, as version 1 is unaware of encryption when using an unsecured payjoin server. The Relay should convert the PSBT to PSBTv2 and construct the JSON payload from the HTTP request body and optional query parameters. Upon receiving an unencrypted PSBTv2 response from a receiver, it should convert it to PSBTv0 for compatibility with BIP 78.
===Asynchronous relay buffers===
Each receiver subdirectory on the relay server has a buffer for requests and one for responses. Each buffer updates listeners through awaitable events so that updates are immediately apparent to relevant client sessions.
===BIP 21 receiver parameters===
A major benefit of BIP 78 payjoin over other coordination mechanisms is its compatibility with the universal BIP 21 bitcoin URI standard.
This proposal defines the following new [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP 21 URI]] parameters:
* <code>psk</code>: the pre-shared symmetric key for encryption and authentication with ChaCha20-Poly1305
* <code>exp</code>: represents a request expiration after which the receiver reserves the right to broadcast the Fallback and ignore requests.
BIP 78's BIP 21 payjoin parameters are also valid for version 2.
===Optional sender parameters===
When the payjoin sender posts the original PSBT to the receiver, it can optionally specify the following HTTP query string parameters:
* <code>v</code>: represents the version number of the payjoin protocol that the sender is using. This version is <code>2</code>.
BIP 78's optional query parameters are also valid as version 2 parameters.
==Rationale==
===Request expiration & fallback===
The relay may hold a request for an offline payjoin peer until that peer comes online. However, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty. Doing so exposes a naïve, surveillance-vulnerable transaction which payjoin intends to avoid.
The existing BIP 78 protocol has to be synchronous only for automated endpoints which may be vulnerable to probing attacks. It can cover this tradeoff by demanding a fallback transaction that would not preserve privacy the same way as a payjoin. BIP 21 URI can communicate a request expiration to alleviate both of these problems. Receivers may specify a deadline after which they will broadcast this fallback with a new expiration parameter <code>exp=</code>. 
===WebTransport===
Many transport protocols are good candidates for Serverless Payjoin functionality, but WebTransport stands out in its ability to stream and take advantage of QUIC's performance in mobile environments. In developing this BIP, serverless payjoin proofs of concept using TURN, HTTP/1.1 long polling, WebSockets, Magic Wormhole, and Nostr have been made. Streaming allows the relay to have more granular and asynchronous understanding of the state of the peers, and this protcol is designed specifically to address the shortcomings of an HTTP protocol's requirement to receive from a reliable, always-online connection.
While WebTransport and HTTP/3 it is built on are relatively new, widespread support across browsers assures me that it is being accepted as a standard and even has a fallback to HTTP/2 environments. Being built on top of QUIC allows it to multiplex connections from a relay to multiple peers which may prove advantageous for later payjoin protocols between more than two participants contributing inputs, such as those used to fund a lightning node with channels from multiple sources in one transaction, or those with threat models more similar to ZeroLink CoinJoin.
While Nostr is fascinating from the perspective of censorship resistance, the backwards compatibility with Payjoin v1 would mean only custom Nostr Payjoin relays exposing an https endpoint would be suitable. Nostr transport is also limited by the performance of WebSockets, being an abstraction on top of that protocol. If Nostr authentication were used instead of a symmetric <code>psk</code> then those keys would also need to be communicated out of band and complicate the protocol. There is nothing stopping a new version of this protocol or a NIP making Payjoin version 2 possible over Nostr should Payjoin censorship become a bottleneck in the way of adoption.
WebTransport is already shipped in both Firefox, Chrome, h3 in Rust, Go, and all popular languages. There is also [[https://w3c.github.io/p2p-webtransport/|a working draft for full P2P WebTransport]] without any relay, which a future payjoin protocol may make use of.
===ChaCha20Poly1305 AEAD===
This authenticated encryption with additional data [[https://en.wikipedia.org/wiki/ChaCha20-Poly1305|algorithm]] is standardized in RFC 8439 and has high performance. ChaCha20Poly1305 AEAD seems to be making its way into bitcoin by way of [[https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki|BIP 324]] as well. The protocol has widespread support in browsers, OpenSSL and libsodium. AES-GCM is more widespread but is both older, slower, and not a dependency in bitcoin software.
secp256k1 asymmetric cryptography could be used, but symmetric encryption allows for many fewer messages to be sent, a single ephemeral key, and seems suitable given the one time use of BIP 21 URIs for Payjoin. Payjoin already requires base64 encoding for PSBTs, so we have it available to encode the 256-bit <code>psk</code> in the BIP 21 parameter.
===PSBT Version 2===
The PSBT version 1 protocol was replaced because it was not designed to have inputs and outputs be mutated. Payjoin mutates the PSBT, so BIP 78 uses a hack where a new PSBT is created by the receiver instead of mutating it. This can cause some strange behaviors from signers who don't know where to look to find the scripts that they are accountable for. PSBT version 2 makes mutating a PSBT's inputs and outputs trivial. It also eliminates the transaction finalization step. Receivers who do not understand PSBT version 1 may choose to reject Payjoin version 1 requests and only support PSBT version 2.
===Attack vectors===
Since relays store arbitrary encrypted payloads to the tragedy of the commons and denial of service attacks. Relay operators may impose an authentication requirement before they provide relay service to receivers to mitigate such attacks.
Since <code>psk</code> is a symmetric key, the first message containing the sender's original PSBT does not have forward secrecy. Since relay buffers are associated with a single ephemeral relay directory, to support request-response simplicity of version 1, this seems appropriate.
Since the Fallback PSBT is valid, even where <code>exp=</code> is specified, the receiver may broadcast it and lose out on ambiguous privacy protection from payjoin at any time. Though unfortunate, this is the typical bitcoin transaction flow today anyhow.
===Network privacy===
Unlike BIP 78 implementations, sender and receiver peers will only see the IP address of the relay, not their peer's. Relays may be made available via Tor hidden service or Oblivious HTTP in addition to IP / DNS to allow either of the peers to protect their IP from the relay with without requiring both peers to use additional network security dependencies.
==Backwards compatibility==
The receivers advertise payjoin capabilities through [[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki|BIP21's URI Scheme]].
Senders not supporting payjoin will just ignore the <code>pj=</code> parameter and proceed to typical address-based transaction flows. <code>req-pj=</code> may be used to compel payjoin.
Receivers may choose to support version 1 payloads. Version 2 payjoin URIs should enable <code>pjos=0</code> so that these v1 senders disable output substitution since the v1 messages are neither encrypted nor authenticated, putting them at risk for man-in-the-middle attacks otherwise. The relay protocol should carry on as normal, validating based on HTTP headers and constructing an unencrypted Version 2 payload from optional query parameters, and PSBT in the body.
The BIP 78 error messages are already JSON formatted, so it made sense to rely on the same dependency for these payloads and error messages.
==Reference implementation==
An early proof of concept draft reference implementation can be found at https://github.com/payjoin/rust-payjoin/pull/78. It implements an asynchronous payment flow using WebSockets using PSBTv1 without encryption. Another reference can be found at https://github.com/payjoin/rust-payjoin/pull/21 which uses HTTP long polling for transport and Noise NNpsk0 for crypto. Recently, I've come to realize the rationale for WebTransport, PSBTv2, and ChaCha20-Poly1305 AEAD substitutions and am working on an implementation including this exact specification, but wanted to get early feedback on this design in the spirit of BIP 2.
==Acknowledgements==
Thank you to OpenSats for funding this pursuit, to Human Rights Foundation for putting a bounty on it and funding invaluable BOB Space space support, who I owe a thank you to as well. Thank you to Ethan Heilman, Nicolas Dorier, Kukks, nopara73, Kristaps Kaupe, Kixunil, /dev/fd0/, Craig Raw, Mike Schmidt, Murch, Dávid Molnár, Lucas Ontiviero, and uncountable twitter plebs for feedback that has turned this idea from concept into draft, to Mike Jarmuz for suggesting that I write a BIP, and to Satsie for writing the "All About BIPS" zine which I've referenced a number of times in the drafting process. Thanks to Armin Sabouri, Ron Stoner, and Johns Beharry for hacking on the first iOS Payjoin receiver and uncovering the problem that this solves in the first place.

2023-08-09 16:03:59

- reply

📅 Original date posted:2023-08-08
🗒️ Summary of this message: Silent Payments could solve the problem of address expiration by using a new BIP 21 URI parameter `req-exp=` to enforce expiration at the application layer.
📝 Original message:
Address expiration does seem to be a generic problem, but Silent Payments could play a role in solving the problem once and for all. Payment requests often have expiration in practice because of moving exchange rates but no way to communicate that to sending software. BTCPay checkout page includes a 15 minute countdown by default. Payments made to a checkout after the expiration are saved in an error state for the BTCPay operator and customer to triage.
Since enforcing expiration by consensus sounds unpopular, one generic way to enforce it at the application layer would be to use a new BIP 21 URI parameter `req-exp=`.
BIP 21 specifies that parameters starting `req-` are considered required. URIs containing unknown `req-` parameters are considered invalid and the parameter can still be shown in UI. Support for `req-exp=` could thus be implemented in BIP 21 libraries rather than for each address type, and without necessarily supporting Silent Payments.
New address specifications like Silent Payments could recommend wallets request payments using BIP 21 URI and `req-exp=` to begin to solve this problem in general. Wallets supporting Silent Payments & `req-exp=` could then apply expiration to older address types too.
Dan
> On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request at lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: BIP-352 Silent Payments addresses should have an
> expiration time (Samson Mow)
> 2. Re: BIP-352 Silent Payments addresses should have an
> expiration time (Brandon Black)
> 3. Re: BIP-352 Silent Payments addresses should have an
> expiration time (josibake)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Aug 2023 11:41:39 -0700
> From: Samson Mow <samson.mow at gmail.com>
> To: Peter Todd <pete at petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <CAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Why the 180 year limit? imho should plan for longer.
>
> On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of
>> toxic
>> data: funds sent to those addresses can be easily lost forever.
>>
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole
>> point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually
>> expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>
>> Fixing this is easy: add a 3 byte field to silent payments addresses,
>> encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days
>> is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>>
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a
>> simple
>> "address expired". Lightning invoices are a good example here: while
>> invoices
>> does not require expiration from a technical point of view, they do expire
>> for
>> similar UX reasons as applies to silent payments.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/fc013648/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 5 Aug 2023 07:46:52 -0700
> From: Brandon Black <freedom at reardencode.com>
> To: Peter Todd <pete at petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID: <ZM5g3Fi_vErCeEx0 at console>
> Content-Type: text/plain; charset=us-ascii
>
> On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
>>> bytes | prefix | usable bits | granularity | max expiration
>>> ------|------------|-------------|-------------|---------------
>>> 1 | 0b0 | 7 | year | 128 years
>>> 2 | 0b10 | 14 | week | 315 years
>>> 3 | 0b110 | 21 | day | 5700 years
>>> 4 | 0b1110 | 28 | block | 5100 years
>>> 5 | 0b11110 | 35 | ??? | ???
>>> 6 | 0b111110 | 42 | ??? | ???
>>> 7 | 0b1111110 | 49 | ??? | ???
>>> 8 | 0b11111110 | 56 | ??? | ???
>>
>> 1) Having the granularity of the limit depend on *when* the limit is to be
>> applied in a UX nightmare. It is far simpler to just pick a useful granularity,
>> and include enough bytes of integer to work until well into the future. 3
>> bytes, 24-bits, of days is 45,000 years. That's plenty.
>
> I must not have explained my proposal clearly. The granularity depends
> not on when it is applied, but on the encoding. For example, the bits
> 0b00000001 encode an expiration 1-year from the epoch of the system. The
> bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.
>
> When decoding, the position of the highest `0` bit in the expiration
> indicates the byte-length, and the granularity. If the expiration's
> highest bit is `0`, it is 1-byte long, and the bits following the
> highest `0` encode a number of years. If the first `0` bit is in the
> second highest position, then it is 2-bytes long and the bits following
> the highest 0 encode a number of weeks. &c.
>
>> 2) Your suggestion would result in a protocol that degrades over time, as the
>> granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
>> where we're creating something now with a limit in the future. 100 years from
>> now - if silent payments still exists - people will still want to create silent
>> payment addresses that expire, say, 30 days in the future. Your suggestion does
>> not allow that.
>
> My suggestion does degrade over time in one sense: if it is still in use
> 128 years in the future, users are required to start using at least 2
> bytes to encode their expiration instead of 1, even if they only need
> year granularity. After 315 years they have to start using at least 3
> bytes even if they only need week granularity.
>
> I'd rather enable users to encode their expirations in 1 or 2 bytes
> today and degrade by requiring more bytes than require 3 bytes now.
>
> Best,
>
> --Brandon
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 06 Aug 2023 14:20:06 +0000
> From: josibake <josibake at protonmail.com>
> To: Peter Todd <pete at petertodd.org>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Peter,
>
> Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
>
> That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
>
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.
> 2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.
> 3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.
> 4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
> 6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.
>
> You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.
>
> Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).
>
> In summary, expiration dates are a separate problem, outside the scope of what BIP352 is trying to address. If we can work toward a more general solution, there is nothing preventing us from adding this to a future silent payments version, but even then, I'm still not convinced expiration dates for static payment codes is a good idea, for the reasons I mentioned above.
>
> Cheers,
> Josie
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of toxic
>> data: funds sent to those addresses can be easily lost forever.
>>
>
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>
>
>> Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>>
>
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a simple
>> "address expired". Lightning invoices are a good example here: while invoices
>> does not require expiration from a technical point of view, they do expire for
>> similar UX reasons as applies to silent payments.
>>
>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: publickey - josibake at protonmail.com - 0x616516B8.asc
> Type: application/pgp-keys
> Size: 3154 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.bin>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 855 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230806/edd207c8/attachment.sig>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************

2023-06-07 23:21:46

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Payjoin, an interactive settlement batching method, can significantly reduce fee expenditure and blockchain throughput while improving Bitcoin's privacy. It breaks the assumption that all transaction inputs belong to the same person and can be used for individual and enterprise circumstances.
📝 Original message:Hi list, The following message details a number of examples using payjoin P2EP to coordinate payment batches. I stray from the original shape of stenographic payjoin, what I call "canonical payjoin" with 2 inputs and many outputs, to describe what I believe are novel structures that break heuristics used to track batched payments. The later examples match typical batch structure 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
—
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/1655885695762808832) for more efficient use of blockspace. Blockchain is a slow 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 customer payjoin is what led to the formal spec. No surprise then that a merchant / customer frame stuck versus a frame payment batching like lightning. Lightning has been batching for scaling all along. The following outlines how payjoin fits into batched transfer settlement infrastructure and how it helps prepare for the next wave of blockspace scarcity.
The term "payjoin" is used to describe both an interactive way to build transactions between peers on the web, aka Pay-to-Endpoint (P2EP), and an ambiguous transaction structure, typically with many inputs and two outputs that I dub *canonical payjoin*. Canonical payjoin looks like transaction behavior 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 sole privacy problem left open in Satoshi's whitepaper. In an effort to improve bitcoin's privacy through payjoin adoption, I outline a number of ways payjoin can significantly reduce fee expenditure and blockchain throughput in individual and enterprise circumstances. Some of these new techniques preserve privacy for transactions otherwise thought of as unambiguous and certainly traceable. The examples mostly ignore mining fees for the sake of simplicity.
## 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 relation between inputs and outputs. The named labels are not. Third party analysts assume both inputs come from the same entity (because they usually do). They also assume `output0` is the payment because neither input is alone sufficient 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 payjoin. 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 btc input txo too. Bob's 4 btc is not the 1 btc amount Alice paid, which is not visible.
## Enter Output Substitution
Payjoin [payment output substitution](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#payment-output-substitution) (`pjos`) lets a receiver 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`. [Serverless Payjoin](https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9) 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 for 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 🥁💥.
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=https://payjoin.bob.cash` on an the wall at the bar.
Alice would scan it to propose the transaction as before, but Bob returns the payjoin proposal with one tiny change. In this way he keeps his tip private 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 not know of `address1` since Bob sent it online as a payjoin proposal. They can't look up what they don't know.
### Payment forwarding
Toys aside, substitution is powerful. What if Bob planned to pay his `C`loud provider next time he got paid. He could substitute `C`loudy's address instead 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 authenticated by Bob, so both of them agree that this payjoin pays Bob. Since transactions are atomic, Bob takes no custody of the funds going to `C`loudy either.
Bob could also turn this into a canonical payjoin by adding input. Or instead, 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 he 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 fun.
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 deposit, Bob may substitute a single output with many, spreading the inbound amount across multiple addresses. Instead of just *address* substitution he substitutes 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 transaction fee. Bob can take any remaining mining fee costs from his increased transaction'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 Cloudy's output from the prior example to forward Cloudy an exact invoice amount 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-analysis-of-batching-in-bitcoin-9bdf81a394e0) [explores](https://bitcoinops.org/en/payment-batching/) sender-batched transactions. It follows that inputs to batched transactions are assumed to belong to the cluster of the entity making payments (Bob, in this case). Receiver side payment batching kills this 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 ⚡️ channel
A's output1: 3 btc A's change
```
Bob's lightning output helps preserve privacy even moreso because it belongs 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 funded channels to achieve the common input assumption-busting result even without BIP 78 as well.
### Mix and Batch 🥣
Combining it all forces multiple ambiguous interpretations of the transaction graph. With basic networking, and no coordinator, Both Alice and Bob can pay multiple parties beyond themselves, combine inputs and consolidate funds without fear for being censored.
Interaction lets multiple ambiguous possibilities converge to preserve bitcoin'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 🍰
```
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 ⚡️ 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 significant ambiguity to foil vast swaths of heuristic analysis being done today by breaking their most basic assumptions. Because of payjoin's intra-transaction transfers from Alice to Bob, [CoinJoin sudoku](http://www.coinjoinsudoku.com/advisory/) analysis does not apply.
Even Alice and Bob preserve some privacy in the other's view. Even though one knows the other's inputs, they cannot be certain that any of their counterpart's outputs will end up in their counterpart's wallet or if output substitution has been used.
## Progress before rainbows 🌈 and unicorns 🦄
Bob and Alice still know the subtransactions of their counterpart. As of today, 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 could still report the other's chosen inputs and outputs to build a cluster with 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.

2023-06-07 23:18:40

- reply

📅 Original date posted:2023-01-22
🗒️ Summary of this message: A new payjoin upgrade allows for surveillance-free bitcoin transfers without the need for a public server, using a relay and symmetric-key for security. However, the payjoin protocol assumes synchronous communication in an asynchronous world.
📝 Original message:Hi all,
I'm publishing a payjoin upgrade in response to a request from this list. The payjoin receiver no longer has to run a public server. They lean on a relay for the connection and share a symmetric-key for security rather than a TLS certificate or a Tor hidden service.
I think this work raises a greater problem which is that payjoin assumes synchronous communication while it’s an asynchronous world.
I added the full write-up in plain text below, though I recommend reading the gist for improved formatting and in order to benefit from future edits:
https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9
Best regards,
Dan
Serverless Payjoin
Receive surveillance-busting bitcoin transfers without hosting a secure endpoint
OVERVIEW
Payjoin[1] solves the sole privacy problem left open in the bitcoin paper, that transactions with multiple inputs "necessarily reveal that their inputs were owned by the same owner."[2] Breaking that common-input ownership assumption requires contributions from multiple owners via interaction, namely hosting a server endpoint secured by a certificate on the receiving side. This problem has been singled out on this list as a barrier to greater payjoin adoption.[3]
Instead of a peer-hosted endpoint, this scheme weilds a TURN[4] relay for connectivity and symmetric cryptography for security. Without a replacement for secured networking, the relay could steal funds. Aside from a pre-shared secret and relayed networking, the protocol takes the same form as the existing BIP 78 payjoin spec.
BASIC SCHEME
The recipient requests that the relay allocate them an endpoint at which they may be reached by UDP. Once allocated, they listen on it. They then generate a 256-bit key, psk. Out of band, they share a BIP 21[5] payjoin uri including their unique relay allocation endpoint in the pj query parameter and psk in a new psk query parameter.
The sender constructs their request containing an original PSBT as in BIP 78. Instead of sending it over TLS or Tor, they follow noise framework NNpsk0[6] pattern. They encrypt the request using psk alongside an ephemeral sender key and MAC. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient by the pj endpoint.
The pay-to-endpoint protocol proceeds to produce a payjoin as in BIP 78 except that messages are secured by the noise NNpsk0 pattern rather than TLS or Tor.
IMPROVEMENTS
HTTP/3
TURN defaults to UDP. In order to adhere to the BIP 78 protocol HTTP messaging, HTTP/3 should be used on top of TURN/UDP.
Offline Asynchronous Payjoins
It may be possible for a relay to hold a requeust for an offline payjoin peer until that peer comes online. However, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty. Doing so exposes a naïve, surveillance-vulnerable transaction which payjoin intends to avoid. More research needs to be done before such a protocol can be recommended.
Nostr
While a custom Nostr relay could in theory replace the TURN relay while sharing shnorr crypto with bitcoin, it would require another protocol to synchronize networking, since Nostr makes no assumptions about whether a peer is online or not, and a careful cryptography audit to secure. TURN and Noise are already well understood, tested, and have production library support across multiple popular languages and other bitcoin-related projects. Noise even has tooling for formal verification. Nostr relays may prove more likely to allow public access and more robust if we figure out async payjoin, however.
NOTEWORTHY DETAILS
Attack vectors
Since TURN relays can be used for any kind of internet traffic they are vulnerable to the tragedy of the commons. Relay operators may impose authentication requirements for endpoint allocation provisions.
Since psk is a symmetric key, the first message containing the sender's original PSBT does not have forward secrecy.
Network Privacy
Peers will only see the IP address of the TURN relay but not their peer's. TURN relays may be made available via Tor hidden service in addition to IP to allow either of the peers to protect their IP with Tor without forcing the other to use it too.
IMPLEMENTATION
I've published working proof of concept sender, receiver clients and relay code in rust[7]
ACKNOWLEDGEMENTS
Deepest gratitude to Ethan Heilman for sitting down with me to help get to the bottom of the requirements of this problem, to Ruben Somsen for this slick format, and to all those engaged in defending the right to privacy.
REFERENCES
[1] BIP 78 A Simple Payjoin Proposal, Nicolas Doier:
https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki
[2] Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto:
https://chaincase.app/bitcoin.pdf
[3] [bitcoin-dev] PayJoin adoption, Craig Raw:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018358.html
[4] RFC 5766: Traversal Using Relays around NAT (TURN):
https://www.rfc-editor.org/rfc/rfc5766
[5] BIP 21 URI Scheme, Nils Schneider, Matt Corallo:
https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki
[6] Noise Explorer: NNpsk0:
https://noiseexplorer.com/patterns/NNpsk0
[7] Serverless PayJoin PoC:
https://github.com/chaincase-app/payjoin/pull/21

2023-06-07 23:16:49

- reply

📅 Original date posted:2022-11-08
📝 Original message:Funding channels on a lightning node can be a pain. First, I need to send funds to my node on-chain. Then I need to make another transaction to open channels. Instead, we can use the BIP 78 PayJoin P2EP protocol to fund and open channels in a single transaction.
We do not communicate over the shared blockchain, we share the blockchain by communicating.
Here is an illustration of how the BIP 78 protocol pairs with the BOLT 2 Channel establishment protocol:
┌──────────────┐ ┌─────────────────┐ ┌──────┐
│Lightning Peer│ │My Lightning Node│ │Sender│
└──────┬───────┘ └───────┬─────────┘ └───┬──┘
│ │ │
│ BOLT 2 ├─────── Bip21 with ?pj= ───────►│
│ Channel Establishment │ │
│ │◄────── Original PSBT ──────────┤
│ │ │
│ │ │
│◄──────── open_channel ─────────┤ │
│ │ │
├──────── accept_channel ───────►│ │
│ │ BIP 78 │
│ │ │
│◄─────── funding_created ───────┤ │
│ │ │
├──────── funding_signed ───────►│ │
│ │ │
│ │ PayJoin Proposal │
│ ├────── PSBT ───────►│
│ │ │
│ │ │
│ │ ┌─ PayJoin + Funding ───────┤
│ │ │ Transaction │
│ │ │ │
x│xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx│xxx ▼ xxxxxxxxxxxxxxxxxxxxxxxxxx│x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx BITCOIN NETWORK xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x│xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx│xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx│x
│ │ │
│◄────────channel_ready ─────────┤ │
│ │ │
├──────── channel_ready ────────►│ │
│ │ │
We use P2EP to automate [PSBT Channel establishment](https://gist.github.com/yuyaogawa/3d69bfa03b0702b8ff12c210bc795a6a) communications. As an added benefit, The BIP 78 spec helps avoid surveillance heuristics as well. On-chain, these transactions look like regular PayJoins when using Taproot outputs.
I thank Martin Habovštiak for the initial work on this idea. Thank you to Riccardo Casatta for developing the rust payjoin crate further. Thank you to Evan Lin for early hacking late nights on this idea. Thanks to my Legends of Lightning Tournament teammates Armin Sabouri and Nick Farrow.
We have released "nolooking," an experimental alpha that implements this work, on the Umbrel app store.
A brand new node can become totally connected in a single transaction that opens channels to outbound peers, and could immediately swap for inbound capacity. Just by scanning a single QR code.
[Source](https://github.com/chaincase-app/nolooking)
Want to help? The rust [payjoin crate](https://github.com/Kixunil/payjoin) needs love in the form of code review and unit testing. Don’t hesitate to reach out.
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221108/fac7c62b/attachment-0001.html>