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