npub1nv…kqw2t

Last Notes

2023-08-11 01:09:39 CEST

- reply

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

2023-07-27 02:26:34 CEST

- reply

📅 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 <bitcoin-dev at lists.linuxfoundation.org> 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

2023-06-08 01:21:02 CEST

- reply

📅 Original date posted:2023-05-03
🗒️ Summary of this message: A new paper by Wei Dai, Okamoto, and Yamamoto highlights the insufficiency of the aEUF-CMA definition of the Aumayr paper, which doesn't address the possibility of multiple adaptors on the same message at once. The paper has a lot of meat in terms of security definitions, but it is not attempting to rewrite reductions.
📝 Original message:Hi Lloyd and list,
While on the road and re-downloading the papers, I realised there is a "new" paper published December 2022 by Wei Dai, Okamoto and Yamamoto on this same topic:
https://eprint.iacr.org/2022/1687
and, strikingly, it focuses on the exact same point I made here in Section 3 - namely that the aEUF-CMA definition of the Aumayr paper doesn't address the possibility of multiple-adaptors-on-the-same-message-at-once.
A pretty big facepalm moment that I didn't bother to search carefully enough to find that!
Also it's cool that such renowned cryptographers are turning their heads towards this subject :)
It does have a nice illustration of why that definition (which as you know has been reused by other researchers) is insufficient, by making up a malicious version of the "preSign" (i.e. adaptor-sign) algorithm which leaks an arbitrary signature after two calls, while it still fits the definition of aEUF-CMA!
The paper has a *lot* of meat in terms of security definitions (only had a brief chance to read parts of it, as I'm on the road, so this is high level vague perspective), but afaict it is not actually attempting to rewrite reductions(?), so perhaps more work is needed on that(?).
Cheers,Adam
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Monday, May 1st, 2023 at 12:37, AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Lloyd,
> thanks for taking a look.
>
>> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production.
>
> I'm struggling with this one - say I hold privkey x for pubkey X. And I publish adaptor for a point Y (DL y) for message m, like: s' = k - y + H(R|X|m)x with k the nonce and R the nonce point.
>
> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of course the secret y is revealed.
>
> What do you mean in saying "any signature on m that is published reveals y"? Clearly you don't mean any signature on any key (i.e. not the key X). But I also can't parse it if you mean "any signature on m using key X", because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' as defined above, right?
>
> I think the point of confusion is maybe about the DLC construct? I referenced that in Section 4.2, parenthetically, because it's analogous in one sense - in MuSig(2) you're fixing R via a negotiation, whereas in Dryja's construct you're fixing R "by definition". When I was talking about single key Schnorr, I was saying that's what's missing, and thereby making them useless.
>
> I think I must have missed some implicit concept in your argument otherwise?
>
>> I haven't read the proofs in detail but I am optimistic about your approach
>
> Appreciate it, but I fear the optimism is misplaced; as you can see from some notes I made in Issue 1, I think I had a pretty substantially invalid line of reasoning in those proof. Probably I need to revert to the forking lemma style arguments that you and Aumayr et al (and some others) took. I also am revisiting a clearer definition of what security threats need to be addressed. It all seems very nuanced.
>
> But hey, that's why I published it and asked for feedback - if nothing else it made *me* think more carefully :)
>
>> One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure.
> Appreciate these thoughts. In particular your point about "generalization of tweaking" is clearly important, I bet other people have thought about it before me. Btw are there any papers on tweaking in general? I'm suddenly reminded of Poelstra's paper on taproot itself, which istr was an entirely different approach.
>
> Sent with [Proton Mail](https://proton.me/) secure email.
>
> ------- Original Message -------
> On Sunday, April 30th, 2023 at 22:23, Lloyd Fournier via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi waxwing,
>>
>> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production.
>>
>> I haven't read the proofs in detail but I am optimistic about your approach. One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure.
>>
>> Cheers,
>>
>> LL
>>
>> On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi list,
>>> I was motivated to look more carefully at the question of the security of using signature adaptors after recently getting quite enthused about the idea of using adaptors across N signing sessions to do a kind of multiparty swap. But of course security analysis is also much more important for the base case of 2 party swapping, which is of .. some considerable practical importance :)
>>>
>>> There is work (referenced in Section 3 here) that's pretty substantial on "how secure are adaptors" (think in terms of security reductions) already from I guess the 2019-2021 period. But I wanted to get into scenarios of multiple adaptors at once or multiple signing sessions at once with the *same* adaptor (as mentioned above, probably this is the most important scenario).
>>>
>>> To be clear this is the work of an amateur and is currently unreviewed - hence (a) me posting it here and (b) putting the paper on github so people can easily add specific corrections or comments if they like:
>>>
>>> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
>>>
>>> I'll note that I did the analysis only around MuSig, not MuSig2.
>>>
>>> The penultimate ("third case"), that as mentioned, of "multiple signing sessions, same adaptor" proved to be the most interesting: in trying to reduce this to ECDLP I found an issue around sequencing. It may just be irrelevant but I'd be curious to hear what others think about that.
>>>
>>> If nothing else, I'd be very interested to hear what experts in the field have to say about security reductions for this primitive in the case of multiple concurrent signing sessions (which of course has been analyzed very carefully already for base MuSig(2)).
>>>
>>> Cheers,
>>> AdamISZ/waxwing
>>>
>>> Sent with Proton Mail secure email.
>>> _______________________________________________
>>> 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/20230503/549203d7/attachment-0001.html>

2023-06-08 01:21:00 CEST

- reply

📅 Original date posted:2023-04-28
🗒️ Summary of this message: The security of using signature adaptors for multiparty swaps has been analyzed by an amateur, with a focus on scenarios involving multiple adaptors or signing sessions. The analysis is currently unreviewed and available on GitHub. An issue around sequencing was found in the case of multiple signing sessions with the same adaptor. Expert opinions on security reductions for this primitive in the case of multiple concurrent signing sessions are sought.
📝 Original message:Hi list,
I was motivated to look more carefully at the question of the security of using signature adaptors after recently getting quite enthused about the idea of using adaptors across N signing sessions to do a kind of multiparty swap. But of course security analysis is also much more important for the base case of 2 party swapping, which is of .. some considerable practical importance :)
There is work (referenced in Section 3 here) that's pretty substantial on "how secure are adaptors" (think in terms of security reductions) already from I guess the 2019-2021 period. But I wanted to get into scenarios of multiple adaptors at once or multiple signing sessions at once with the *same* adaptor (as mentioned above, probably this is the most important scenario).
To be clear this is the work of an amateur and is currently unreviewed - hence (a) me posting it here and (b) putting the paper on github so people can easily add specific corrections or comments if they like:
https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
I'll note that I did the analysis only around MuSig, not MuSig2.
The penultimate ("third case"), that as mentioned, of "multiple signing sessions, same adaptor" proved to be the most interesting: in trying to reduce this to ECDLP I found an issue around sequencing. It may just be irrelevant but I'd be curious to hear what others think about that.
If nothing else, I'd be very interested to hear what experts in the field have to say about security reductions for this primitive in the case of multiple concurrent signing sessions (which of course has been analyzed very carefully already for base MuSig(2)).
Cheers,
AdamISZ/waxwing
Sent with Proton Mail secure email.

2023-06-08 01:10:26 CEST

- reply

📅 Original date posted:2022-06-12
📝 Original message:List denizens,
As per the title, a suggested protocol for doing anti-Sybil that isn't too demanding for the users, but actually keeps a decent level of privacy.
Notice how it's mostly focused on a user/customer of a service/product/website, but it could conceivably useful in e.g. anti-Sybil in things like Lightning.
Sorry that as usual I write rather long but there are several conveniently arranged sections you can click on :)
https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f
(with apologies for my backronym-ing sins)
Cheers,
waxwing/AdamISZ
Sent with Proton Mail secure email.

2023-06-08 01:09:57 CEST

- reply

📅 Original date posted:2022-05-23
📝 Original message:Jonas, all,:
So I do want to ask a couple further clarifying questions on this point, but I got rather majorly sidetracked :)
I wonder can you (and other list readers!) take a look at my attempt here to summarize what is described in Footnote 2 of the draft BIP (as it's related to this discussion and also .. it's pretty interesting generally!):
https://gist.github.com/AdamISZ/ca974ed67889cedc738c4a1f65ff620b
(btw github gists have equation rendering now which is nice!)
Thanks,
waxwing/AdamISZ
Sent with ProtonMail secure email.
------- Original Message -------
On Monday, May 23rd, 2022 at 10:56, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thank you for taking the time to look at the BIP and reference code, waxwing. I
> don't know if you're overlooking anything, so let me try to restate the
> paragraph in the BIP draft that attempts to cover this topic [0].
>
> Suppose signers would just abort in the presence of identical public keys. In
> that case, a disruptive signer can permanently DoS-attack a session by simply
> copying the public key of some other signer. Therefore, the BIP is much more
> useful if it can deal with identical public keys.
>
> The MuSig2 BIP draft requires some added complexity to handle identical public
> keys (because of the MuSig2* optimization). But this solution naturally allows
> identifying and removing disruptive signers, which ultimately reduces the
> complexity for MuSig2 users.
>
> [0] https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#public-key-aggregation
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-08 01:09:56 CEST

- reply

📅 Original date posted:2022-05-22
📝 Original message:Jonas,
Many thanks for getting the BIP draft out. Particularly appreciate the reference code!
I have a question about identical pubkeys (including how it relates to MuSig2* optimization):
What is the purpose of allowing this? Isn't it always the case that N equal keys combined with M non-equal keys is logically equivalent to 1+M keys? It non trivially complicates certain aspects of the algorithm to allow it and I guess I must be missing something in my previous statement because, otherwise, isn't it pointless (and pretty unwise, considering how likely it is to come from an error)? The whole 'second key' thing in MuSig2 is a sorty of icky side effect.
A valid point about this is already made in the BIP and enunciated clearly and in detail: that MuSig2 is designed to discover lying at the partial sig verify stage, so it's not really that I'm saying that what's in the BIP is logically or mathematically wrong; it just seems unwise and needlessly complex. The case of 2 keys being identical does not imply an attacker; it is far more likely to be a busted implementation by counterparties where they're accidentally using P1, P1 instead of their intended P1, P2.
I suppose the key word is 'needlessly' - is there a need for this that I'm overlooking?
Cheers,
waxwing/AdamISZ
Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, April 5th, 2022 at 17:57, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like
> to propose to the community for discussion. The BIP is compatible with BIP340
> public keys and signatures. It supports tweaking, which allows deriving BIP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with key and
> script paths. You can find the BIP draft at:
> https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
>
> The draft is in a state where it should be possible to write an implementation
> based on the BIP that passes the basic test vectors (as, e.g., demonstrated by
> [0]). The draft BIP also contains a reference implementation in python. Please
> be aware that this is only a draft and that it may still be necessary to make
> small tweaks to the algorithms and test vectors.
>
> [0] https://github.com/btcsuite/btcd/pull/1820
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-08 01:09:08 CEST

- reply

📅 Original date posted:2022-05-21
📝 Original message:Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, May 3rd, 2022 at 02:37, vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Typical P2PK looks like that: "<signature> <pubkey> OP_CHECKSIG". In a typical scenario, we have "<signature>" in out input and "<pubkey> OP_CHECKSIG" in our output. I wonder if it is possible to use covenants right here and right now, with no consensus changes, just by requiring a specific signature. To start with, I am trying to play with P2PK and legacy signatures, but it may turn out, that doing such things with Schnorr signatures will be more flexible and will allow more use cases.
>
>
> The simplest "pay to signature" script I can think of is: "<signature> OP_SWAP OP_CHECKSIG". Then, any user can provide just a "<pubkey>" in some input, as a part of a public key recovery. The problem with such scheme is that it is insecure. Another problem is that we should handle it carefully, because signatures are removed from outputs. However, we could replace it with some signature hash, then it will be untouched, for example: "OP_TOALTSTACK OP_DUP OP_HASH160 <signatureHash> OP_EQUALVERIFY OP_FROMALTSTACK OP_CHECKSIG".
>
Doesn't this suffer from the standard "circular reference" problem for covenants? To pay to a utxo U1, whose scriptpubkey is a (p2wsh wrapped, say) script of: sig, op_checksig, I must create that sig, using my chosen public key, and a message which is a (signature style) hashing of a tx TX1, where an/the input to TX1 is U1, and the txid of U1 'hashes over' that script, which includes the sig we're trying to create. You can't make a hash of data which includes that hash (unless the hash fn is broken ofc).
I don't think that's affected by the later discussion here or in Zmn's response right?
Also a side detail which you might find useful in these ponderings: pubkey recovery is, as you know, possible in ECDSA but is not possible in BIP340 schnorr (which has key prefixing, i.e. the pubkey is included in the message hash binding, i.e. the e in s = k + ex), but is in the original Schnorr where only R(=kG), m are included in e. Easy to see why: from R, s and e(=H(R,m) .. easy to calculate) you can get P = (sG - R)* e^-1.
But in BIP340 Schnorr where (R, s) is published and e (=H(P, R, m)) is not, you cannot reconstruct e and so can only calculate e*P, which by DL assumption does not reveal P. Another way to put it is: if you made up a random R, s you wouldn't be able to find the right 'P' to put into e=H(P, R, m) so that the same P came out, and so that the sig actually verifies.
Cheers,
waxwing/AdamISZ

2023-06-08 01:08:50 CEST

- reply

📅 Original date posted:2022-05-10
📝 Original message:> I suppose ultimately this brings up the question of the scope of this BIP. The abstract points out that the BIP contains both a definition of address derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that the 'Motivation' section gives motivation for standardisation of derivation (this includes things like time schedule), but not the second area - certificate signing. I think the second area is much more tricky, but much more to the point is, isn't it the case that that second area, can be interpreted without consensus between wallet developers? So say you were a hardware wallet provider, or a "node in a box" provider - your customers want you to provide the ability move funds around, including e.g. moving funds out of an old Joinmarket wallet (in which say there is a now expired timelock address utxo) by just entering its BIP39 seed. If this BIP addresses that, it should be enough.
>
> I don't doubt that there's gains to be had from a broader community discussing and agreeing the details of how to create a fidelity bond certificate, but it's a separate, and more difficult, task.
>
> Cheers,
> waxwing/AdamISZ
Further to that last point, as the BIP draft currently says:
" Almost all wallets implementing this standard can use their
already-existing "Sign Message" function to sign the certificate
message. As the certificate message itself is always an ascii string,
the wallet may not need to specially implement this section at all but
just rely on users copypasting their certificate message into the
already-existing "Sign Message" user interface. This works as long as
the wallet knows how to use the private key of the timelocked address
for signing messages."
So, isn't that an argument that we don't need to specify the certificate message format here?
On the other hand, I can hardly disagree that it's worth presenting a kind of 'default' way of doing it. But I fear it is not at all simple to decide what a secure, general format should be (as per the discussion we started having here about domain separation tags).
Cheers,
waxwing/AdamISZ

2023-06-08 01:08:50 CEST

- reply

📅 Original date posted:2022-05-10
📝 Original message:------- Original Message -------
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning waxwing,
<snip>
>
> Ah, yes, now I remember.
> I discussed this with Tamas as well in the past and that is why we concluded that in defiads, each UTXO can host at most one advertisement at any one time.
> In the case of defiads there would be a sequence counter where a higher-sequenced advertisement would replace lower-sequenced advertisement, so you could update, but at any one time, for a defiads node, only one advertisement per UTXO could be used.
> This assumed that there would be a defiads network with good gossip propagation so our thinking at the time was that a higher-sequenced advertisement would quickly replace lower-sequenced ones on the network.
> But it is simpler if such replacement would not be needed, and you could then commit to the advertisement directly on the UTXO via a tweak.
>
> Each advertisement would also have a specific application ID that it applied to, and applications on top of defiads would ask the local defiads node to give it the ads that match a specific application ID, so a UTXO could only be used for one application at a time.
> This would be equivalent to domain separation tags that waxwing mentions.
>
> Regards,
> ZmnSCPxj
>
I suppose ultimately this brings up the question of the scope of this BIP. The abstract points out that the BIP contains both a definition of address derivation, but also how to sign fidelity bond certificates.
My feeling is that the latter might be better not included? I note that the 'Motivation' section gives motivation for standardisation of derivation (this includes things like time schedule), but not the second area - certificate signing. I think the second area is much more tricky, but much more to the point is, isn't it the case that that second area, can be interpreted without consensus between wallet developers? So say you were a hardware wallet provider, or a "node in a box" provider - your customers want you to provide the ability move funds around, including e.g. moving funds out of an old Joinmarket wallet (in which say there is a now expired timelock address utxo) by just entering its BIP39 seed. If this BIP addresses that, it should be enough.
I don't doubt that there's gains to be had from a broader community discussing and agreeing the details of how to create a fidelity bond certificate, but it's a separate, and more difficult, task.
Cheers,
waxwing/AdamISZ

2023-06-08 01:08:49 CEST

- reply

📅 Original date posted:2022-05-10
📝 Original message:------- Original Message -------
On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello ZmnSCPxj,
>
> This is an intended feature. I'm thinking that the same fidelity bond
> can be used to running a JoinMarket maker as well as a Teleport
> (Coinswap) maker.
>
> I don't believe it's abusable. It would be a problem if the same
> fidelity bond is used by two makers in the same application, but
> JoinMarket takers are already coded to check for this, and Teleport
> takers will soon as well. Using the same bond across different
> applications is fine.
>
> Best,
> CB
>
Hi Chris, Zmn, list,
I've noodled about this a few times in the past (especially when trying to figure out an LSAG style ring sig based FB for privacy, but that does not seem workable), and I can't decide the right perspective on it.
A user sacrifices X amount of time-value-of-money (henceforth TVOM) by committing in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in Teleport, then presumably he'll only do it if (probabilistically) he thinks Y+Z > X.
But as an assessor of FB1 in Joinmarket, I don't know if it's also being used for Teleport, and more importantly, if it's being used somewhere else I'm not even aware of. Now I'm not an economist I admit, so I might not be intuit-ing this situation right, but it fees to me like the right answer is "It's fine for a closed system, but not an open one." (i.e. if the set of possible usages is not something that all participants have fixed in advance, then there is an effective Sybilling problem, like I'm, as an assessor, thinking that sacrificed value 100 is there, whereas actually it's only 15, or whatever.)
As I mentioned in https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/993#issuecomment-1110784059 , I did wonder about domain separation tags because of this, and as I vaguely alluded to there, I'm really not sure about it.
If it was me I'd want to include domain separation via part of the signed message, since I don't see how it hurts? For scenarios where reuse is fine, reuse can still happen.
Cheers,
waxwing/AdamISZ

2023-06-08 01:08:49 CEST

- reply

📅 Original date posted:2022-05-21
📝 Original message:> > > As a better analogy: I am borrowing a piece of gold, smelting it down to make
> > > a nice shiny advertisement "I am totally not a bot!!", then at the end of the
> > > lease period, re-smelting it back and returning to you the same gold piece
> > > (with the exact same atoms constituting it), plus an interest from my business,
> > > which gained customers because of the shiny gold advertisement claiming "I
> > > am totally not a bot!!".
> > >
> > > That you use the same piece of gold for money does not preclude me using
> > > the gold for something else of economic value, like making a nice shiny
> > > advertisement, so I think your analysis fails there.
> > > Otherwise, your analysis is on point, but analyses something else entirely.
Back to this analogy, I think it's imprecise in a way that's important to not overlook: you cannot re-use the same gold atoms in two different advertisements. Use of a fidelity bond, being basically a signature, is completely 'non-rivalrous' as I think the economists say.
> Yes, that is why Tamas switched to defiads, as I had convinced him that it would be similar enough without actually being a covenant scam like you described.
>
> > In any case, I tend to agree with your other posts on the subject. For the burn to be provably non-dilutable it must be a cost provably associated to the scenario which relies upon the cost. This provides the global uniqueness constraint (under cryptographic assumptions of difficulty).
>
>
> Indeed.
> I suspect the only reason it is not yet a problem with existing JoinMarket and Teleport is simply that no convenient software currently exists which allows the same bond to be used by both, thus making it safe in practice but not in theory.
> But the theory implies that if somebody does make such software, effectively both systems will become joined as effectively only a single identity exists in both systems.
> This may not be a problem either since the intent is that Teleport will obsolete JoinMarket someday, but if other applications start using the same scheme without requiring a commitment to a specific application, this may also effectively render Teleport less useful as well.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
So, general comment: it seems like both you and Eric agree with my uncertain intuition up-thread and therefore do we all agree that the correct solution (to whatever extent there is one) is something like domain separation tags, as we discussed earlier? It's still a matter of social consensus: if appending "JM" to the end of a certificate signature is intended to mean that this fidelity bond can only be used in Joinmarket and not anywhere else, well we can only as individual users demand that (i.e. *I* might not accept it in Teleport, but what if Fred down the street does? It's not enough for me to rely on my own criteria!), and more subtly, it makes sense only if we all have an unambiguous definition of what Joinmarket *is* - ironically it is precisely the thing brought most into question by the achievement of real decentralization in a system.
Cheers,
waxwing/AdamISZ

2023-06-08 01:02:45 CEST

- reply

📅 Original date posted:2022-01-25
📝 Original message:Hi Billy,
I read through the description. I think systems like this *mostly* fail due to game theory.
With punishment-by-burn you have various issues that make it to my mind pretty unstable, too unstable to use for any serious system. To be fair, this isn't cut-and-dried. So let me unpack:
(I briefly touched on why I dismissed penalties via burn in my gist, section: "Not feeling the burn".)
There is a distinction between penalty via burn to unspendable output and penalty via burn to miner fees. The latter has an obvious problem: if your counterparties collude with (or are) miners, they may not actually be penalized at all (now to be clear, that is a problematic attack ex nihilo: nobody usually can be sure who's mining the next block, but markets have a way of solving and coordinating such things: see e.g. the various MEV discussions and initiatives in Ethereum for an example of that).
But the former (provable burn) is still imo extremely unstable: if the penalty tx destroys all the money, what is the incentive for the honest party to punish? In such a scenario even a one cent donation from the attacker to the victim might prevent the penalty from happening.
You can combine 'destruction of most, or some, of the funds' with a smaller payout to the aggrieved party, but then again you have to factor in the possibility of bribes. The Sabu post you linked describes it as: "There are precise and delicate formulas for calculating the amount of loss of the issuer and the creditor, which ensures that just and true act in both parties are cost-effective in all situations." I agree it's delicate, but after having spent time looking into these things, my strong intuition is that it will never be properly stable.
In the PathCoin description I am specifically looking for a trustless system, with this finesse: we still count it as trustless even though we are using penalties as disincentive, because the penalty *consists of a payment directly from the attacker to the attacked, and that payment is larger than the amount stolen*. I claim that that *is* stable.
Notice that Lightning has the same model (in LN-Penalty), as long as 'claiming the whole channel capacity' is enough to be larger than what is stolen (see: channel reserves etc.).
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 25th, 2022 at 11:53, Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> There was a protocol someone mentioned a while back called Sabu that had the same goals. As i recall, it had some pretty promising constructs, but would have a critical vulnerability that could be exploited by miners. This is the write up:
>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Perhaps some of the techniques there could be combined with your ideas to get closer to a solution.
>
> On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I took the time to write up this rather out-there idea:
>>
>> Imagine you wanted to send a coin just like email, i.e. just transfer data to the counterparty.
>>
>> Clearly this is in general entirely impossible; but with what restrictions and assumptions could you create a toy version of it?
>>
>> See this gist for a detailed build up of the idea:
>>
>> https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
>>
>> Basically: using signature adaptors and CTV or a similar covenant, you could create a fully trustless transfer of control of a utxo from one party to another with no interaction with the rest of the group, at the time of transfer (modulo of course lots and lots of one-time setup).
>>
>> The limitations are extreme and as you'd imagine. In the gist I feel like I got round one of them, but not the others.
>>
>> (I very briefly mention comparison to e.g. statechains or payment pools; they are making other tradeoffs against the 'digital cash' type of goal. There is no claim that this 'pathcoin' idea is even viable yet, let alone better than those ideas).
>>
>> Publishing this because I feel like it's the kind of thing imaginative minds like the ones here, may be able to develop further. Possibly!
>>
>> waxwing / AdamISZ
>> _______________________________________________
>> 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/20220125/e672234b/attachment.html>

2023-06-08 01:02:45 CEST

- reply

📅 Original date posted:2022-01-24
📝 Original message:Hello list,
I took the time to write up this rather out-there idea:
Imagine you wanted to send a coin just like email, i.e. just transfer data to the counterparty.
Clearly this is in general entirely impossible; but with what restrictions and assumptions could you create a toy version of it?
See this gist for a detailed build up of the idea:
https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
Basically: using signature adaptors and CTV or a similar covenant, you could create a fully trustless transfer of control of a utxo from one party to another with no interaction with the rest of the group, at the time of transfer (modulo of course lots and lots of one-time setup).
The limitations are extreme and as you'd imagine. In the gist I feel like I got round one of them, but not the others.
(I very briefly mention comparison to e.g. statechains or payment pools; they are making other tradeoffs against the 'digital cash' type of goal. There is no claim that this 'pathcoin' idea is even viable yet, let alone better than those ideas).
Publishing this because I feel like it's the kind of thing imaginative minds like the ones here, may be able to develop further. Possibly!
waxwing / AdamISZ

2023-06-07 20:21:31 CEST

- reply

📅 Original date posted:2019-11-23
📝 Original message:Two party mixes can be useful in the context of a very large number of them.
There is no pretence that doing one such, or even doing several such, gives any privacy *guarantees*.
However, if it can be arranged that such 'mixes' occur frequently across a broad spectrum of wallets - and the claim is that that is possible precisely because at least one of the two participants needs to do *absolutely nothing at all* for the join to happen - then the degradation of blockchain analysis could be pretty severe.
What's described here therefore is essentially an attempt to go to the other far extreme from 'rigidly controlled and coordinated large mix sets' to 'ultra loosely coupled almost zero coordination mixing', trading off size in one step for convenience/low effort/even zero effort mixing. Part of that may (or may not) involve Proposers being specialised entities, and it's only the Receiver side that's zero effort.
It should be noted that the two extremes are not incompatible; if one is valuable, it doesn't mean the other isn't.
But what I think you can deduce: a proposal to do SNICKER that just involved a very small set of users would not be much use (still not zero, though); the tradeoffs have been made having in mind the idea of more usage, especially more *broad* usage.
Answering about 2 party joins in more general terms:
Any such coinjoin, no matter its pattern, will break the common input ownership heuristic. If there are equal sized outputs of the same scriptpubkey type (as is proposed) then that delinking effect is of considerable value also.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 22, 2019 2:57 PM, popo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi, AFAIK snicker is limited to 2 party mixes for the foreseeable future.
> What makes this a useful anonymity system for cryptocurrency/Bitcoin?
>
> Thanks
>
> On 11/22/19 3:02 PM, AdamISZ via bitcoin-dev wrote:
>
> > Hi Riccardo,
> > Apologies for not answering before, this slipped my mind.
> > Clearly what you propose is possible, and adding the proposer's own
> > signed transaction is a nice touch to make it more privacy-viable.
> > For now my inclination is not to add this complexity, especially because
> > of the cost implication.
> > I'd note though that your idea about adding in second-stage transactions
> > aligns with the CoinJoinXT idea (or perhaps, just the segwit idea!).
> > Proposers could send sequences of transactions with various patterns,
> > including backouts and promises, but it would clearly be way more
> > complicated than what we're considering right now.
> > Regards,
> > Adam/waxwing
> > Sent with ProtonMail https://protonmail.com Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Wednesday, November 6, 2019 4:52 PM, Riccardo Casatta via bitcoin-dev
> > bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Hello Adam,
> > > are you sure you can't tackle the watch-only issue?
> > > What if the proposer create the coinjoin-tx, plus another tx
> > > (encrypted with the shared secret) which is a 1 input-1 output (1to1)
> > > tx which spend his output to another of his key.
> > > At this point when the receiver accept the proposal tx he could create
> > > other tx 1to1 which are spending his tweaked output to pure bip32
> > > derived key, he than broadcast together the coinjoin tx and for every
> > > output of the coinjoin tx one other tx which is a 1to1 tx.
> > > Notes:
> > >
> > > - We are obviously spending more fee because there are more txs
> > > involved but the receiver ends up having only bip32 derived outputs.
> > >
> > > - The receiver must create the 1to1 tx or the receiver lose privacy by
> > > being the only one to create 1to1 tx
> > >
> > > - a good strategy could be to let the coinjoin tx have a very low fee,
> > > while the 1to1 tx an higher one so there is less risk that only the
> > > coinjoin gets mined
> > >
> > > - Whit this spending strategy, the wallet initial scan does not need
> > > to be modified
> > >
> > >
> > > Il giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org
> > > mailto:bitcoin-dev at lists.linuxfoundation.org> ha scritto:
> > >
> > > Just to chime in on these points:
> > >
> > > My discussions with ghost43 and ThomasV led me to the same
> > > conclusion, at least in general, for the whole watch-only issue:
> > >
> > > It's necessary that the key tweak (`c` as per draft BIP) be known
> > > by Proposer (because has to add it to transaction before signing)
> > > and Receiver (to check ownership), but must not be known by anyone
> > > else (else Coinjoin function fails), hence it can't be publically
> > > derivable in any way but must require information secret to the
> > > two parties. This can be a pure random sent along with the
> > > encrypted proposal (the original concept), or based on such, or
> > > implicit via ECDH (arubi's suggestion, now in the draft, requiring
> > > each party to access their own secret key). So I reached the same
> > > conclusion: the classic watch-only use case of monitoring a wallet
> > > in real time with no privkey access is incompatible with this.
> > >
> > > It's worth mentioning a nuance, however: distinguish two
> > > requirements: (1) to recover from zero information and (2) to
> > > monitor in real time as new SNICKER transactions arrive.
> > >
> > > For (2) it's interesting to observe that the tweak `c` is not a
> > > money-controlling secret; it's only a privacy-controlling secret.
> > > If you imagined two wallets, one hot and one cold, with the second
> > > tracking the first but having a lower security requirement because
> > > cold, then the `c` values could be sent along from the hot to the
> > > cold, as they are created, without changing the cold's security
> > > model as they are not money-controlling private keys. They should
> > > still be encrypted of course, but that's largely a technical
> > > detail, if they were exposed it would only break the effect of the
> > > coinjoin outputs being indistinguishable.
> > >
> > > For (1) the above does not apply; for there, we don't have anyone
> > > telling us what `c` values to look for, we have to somehow
> > > rederive, and to do that we need key access, so it reverts to the
> > > discussion above about whether it might be possible to interact
> > > with the cold wallet 'manually' so to speak.
> > >
> > > To be clear, I don't think either of the above paragraphs describe
> > > things that are particularly likely to be implemented, but the
> > > hot/cold monitoring is at least feasible, if there were enough
> > > desire for it.
> > >
> > > At the higher level, how important is this? I guess it just
> > > depends; there are similar problems (not identical, and perhaps
> > > more addressable?) in Lightning; importing keys is generally
> > > non-trivial; one can always sweep non-standard keys back into the
> > > HD tree, but clearly that is not really a solution in general; one
> > > can mark out wallets/seeds of this type as distinct; not all
> > > wallets need to have watch-only (phone wallets? small wallets?
> > > lower security?) one can prioritise spends of these coins. Etc.
> > >
> > > Some more general comments:
> > >
> > > Note Elichai's comment on the draft (repeated here for local
> > > convenience:
> > > https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#gistcomment-3014924)
> > > about AES-GCM vs AES-CBC, any thoughts?
> > >
> > > I didn't discuss the security of the construction for a Receiver
> > > from a Proposer who should after all be assumed to be an attacker
> > > (except, I emphasised that PSBT parsing could be sensitive on this
> > > point); I hope it's clear to everyone that the construction Q = P
> > > + cG is only controllable by the owner of the discrete log of P
> > > (trivial reduction: if an attacker who knows c, can find the
> > > private key q of Q, he can derive the private key p of P as q - c,
> > > thus he is an ECDLP cracker).
> > >
> > > Thanks for all the comments so far, it's been very useful.
> > >
> > > AdamISZ/waxwing/Adam Gibson
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Monday, October 21, 2019 4:04 PM, SomberNight via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > >
> > > > > The SNICKER recovery process is, of course, only required for
> > > wallet
> > > >
> > > > recovery and not normal wallet use, so I don't think a small
> > > amount of
> > > > round-trip communication between the hot wallet and the cold
> > > wallet is
> > > > too much to ask---especially since anyone using SNICKER with a
> > > > watching-only wallet must be regularly interacting with their cold
> > > > wallet anyway to sign the coinjoins.
> > > >
> > > > What you described only considers the "initial setup" of a
> > > watch-only wallet. There are many usecases for watch-only wallets.
> > > There doesn't even necessarily need to be any offline-signing
> > > involved. For example, consider a user who has a hot wallet on
> > > their laptop with xprv; and wants to watch their addresses using
> > > an xpub from their mobile. Or consider giving an xpub to an
> > > accountant. Or giving an xpub to your Electrum Personal Server
> > > (which is how it works).
> > > >
> > > > Note that all these usecases require "on-going" discovery of
> > > addresses, and so they would break.
> > > >
> > > > ghost43
> > > >
> > > > (ps: Apologies Dave for the double-email; forgot to cc list
> > > originally)
> > > >
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > >
> > > --
> > > Riccardo Casatta - @RCasatta https://twitter.com/RCasatta
> >
> > 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