alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-12 🗒️ Summary of this message: The email ...
📅 Original date posted:2023-06-12
🗒️ Summary of this message: The email discusses a proof of concept for using nostr npub and relays for payjoin, but there are concerns about the use of SIGHASH_NONE and security issues.
📝 Original message:
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 to do whatever they want with your funds (which I see you acknowledge in your brief description, but still, not very practical).
SIGHASH_NONE can be used when there is no change in the transaction and sender 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 transaction to extract the sender'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.
- 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 have 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 experiments 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/change 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 spend 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 at proton.me> wrote:
> Hey alicexbt,
> I'm a bit confused as to what exactly this is a proof of concept for. Your 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 brief description, but still, not very practical). However, it is also possible for anyone who sees the final broadcasted transaction to extract the sender'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.
>
> 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.
>
> Moreover, a bit redundantly considering the glaring and severe security issues, this is not a proper implemenation of a payjoin, even in a theoretical scenario, as it is trivial to discern which inputs belong to the sender and reciever respectively in the final transaction.
>
> Symphonic
>
>
> Sent with Proton Mail secure email.
🗒️ Summary of this message: The email discusses a proof of concept for using nostr npub and relays for payjoin, but there are concerns about the use of SIGHASH_NONE and security issues.
📝 Original message:
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 to do whatever they want with your funds (which I see you acknowledge in your brief description, but still, not very practical).
SIGHASH_NONE can be used when there is no change in the transaction and sender 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 transaction to extract the sender'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.
- 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 have 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 experiments 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/change 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 spend 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 at proton.me> wrote:
> Hey alicexbt,
> I'm a bit confused as to what exactly this is a proof of concept for. Your 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 brief description, but still, not very practical). However, it is also possible for anyone who sees the final broadcasted transaction to extract the sender'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.
>
> 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.
>
> Moreover, a bit redundantly considering the glaring and severe security issues, this is not a proper implemenation of a payjoin, even in a theoretical scenario, as it is trivial to discern which inputs belong to the sender and reciever respectively in the final transaction.
>
> Symphonic
>
>
> Sent with Proton Mail secure email.