Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)
Hey Dan, Very interested in such a protocol finally becoming standardized. Quick little nit I noticed as well, are you sure base64 encoding is the best choice for the psk in the URI? You may find that having to urlencode the special characters in base64 it impacts readability and adds a layer of complexity if a human wanted to extract the psk from the URI for some reason. I suggest using something like [base64url](https://datatracker.ietf.org/doc/html/rfc4648#section-5) which modifies base64 slightly to be more suited to this purpose. Symphonic --- Original Message --- On Friday, August 11th, 2023 at 5:03 PM, Dan Gould via bitcoin-dev wrote: > Hi waxwing > > thanks for the detailed response. You've identified a number of flaws both in > the protocol and the document that can be fixed. I sincerely appreciate it. > If more comes to mind, fire away. > > > I wanted to immediately "nit" a point I saw as I was reading: > > > > > Because BIP 78 messages are neither authenticated nor encrypted a > > > malicious unsecured payjoin server is able to modify the Payjoin PSBT in > > > flight, > > > > Taken as is - i.e. out of context! - this is just wrong. The BIP explicitly > > states: > > > > "The sender must ensure that the url refers to a scheme or protocol using > > authenticated encryption, for example TLS with certificate validation, or a > > .onion link to a hidden service whose public key identifier has already > > been communicated via a TLS connection. Senders SHOULD NOT accept a url > > representing an unencrypted or unauthenticated connection. " > > > Nice Catch. I've fixed it in the draft. > > > Out of band, the receiver of the payment, shares a bitcoin URI with the > > sender including a 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. > > > At first I thought this would be secure because the relay itself would need > to discover the key only to uncover privacy, but because of output > substitution it would actually open the protocol to a loss of funds attack: > If the ask-containing bip21 were discovered by the relay, then the relay > would have enough information to both find the buffer and forge a Payjoin > PSBT paying itself rather than the receiver, and the sender would send it > because output substitution is allowed. Even though I handle bip21s and > addresses as secret, I know many people post them in unencrypted channels and > so they should not be assumed secure to pass secrets. > > I have certainly considered the security trade offs of using a symmetric key > vs DH. The main reason I chose to use the symmetric psk over DH is because I > thought DH would require another round of communication to establish receiver > authentication, which is a huge inconvenience in an asynchronous setting. The > attack I’ve described can be mitigated inside the same message pattern by > having receiver share a public key of a per-request keypair Instead, > approximately following the NKpsk0 pattern, the sender may pass an ephemeral > secret session key under which the Payjoin PSBT response would be encrypted > and authenticated so no malicious adversary with knowledge of the bip21 would > be unable to read or forge. Stowaway uses BIP 47 codes for this purpose, but > I see no reason to tie buffer identity to the underlying wallet. Using > ephemeral keys also allows a single receiver to enroll multiple buffers at a > relay simultaneously. > > > About attack vectors: > > > > Since relays store arbitrary encrypted payloads to the tragedy of the > > commons and denial of service attacks. Relay operators may impose an > > authentication requirement before they provide relay service to receivers > > to mitigate such attacks. > > > > Isn't the most obvious concern with this architecture, that the relays have > > metadata - most obviously, they can time correlate messages, with bitcoin > > network events, so at the least they could tie transactions to clients. If > > both parties use anonymised network connections then this is ameliorated > > (though not removed) as a vector, but then we'd need to be clear that we > > require those (e.g. Tor). Not sure if it's palatable to do this if > > otherwise, i.e. if we think the relays can tie network addresses to > > transactions? Well, not sure, but I'd expect it to be mentioned? > > > The most obvious concern with this architecture is indeed that the relays > would have metadata that could be used for timing attacks correlating to a > Payjoin PSBT buffer being cleared
Re: [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ)
Hi waxwing thanks for the detailed response. You've identified a number of flaws both in the protocol and the document that can be fixed. I sincerely appreciate it. If more comes to mind, fire away. > I wanted to immediately "nit" a point I saw as I was reading: > >> Because BIP 78 messages are neither authenticated nor encrypted a malicious >> unsecured payjoin server is able to modify the Payjoin PSBT in flight, > > Taken as is - i.e. out of context! - this is just wrong. The BIP explicitly > states: > > "The sender must ensure that the url refers to a scheme or protocol using > authenticated encryption, for example TLS with certificate validation, or a > .onion link to a hidden service whose public key identifier has already been > communicated via a TLS connection. Senders SHOULD NOT accept a url > representing an unencrypted or unauthenticated connection. " Nice Catch. I've fixed it in the draft. > Out of band, the receiver of the payment, shares a bitcoin URI with the > sender including a 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. At first I thought this would be secure because the relay itself would need to discover the key only to uncover privacy, but because of output substitution it would actually open the protocol to a loss of funds attack: If the ask-containing bip21 were discovered by the relay, then the relay would have enough information to both find the buffer and forge a Payjoin PSBT paying itself rather than the receiver, and the sender would send it because output substitution is allowed. Even though I handle bip21s and addresses as secret, I know many people post them in unencrypted channels and so they should not be assumed secure to pass secrets. I have certainly considered the security trade offs of using a symmetric key vs DH. The main reason I chose to use the symmetric psk over DH is because I thought DH would require another round of communication to establish receiver authentication, which is a huge inconvenience in an asynchronous setting. The attack I’ve described can be mitigated inside the same message pattern by having receiver share a public key of a per-request keypair Instead, approximately following the NKpsk0 pattern, the sender may pass an ephemeral secret session key under which the Payjoin PSBT response would be encrypted and authenticated so no malicious adversary with knowledge of the bip21 would be unable to read or forge. Stowaway uses BIP 47 codes for this purpose, but I see no reason to tie buffer identity to the underlying wallet. Using ephemeral keys also allows a single receiver to enroll multiple buffers at a relay simultaneously. > About attack vectors: > > Since relays store arbitrary encrypted payloads to the tragedy of the commons > and denial of service attacks. Relay operators may impose an authentication > requirement before they provide relay service to receivers to mitigate such > attacks. > > Isn't the most obvious concern with this architecture, that the relays have > metadata - most obviously, they can time correlate messages, with bitcoin > network events, so at the least they could tie transactions to clients. *If* > both parties use anonymised network connections then this is ameliorated > (though not removed) as a vector, but then we'd need to be clear that we > *require* those (e.g. Tor). Not sure if it's palatable to do this if > otherwise, i.e. if we think the relays can tie network addresses to > transactions? Well, not sure, but I'd expect it to be mentioned? The most obvious concern with this architecture is indeed that the relays would have metadata that could be used for timing attacks correlating to a Payjoin PSBT buffer being cleared from the relay and a potential payjoin transaction being broadcast. If a sufficient number of steganographic transactions are broadcast per quantum, then requiring a sender to broadcast only after a random delay based on a poisson distribution could mitigate this problem somewhat. According to S. Ghesmati 2020 research, between 27% and 42% of all transactions conform to the type of unnecessary input heuristic that payjoins conform to (UIH2). So it wouldn’t take long for multiple steganographic candidates to enter the Mempool at any given time. I'm extremely reluctant to require Tor because it severely limits the number of environments where this proposal could be deployed. If we were to require Tor, we should then just ignore this proposal and focus on deploying hidden service based v1 receivers as in JoinMarket. I'm
Re: [bitcoin-dev] segwit naming ambiguity
On Fri, Aug 11, 2023 at 02:45:57PM +1000, Tobin Harding via bitcoin-dev wrote: > Question for OG bitcoin API designers please. > > If you were to see the following function > > `is_segwit()` > > would you assume it returns `true` or `false` for a p2tr transaction? > > > Currently we (rust-bitcoin) are being liberal with the use of `v0` but > its a pretty ugly. Is there an official, or widely used, name for segwit v0? > As others have said, I think `is_segwit` should match all segwit versions. Pavol also sorta answered your "widely used name" question though he didn't draw attention to it -- segwit v0 outputs are called "p2wsh" or "p2wpkh". But I don't know any term that covers "p2wsh or p2wpkh but not p2tr". Other than "segwit_v0", which we are currently using, and which I agree is a bit of a mouthful. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] segwit naming ambiguity
Here's my idea for a clean API: 1. `is_segwit()` returns true for a p2tr output 2. a function `segwit_version()` which returns an int according to segwit version used 3. helper functions like `is_p2wpkh()`, `is_p2tr()`, `is_p2wsh()` for all script types which all return a bool On Fri, 11 Aug 2023 at 08:41, Tobin Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Question for OG bitcoin API designers please. > > If you were to see the following function > > `is_segwit()` > > would you assume it returns `true` or `false` for a p2tr transaction? > > > Currently we (rust-bitcoin) are being liberal with the use of `v0` but > its a pretty ugly. Is there an official, or widely used, name for segwit > v0? > > > Thanks, > Tobin. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Best Regards / S pozdravom, Pavol "Stick" Rusnak Co-Founder, SatoshiLabs ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] segwit naming ambiguity
Hey Tobin, I would assume `is_segwit()` is true for P2TR, since Taproot is Segwit. I'm not aware of a different term for "is P2WPKH or P2WSH" that "is Segwit v0". Maybe look into Murch's BIP about wording? He could have a better name for Segwit v0 there. Cheers, Antoine --- Original Message --- On Friday, August 11th, 2023 at 6:45 AM, Tobin Harding via bitcoin-dev wrote: > Question for OG bitcoin API designers please. > > If you were to see the following function > > `is_segwit()` > > would you assume it returns `true` or `false` for a p2tr transaction? > > > Currently we (rust-bitcoin) are being liberal with the use of `v0` but > its a pretty ugly. Is there an official, or widely used, name for segwit v0? > > > Thanks, > Tobin. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] segwit naming ambiguity
Transactions should be considered segwit if they match the witness program structure of "A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 40 bytes" as defined in [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program). This would return true for version 0 segwit outputs as well as version 1 taproot outputs. I would propose a different function for differentiating v0 vs taproot scripts. Bitcoin core uses an [enum](https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.h#L51), of which you can use something similar. Core also uses a different [enum](https://github.com/bitcoin/bitcoin/blob/master/src/outputtype.h) for wallet logic, but it has a highly confusing naming scheme which imo should be avoided. Additionally, witness programs nested inside P2SH need to be considered. The context in which these are interpreted depends on whether or not they should be differentiated from other P2SH, as is shown with the 2 separate enums from core. It is possible that this would cause some ambiguity, and it should be explicitly documented how such functions would return for different types of programs. These nested programs should technically also be considered segwit for a simple `is_segwit`, as they have segregated witness data. v0 is the most common way of referring to version 0 segwit. Symphonic --- Original Message --- On Friday, August 11th, 2023 at 4:45 AM, Tobin Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: > Question for OG bitcoin API designers please. > > If you were to see the following function > > `is_segwit()` > > would you assume it returns `true` or `false` for a p2tr transaction? > > Currently we (rust-bitcoin) are being liberal with the use of `v0` but > its a pretty ugly. Is there an official, or widely used, name for segwit v0? > > Thanks, > Tobin. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] segwit naming ambiguity
Question for OG bitcoin API designers please. If you were to see the following function `is_segwit()` would you assume it returns `true` or `false` for a p2tr transaction? Currently we (rust-bitcoin) are being liberal with the use of `v0` but its a pretty ugly. Is there an official, or widely used, name for segwit v0? Thanks, Tobin. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
