📅 Original date posted:2023-08-10

🗒️ Summary of this message: The text discusses the Serverless Payjoin idea and raises concerns about securely sharing the secret key and potential attack vectors.

📝 Original message:

Hi Dan,

A couple more more thoughts:

> Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a pj= query parameter describing the relay subdirectory endpoint and psk= 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.

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?

Cheers,

AdamISZ/waxwing

Sent with Proton Mail secure email.

------- Original Message -------

On Wednesday, August 9th, 2023 at 11:32, Dan Gould via bitcoin-dev 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

>

>

>
> 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
> 

>

>

> ==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 psk. 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 psk 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 pj= query parameter and the pre-shared key in a new psk= 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 pj= endpoint.

>

>

> The sender's request is relayed to the receiver over a streaming session at the subdirectory identified by the hash of psk. 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 H(psk) 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 pj= query parameter describing the relay subdirectory endpoint and psk= parameter with base64 encoded 256-bit secret key. To support version 1 senders the relay acts as an unsecured payjoin server so pjos=0 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 Fallback PSBT. This Fallback PSBT and optional sender parameters are encrypted and authenticated with the psk using ChaCha20Poly1305 and streamed to the relay subdirectory endpoint.

>

> * The sender awaits a response from the relay stream containing an encrypted Payjoin PSBT. It can replay the Fallback PSBT 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 Payjoin PSBT.

>

> * It responds with the Payjoin PSBT encrypted then authenticated under psk using ChaCha20Poly1305.

>

> * The relay awaits a connection from the sender if it goes offline. Upon connection, it relays the encrypted Payjoin PSBT to the sender.

>

> * The sender validates the Payjoin PSBT 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 psk 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 Authenticate: after which the receiver is required to submit an Authenticate: 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 psk.

>

>

> ===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.

>

>

>
> {
> "psbt": "",
>
> "params": {
> "param1": "",
>
> "param2": "",
>
> ...
> }
> }
> 

>

>

> The payload must be encrypted using ChaCha20Poly1305 by the sender using the psk.

>

>

> ====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:

>

> * psk: the pre-shared symmetric key for encryption and authentication with ChaCha20-Poly1305

>

> * exp: 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:

>

> * v: represents the version number of the payjoin protocol that the sender is using. This version is 2.

>

>

> 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 exp=.

>

>

> ===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 psk 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 psk 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 psk 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 exp= 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 pj= parameter and proceed to typical address-based transaction flows. req-pj= may be used to compel payjoin.

>

>

> Receivers may choose to support version 1 payloads. Version 2 payjoin URIs should enable pjos=0 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

📅 Original date posted:2023-07-26

🗒️ Summary of this message: The protocol described in the text is an interesting idea for incorporating 2FA authentication into blind signing. However, there may be vulnerabilities in the protocol that need to be addressed.

📝 Original message:

It's an interesting idea for a protocol. If I get it right, your basic idea here is to kind of "shoehorn" in a 2FA authentication, and that the blind-signing server has no other function than to check the 2FA?

This makes it different from most uses of blind signing, where *counting* the number of signatures matters (hence 'one more forgery etc). Here, you are just saying "I'll sign whatever the heck you like, as long as you're authorized with this 2FA procedure".

Going to ignore the details of practically what that means - though I'm sure that's where most of the discussion would end up - but just looking at your protocol in the gist:

It seems you're not checking K values against attacks, so for example this would allow someone to extract the server's key from one signing:

1 Alice, after receiving K2, sets K1 = K1' - K2, where the secret key of K1' is k1'.

2 Chooses b as normal, sends e' as normal.

3 Receiving s2, calculate s = s1 + s2 as normal.

So since s = k + ex = (k' + bx) + ex = k' + e'x, and you know s, k' and e', you can derive x. Then x2 = x - x1.

(Gist I'm referring to: https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb)

Sent with Proton Mail secure email.

------- Original Message -------

On Wednesday, July 26th, 2023 at 03:44, moonsettler via bitcoin-dev wrote:

> Hi All,

>

> I believe it's fairly simple to solve the blinding (sorry for the bastard notation!):

>

> Signing:

>

> X = X1 + X2

> K1 = k1G

> K2 = k2G

>

> R = K1 + K2 + bX

> e = hash(R||X||m)

>

> e' = e + b

> s = (k1 + e'*x1) + (k2 + e'*x2)

> s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)

>

> sG = (K1 + K2 + bX) + eX

> sG = R + eX

>

> Verification:

>

> Rv = sG - eX

> ev = hash(R||X||m)

> e ?= ev

>

> https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb

>

> Been trying to get a review on this for a while, please let me know if I got it wrong!

>

> BR,

> moonsettler

>

>

> ------- Original Message -------

> On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:

>

>

>

> > > Party 1 never learns the final value of (R,s1+s2) or m.

> >

> > Actually, it seems like a blinding step is missing. Assume the server (party 1)

> > received some c during the signature protocol. Can't the server scan the

> > blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as in

> > signature verification and then check c == c'? If true, then the server has the

> > preimage for the c received from the client, including m.

> > _______________________________________________

> > bitcoin-dev mailing list

> > bitcoin-dev at lists.linuxfoundation.org

> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>

> _______________________________________________

> bitcoin-dev mailing list

> bitcoin-dev at lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2023-07-24

🗒️ Summary of this message: Wagner's attack is discussed in the conversation, and it is suggested that using the 3rd round of MuSig1 can help avoid it. There are also discussions about blind signing schemes and the need for proof of a well-formed signing request.

📝 Original message:

@ZmnSCPxj:

yes, Wagner is the attack you were thinking of.

And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R commitments.

@Tom:

As per above it seems you were more considering MuSig1 here, not MuSig2. At least in this version. So you need the initial commitments to R.

Jonas' reply clearly has covered a lot of what matters here, but I wanted to mention (using your notation):

in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c could be given to the server, to construct s1, but since a1 = H(L, X1) and L is the serialization of all (in this case, 2) keys, that wouldn't work for blinding the final key, right?

But, is it possible that this addresses the other problem?

If the server is given c1*a1 instead as the challenge for signing (with their "pure" key x1), then perhaps it avoids the issue? Given what's on the blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 + a2X2, is it the case that you cannot find a1 and therefore you cannot correlate the transaction with just the quantity 'c1*a1' which the server sees?

But I agree with Jonas that this is just the start, i.e. the fundamental requirement of a blind signing scheme is there has to be some guarantee of no 'one more forgery' possibility, so presumably there has to be some proof that the signing request is 'well formed' (Jonas expresses it below as a ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the face of it, that is what's needed).

@Jonas, Erik:

'posk' is probably meant as 'proof of secret key' which may(?) be a mixup with what is sometimes referred to in the literature as "KOSK" (iirc they used it in FROST for example). It isn't clear to me yet how that factors into this scenario, although ofc it is for sure a potential building block of these constructions.

Sent with Proton Mail secure email.

------- Original Message -------

On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev wrote:

> Hi Tom,

>

> I'm not convinced that this works. As far as I know blind musig is still an open

> research problem. What the scheme you propose appears to try to prevent is that

> the server signs K times, but the client ends up with K+1 Schnorr signatures for

> the aggregate of the server's and the clients key. I think it's possible to

> apply a variant of the attack that makes MuSig1 insecure if the nonce commitment

> round was skipped or if the message isn't determined before sending the nonce.

> Here's how a malicious client would do that:

>

> - Obtain K R-values R1[0], ..., R1[K-1] from the server

> - Let

> R[i] := R1[i] + R2[i] for all i <= K-1

> R[K] := R1[0] + ... + R1[K-1]

> c[i] := H(X, R[i], m[i]) for all i <= K.

> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that

> c[0] + ... + c[K-1] = c[K].

> - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].

> - Let

> s[K] = s[0] + ... + s[K-1].

> Then (s[K], R[K]) is a valid signature from the server, since

> s[K]G = R[K] + c[K]a1X1,

> which the client can complete to a signature for public key X.

>

> What may work in your case is the following scheme:

> - Client sends commitment to the public key X2, nonce R2 and message m to the

> server.

> - Server replies with nonce R1 = k1G

> - Client sends c to the server and proves in zero knowledge that c =

> SHA256(X1 + X2, R1 + R2, m).

> - Server replies with s1 = k1 + c*x1

>

> However, this is just some quick intuition and I'm not sure if this actually

> works, but maybe worth exploring.

> _______________________________________________

> bitcoin-dev mailing list

> bitcoin-dev at lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev