-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serverless PayJoin PoC (HTTP Long Polling) #21
Conversation
594a921
to
ff8b189
Compare
This PoC went through a couple of iterations, passing TURN and even magic-wormhole before settling on an http-only long-polling client let payjoins be relayed anywhere http is supported. This removes the need for any additional networking library. This example follows https://httprelay.io/features/proxy/ The goal is to give serverless payjoin the greatest chance of actually being adopted. Removing noise might be worthwhile too if we find another simple way to authenticate receiver requests. While we may lose some forward-secrecy protections, the chance that one key gets compromised and not the other seems slim. Even with a single symmetric per-bip21 key, that's just like a per-session TLS key. Encrypt-then-mac with a sha256 hmac construction seems secure enough to me. BIP322 auth on the bip21 address would be more slick, but I think it's too early. |
ff8b189
to
90ea09a
Compare
this way neither sender nor receiver have to operate a public endpoint secured by a certificate authority
See the bitcoin-dev writeup https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021364.html
This PoC is much longer than the others because it adds source for NNpsk0 Noise protocol