Date: Sun, 20 Aug 2023 17:13:33 +0000
To: Dan Gould <d@ngould.dev>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <8qSa5NNuqF64Yg-R-OvO34IYBI0efPOUYYGrFBwvhsDuRMdQzcA6joTi0BNdBkoGgZQgBut257mfwX1e-bDdExlmcxdtRrSjCtWYPBlne6M=@protonmail.com>
In-Reply-To: <3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev>
References: <3C0A6E4C-444E-4E75-829C-1A21D8EE40E0@ngould.dev>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Serverless Payjoin
Precedence: list

Hi Dan,

May be too late to reply. Sorry.

Based on our last communication, I wanted to share these points after readi=
ng https://payjoin.substack.com/p/serverless-payjoin-gets-its-wings so that=
 other can also evaluate them:

1) I don't think NIP 4 has any security issues. Maybe privacy issues. Its j=
ust metadata leak which should be okay if a new npub is used every time use=
rs do payjoin. Message itself will remain secret because it's encrypted.
2) Backwards compatibility due to npub, relay etc. shared in payjoin URI as=
 implemented by Kukks. Not sure how to fix this.
3) Relays have no incentive to anything malicious if multiple relays are us=
ed. Although I am still not clear what malicious activity can they do with =
encrypted messages.
4) IP address is an issues with lot of projects and this can be managed by =
users or wallet implementation with the use of RiseupVPN, Tor, i2p etc.
5) Random padding suggested by a few senior devs makes sense.

/dev/fd0

floppy disk guy

------- Original Message -------
On Monday, January 23rd, 2023 at 2:20 AM, Dan Gould via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:


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