Re: [bitcoin-dev] postr: p2n payjoin using nostr

2023-06-12 Thread alicexbt via bitcoin-dev
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 ack

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

2023-06-12 Thread Greg Sanders via bitcoin-dev
> Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution? The only plausible case I could see moving forward is replacing the transaction to a form that has *no* annex or scriptpath

Re: [bitcoin-dev] Bitcoin mail list needs an explicit moderation policy

2023-06-12 Thread vjudeu via bitcoin-dev
> Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, > while mine - was not. If you created a new topic, then that is the reason. I noticed an interesting thing: if the title of your post is just a reply to some existing topic, then there are less strict rules, than i

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

2023-06-12 Thread Antoine Riard via bitcoin-dev
Hi Joost, > However, the primary advantage I see in the annex is that its data isn't included in the calculation of the txid or a potential parent commit transaction's txid (for inscriptions). I've explained this at [1]. This > feature makes the annex a powerful tool for applications that would id