Re: [bitcoin-dev] postr: p2n payjoin using nostr
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/144bytes/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 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
> 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 spends, ala https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 . It's much easier to think about one-off replacements from an anti-DoS perspective. We would have to think a lot harder if that actually solves the problem and maintains the prospective use-cases before diving into analysis, regardless. Cheers, Greg On Sat, Jun 10, 2023 at 5:02 AM Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Antoine, > > On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard > wrote: > >> From a taproot annex design perspective, I think this could be very >> valuable if you have a list of unstructured data use-cases you're thinking >> about ? >> > > The annex's list of unstructured data use-cases includes existing data > storage uses that utilize OP_RETURN or inscriptions. Consider ordinals, > timestamps, and any other data already stored on the chain. These > applications would immediately benefit from the annex's improved space > efficiency. > > 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 ideally > use covenants. > > The most critical application in this category, for me, involves > time-locked vaults. Given the positive reception to proposals such as > OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably > a bit further out, but pre-signed transactions signed using an ephemeral > key can fill the gap and improve the safeguarding of Bitcoin in the short > term. > > Backing up the ephemeral signatures of the pre-signed transactions on the > blockchain itself is an excellent way to ensure that the vault can always > be 'opened'. However, without the annex, this is not as safe as it could > be. Due to the described circular reference problem, the vault creation and > signature backup can't be executed in one atomic operation. For example, > you can store the backup in a child commit/reveal transaction set, but the > vault itself can be confirmed independently and the backup may never > confirm. If you create a vault and lose the ephemeral signatures, the funds > will be lost. > > This use case for the annex has been labeled 'speculative' elsewhere. To > me, every use case appears speculative at this point because the annex > isn't available. However, if you believe that time-locked vaults are > important for Bitcoin and also acknowledge that soft forks, such as the one > required for OP_VAULT, aren't easy to implement, I'd argue that the > intermediate solution described above is very relevant. > > >> As raised on the BIP proposal, those unstructured data use-cases could >> use annex tags with the benefit to combine multiple "types" of unstructured >> data in a single annex payload. As you're raising smaller bits of >> unstructured data might not afford the overhead though my answer with this >> observation would be to move this traffic towards some L2 systems ? In my >> mind, the default of adding a version byte for the usage of unstructured >> data comes with the downside of having future consensus enabled use-cases >> encumbering by the extended witness economic cost. >> > > When it comes to the trade-offs associated with various encodings, I fully > acknowledge their existence. The primary motivation behind my proposal to > adopt a simple approach to the Taproot annex is to avoid a potentially long > standardization process. While I am not entirely familiar with the > decision-making process of Bitcoin Core, my experience with other projects > suggests that simpler changes often encounter less resistance and can be > implemented more swiftly. Perhaps I am being overly cautious here, though. > > >> About the annex payload extension attack described by Greg. If my >> understanding of this transaction-relay jamming griefing issue is correct, >> we can have an annex tag in the future where the signer is committing to >> the total weight of the transaction, or even the max per-input annex size ? >> This should prevent a coinjoin or aggregated commitment transaction >> counterparty to inflate its annex space to downgrade the overall >> transaction feerate, I guess. And I think this could benefit unstructured >> data use-cases too. >> > > 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? > > Joost > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html > [2]
Re: [bitcoin-dev] Bitcoin mail list needs an explicit moderation policy
> 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 if you create a new one. It is hard to start new topics properly, it is not a forum, a lot of effort is needed to create some new discussion, and pass through all moderation filters. However, if you reply to some existing post, then it is all about quotes and replies, there are less requirements. In the past, I tried writing two very similar replies, just with a different title, and guess what: the one with "re" was published, but the one with the new title was rejected. The reason is that people filter messages by title, and some of them read only some topics, so if you bring a new one, then they can get angry, if they are not interested in it. However, if you start from existing topic, and you gradually move the discussion into something else, then the title will be finally changed by some moderator into "Topic Y (was: topic X)", and that approach is much easier than starting from "Topic Y" explicitly. The main reason for such moderation is this: if you reply for some topic, then there are rules for the quality of your reply, and nothing else. But if you start a new topic, then there are more sieves: not only your content has to meet some criteria, but also bringing that new particular topic has to be justified. So, rejecting replies is about "your content is spam", but rejecting new topic is about "talking about this is spam, no matter of the content". On 2023-06-03 01:48:45 user Dr Maxim Orlovsky via bitcoin-dev wrote: Dear community, I am writing this list to bitcoin-dev mail list, but to prevent potential censorship I am sending CC to lightning-dev mail list, in order to leave the current moderator(s) without an option not to publish the letter and not to leave the topic “under the cover” (sorry Lightning friends for spamming your list with this off-topic). A day before yesterday I sent a post to bitcoin-dev referencing the publication of the new Bitcoin scalability and privacy protocol, which had already received a broad reaction across the bitcoin community with literally no critical/negative responses after ~25k of reads [1]. I am not the first-time writer to the mail list and had developed things like RGB smart contracts [2], rust lightning implementation named LNP [3], multiple bitcoin libraries and software [4], [5], during three years was a main contributor to rust-bitcoin [6] etc, etc. The post was clearly not spam and received support from known community members like Giacomo Zucco [7]. Bryan Bishop knows me since 2019 when I was presenting Storm protocol on the stage on Scaling Bitcoin in Tel Aviv - and he was writing a transcript of it [8]. Thus, I am not a random unknown guy or a known spammer - and the post can be easily checked for not containing any scam promotion. Nevertheless, I next day I see other e-mails getting released to bitcoin-dev, while mine - was not. It is not a problem, but since we already had an incident in the past where Bryan reported the failure of his software, me and my colleagues from LNP/BP Standards Association started asking questions about whether this post ever got to Bryan. What happened next was very unexpected. I am giving the core of the conversation over Twitter after in Annex A - with the purpose to showcase the problem I’d like to address in this e-mail. From the discussion, it is clear that bitcoin-dev mail list lacks clear explicit moderation (or peer-review) policies, which must be applied on a non-selective basis. Also, Bryan Bishop, as the current moderator, had abused his powers in achieving his agenda based on personal likes or dislikes. The conversation went nowhere, and the post got published only after a requirement from Peter Todd [9]. In this regard, I’d like to propose the following: The bitcoin-dev mail list must have a clear moderation (or pre-publication peer-review policy). It can be proposed and discussed in this mail list and, upon agreement, must become public and obligatory. Bryan Bishop, who was acting for a long time as moderator, must be appreciated for many years of unpaid work, and replaced with the new moderator who should be selected from a list of potential candidates (again in this mail list) using the criteria “least votes against”. The role of the moderator(s) must be purely executive of the policies, without any personal preferences. A dedicated mail list should be created (“bitcoin-dev-unmoderated”) which will publish all submissions without moderation. It may contain spam and only people interested in the auditing bitcoin-dev main mal list non-censorship will be reading it. However, if they will notice that some non-spam e-mails were censored,
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
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 ideally use covenants. I share the observation that the annex data not being committed in the parent txid is very powerful for use-cases that would use covenants. E.g there could be an alternative design of CoinPool based on Grafroot, where the signed surrogate scripts authorized withdrawal abilities [0]. Once consumed the signed surrogate shouldn't be replayable against the clawback pool output, and the signature of the surrogate added as "toxic" in a cryptographic accumulator. Efficient set test membership can be realized to refuse pool output spend attempts with consumed surrogate scripts. The annex is a perfect emplacement to locate such an accumulator in the future as the state of the accumulator cannot be predicted as pool setup time and is a function of the effective order withdrawal. Note with Taproot-based design, the replay protection is achieved by the removal from the taproot tree as edited by any contracting primitive during the withdrawal phase (e.g TLUV). > When it comes to the trade-offs associated with various encodings, I fully acknowledge their existence. The primary motivation behind my proposal to adopt a simple approach to the Taproot annex is to > avoid a potentially long standardization process. While I am not entirely familiar with the decision-making process of Bitcoin Core, my experience with other projects suggests that simpler changes often > encounter less resistance and can be implemented more swiftly. Perhaps I am being overly cautious here, though. I fully understand the motivation to avoid a lengthy standardization process, which can be a source of frustration for everyone, including the standard champions themselves. Indeed, no one lacks the bureaucratic-style of standardization process for their own sake. Long standardization processes in Bitcoin consensus are better explained by the number of technical dimensions to weigh in terms of designs (e.g full-nodes ressources scalability, fee economic costs, confidentiality, composability with other changes). And due to the asynchronous nature of FOSS development, every domain expert is constantly jungling between different engineering contributions priorities (e.g for myself currently package relay and mempool for L2s). All that said, to make the conversation of annex standardization more practical, and aiming to compose with all technical interest expressed, I can think about a 2 phase process, at least. Such standardization process reflects only my opinion, and is based on the experience of recent mempool fullrbf partial deployment experience, the Core's trends to have tracking issues for substantial changes, bitcoin-inquisition and the bitcoin contracting primitives WG experiences. Phase 1: - a BIP proposal for the TLV records + code (almost done with #9 in bitcoin-inquisition and #1421 in the bips repository) - a BIP proposal to reserve "tag 0" for unstructured data + code (let's say in bitcoin-inquisition) - anti-DoS mempool/transaction-relay/replacement code (same) - bonus point: documenting the new mempool/replacement rules like in Core's `doc/policy` - preferential peering logic working code (there is already some code with Core's #25600) - opt-in activation of the annex validation rules - engage Bitcoin devs appreciated by the community as domain experts in the covered areas to collect more relevant technical feedbacks Phase 2: - submit the annex branch with all the features on the Bitcoin Core repository - communicate to the Bitcoin technical community at large the existence of the proposal e.g dev mail list, technical newsletters - communicate to the second-layers and unstructured data application maintainers the existence of the proposal - integrate the feedback from Bitcoin Core, Bitcoin users and second-layers communities in a "staging code branch" - if there is a deep technical objection, go back to phase 1 (e.g a competing serializing proposal for the annex) - otherwise, split the annex reference branch core in logical chunks for optimal review process This is what an efficient-yet-decentralized standardization process of the annex would look like to me, I don't know. About when we can expect a deployment of new policy rules for the annex, as Dave made me the (grounded) reprimand on the list a while back, I don't think mentioning a date or software version release is appropriate. And this to avoid creating a sense of commitment on all the contributors involved in the projects above mentioned. I'm still interested in championing the "base" TLV serialization annex code and BIP. To move faster, I think it would be better to have another champion on the "tag 0" and BIP, especially as the unstructured data
