Published on: 2023-08-20T17:13:33+00:00
In a recent communication, Dan shared some points after reading an article titled "Serverless Payjoin Gets Its Wings" by Kukks. Firstly, there is a mention of NIP 4, which seems to have no security issues but potential privacy concerns due to metadata leakage. However, using a new npub each time users engage in payjoin can address this issue, as the message itself remains encrypted. Secondly, there is a discussion about backwards compatibility related to npub and relay information shared in payjoin URIs. The email mentions that fixing this issue is uncertain. Regarding relays, it is stated that if multiple relays are used, there is no incentive for them to engage in malicious activities. However, the exact nature of potential malicious activities with encrypted messages is not clearly understood. Additionally, IP addresses are identified as an issue in many projects, but this can be managed by users or wallet implementations through the use of RiseupVPN, Tor, i2p, etc. Finally, the suggestion of adding random padding, proposed by some senior developers, is considered sensible.Dan Gould has published an upgrade for payjoin that allows the receiver to receive bitcoin transfers without running a public server. This new scheme utilizes a TURN relay for connectivity and symmetric cryptography for security. The recipient requests the relay to allocate them an endpoint for UDP communication. They then share a BIP 21 payjoin URI containing the allocated endpoint and a generated 256-bit key called psk. The sender constructs their request using the original PSBT format from BIP 78, and they utilize the NNpsk0 pattern for noise framework instead of TLS or Tor. The resulting ciphertext ensures message secrecy and integrity when relayed to the recipient through the endpoint.However, this work highlights a larger issue with payjoin, which assumes synchronous communication in an asynchronous world. It is mentioned that a relay could hold a request for an offline payjoin peer until that peer comes online. Yet, the BIP 78 spec recommends broadcasting request PSBTs in the case of an offline counterparty, which exposes a naive and surveillance-vulnerable transaction that payjoin aims to avoid. Further research is needed before recommending such a protocol.Since TURN relays can handle various internet traffic, they are susceptible to the tragedy of the commons. Relay operators might impose authentication requirements for endpoint allocation provisions. While peers only see the IP address of the TURN relay, not their peer's, it is suggested that TURN relays could also be made available via Tor hidden service to allow either peer to protect their IP with Tor without forcing the other to use it too.Dan Gould has provided proof-of-concept sender, receiver clients, and relay code in Rust, which can be found on GitHub for more details and improved formatting.
Updated on: 2023-08-21T01:52:45.170913+00:00