Re: [bitcoin-dev] BIP for Serverless Payjoin

[Dan Gould via bitcoin-dev]

Thanks for weighing in Dave,

> On Aug 13, 2023, at 8:00 AM, bitcoin-dev-requ...@lists.linuxfoundation.org 
> wrote:
> 
> 

> The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, 
> posting them where evesdroppers can see
> 
> …
> 
> 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.
> 
> d...@dtrt.org

The BIP has changed to adopt a DH cryptosystem where the receiver only shares a 
public key in the BIP 21 as part of the pj= endpoint since Adam posted 
comments. I agree enabling the simplest asynchronous experience while, as I 
gather you’re thinking, keeping the UX expectation that leaked BIP 21 URIs pose 
no risk for loss of funds is the right set of tradeoffs.

Dan


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for Serverless Payjoin

[Christopher Allen via bitcoin-dev]

On Sat, Aug 12, 2023 at 2:20 PM Dan Gould  wrote:

>  am somewhat concerned that some payjoin implementations are written in
> JavaScript and would benefit most from a v2 upgrade in order to support
> receiving, but no JavaScript ur library exists yet. Perhaps one could be
> bound from the rust implementation.
>

There is some progress here, including our reference library in Typescript
for dCBOR and UR-based Envelope, but hopefully we will expand soon to offer
it in reference libraries, though some will have to be wasm of our rust
code.

I've heard that there are some wallets using URs written Javascript, but
they have not announced open source libraries yet.

-- Christopher Allem
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for Serverless Payjoin

[David A. Harding via bitcoin-dev]

On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev 
 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 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.

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev