Date: Mon, 12 Jun 2023 19:28:47 +0000
To: symphonicbtc <symphonicbtc@proton.me>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <EQsyuwTpcGBPNNTpCdDzZr4mWC99WoNQLxt5_vSpBCVUZ-dfbGJOrAUh4aLZ7LBkDjpRtEsPTi11xCn4NfY4z18ljbrbsx6GIUgJaK_APxI=@protonmail.com>
In-Reply-To: <5q2errITNASjAVbki97N00q-GQvQHR_9jJ0dppnEW1dcPGYQ9C71abKzcP0z7wit_wbXsRGpNstCPM26pkQmn1aFwfL475A93gaK6uPSt6c=@proton.me>
References: <5q2errITNASjAVbki97N00q-GQvQHR_9jJ0dppnEW1dcPGYQ9C71abKzcP0z7wit_wbXsRGpNstCPM26pkQmn1aFwfL475A93gaK6uPSt6c=@proton.me>
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"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] postr: p2n payjoin using nostr
Precedence: list

Hi Symphonic,

> I'm a bit confused as to what exactly this is a proof of concept for.

This is a proof of concept for using nostr npub and relays for payjoin.

> Your use of SIGHASH_NONE does in fact make it possible for the reciever t=
o do whatever they want with your funds (which I see you acknowledge in you=
r brief description, but still, not very practical).

SIGHASH_NONE can be used when there is no change in the transaction and sen=
der wants to spend whole UTXO for the payment. Recipient is free to decide =
the outputs and extra input for the transaction.

> However, it is also possible for anyone who sees the final broadcasted tr=
ansaction to extract the sender's input and use it for any purpose they wis=
h; game theoretically miners would just steal your funds, but it's possible=
 for any user to RBF and send those funds wherever they like.

- Based on my understanding of SIGHASH flags and a [blog post][0] by Raghav=
 Sood, use of SIGHASH_ALL by recipient will secure all outputs. However I h=
ave realized it is still vulnerable in a [tweet thread][1] as you mentioned=
. While writing this email, poll was still 50-50 so I guess its a learning =
thing. We have less docs about SIGHASH flags, maybe an e-book with all expe=
riments would improve this.
- Since this was just a PoC to use nostr, use of specific SIGHASH flags can=
 be ignored and developers can use other flags or default. I will improve/c=
hange it as well. I wanted to use SIGHASH_NONE to improve privacy and less =
UX issues.
- There are no incentives for sender or recipient to use RBF and double spe=
nd in a payjoin transaction.

[0]: https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash
[1]: https://twitter.com/1440000bytes/status/1668261886884708352

/dev/fd0
flopyy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, June 11th, 2023 at 8:02 AM, symphonicbtc <symphonicbtc@proton.me=
> wrote:


> Hey alicexbt,
> I'm a bit confused as to what exactly this is a proof of concept for. You=
r use of SIGHASH_NONE does in fact make it possible for the reciever to do =
whatever they want with your funds (which I see you acknowledge in your bri=
ef description, but still, not very practical). However, it is also possibl=
e for anyone who sees the final broadcasted transaction to extract the send=
er's input and use it for any purpose they wish; game theoretically miners =
would just steal your funds, but it's possible for any user to RBF and send=
 those funds wherever they like.
>=20
> As is the case with any work-in-progress software, but especially in this=
 instance, I urge you to disable the ability to use mainnet coins directly =
in your code. This is highly irresponsible to post in this state.
>=20
> Moreover, a bit redundantly considering the glaring and severe security i=
ssues, this is not a proper implemenation of a payjoin, even in a theoretic=
al scenario, as it is trivial to discern which inputs belong to the sender =
and reciever respectively in the final transaction.
>=20
> Symphonic
>=20
>=20
> Sent with Proton Mail secure email.