From: "David A. Harding" <dave@dtrt•org>
To: AdamISZ <AdamISZ@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP for Serverless Payjoin
Date: Sat, 12 Aug 2023 20:58:29 -1000 [thread overview]
Message-ID: <9E89DE36-4CB4-4F16-A702-FE33EDF544C3@dtrt.org> (raw)
In-Reply-To: <qUoIvwrIl8ltj3TkQ7y1ExhjUan6VEpGl7c7TlHNfF1pT-eZWd_mwuNYH13YPRyvMj9OSApLmW-hwrdaHCEapEXr503SlXSywcAGceXcbow=@protonmail.com>
On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>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.
Hi Dan,
After reading Adam's comments above and re-reading your draft BIP where it says the secret key is also used as the session identifier and that outputs can be modified, I'm wondering about the security of posting payment URIs anywhere someone can see them.
For example, if Alice posts her BIP21 URI for Bob to pay where Eve can see it, such as in a shared chatroom or via email or any cleartext protocol that gets relayed, can Eve establish her own session to the relay and frontrun Alice on receiving Bob's PSBT, modify the returned PSBT to include her (Eve's) output, and submit it for Bob to sign and broadcast?
The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, posting them where evesdroppers can see them poses a privacy risk but not a risk of loss of funds, so many users don't treat them as especially hazardous material. I don't think it would be practical to change that expectation, and I think a protocol where evesdropping didn't create a risk of funds loss would be much better than one where that risk was created.
(Apologies to Adam is this is exactly what he was saying with more subtly.)
-Dave
next prev parent reply other threads:[~2023-08-13 7:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 17:32 Dan Gould
[not found] ` <PnynUg0ga-9fQ_4qVhy3ZwuJCk6eeK8Ie3NQi6xiCtfbQSveE7ieLDNtq59nNAwLVmPkpaARfIVUXghzvc0ySlF9z_cFLh01JRTz3AzUMww=@protonmail.com>
2023-08-10 14:57 ` [bitcoin-dev] Fw: " AdamISZ
2023-08-10 15:37 ` [bitcoin-dev] " AdamISZ
2023-08-10 15:46 ` AdamISZ
2023-08-13 6:58 ` David A. Harding [this message]
[not found] <mailman.130337.1691684480.956.bitcoin-dev@lists.linuxfoundation.org>
2023-08-11 17:03 ` [bitcoin-dev] BIP for Serverless Payjoin (AdamISZ) Dan Gould
2023-08-11 22:04 ` symphonicbtc
2023-08-12 1:05 ` Christopher Allen
2023-08-12 21:20 ` [bitcoin-dev] BIP for Serverless Payjoin Dan Gould
2023-08-13 9:22 ` Christopher Allen
[not found] <mailman.5.1691928003.16386.bitcoin-dev@lists.linuxfoundation.org>
2023-08-13 12:50 ` Dan Gould
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9E89DE36-4CB4-4F16-A702-FE33EDF544C3@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=AdamISZ@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox