Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Sat, Jun 3, 2023 at 9:49 AM Joost Jager wrote: > The removal of the need for a commitment transaction also enables the > inclusion of data within a single transaction that relies on its own > transaction identifier (txid). This is possible because the txid > calculation does not incorporate the annex, where the data would be housed. > This feature can be beneficial in scenarios that require the emulation of > covenants through the use of presigned transactions involving an ephemeral > signer. > I think this avoidance of a circular reference is also why LN-Symmetry uses the annex? Joost ___ 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
HI Greg, On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders wrote: > Attempting to summarize the linked PR: > > I think the biggest remaining issue to this kind of idea, which is why I > didn't propose it for mainnet, > is the fact that BIP341/342 signature hashes do not cover *other* inputs' > annex fields, which we > briefly discussed here > https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264 > . > > This means that in a coinjoin like scenario, even if the other joining > parties prove they don't have any > crazy script paths, a malicious party can make the signed transaction into > a maximum sized transaction > package, causing griefing. The mitigation in the PR I linked was to limit > it to 126 bytes, basically punting > on the problem by making the grief vector small. Another solution could be > to make annex usage "opt-in" > by requiring all inputs to commit to an annex to be relay-standard. In > this case, you've opted into a possible > vector, but at least current usage patterns wouldn't be unduly affected. > For those who opt-in, perhaps the first > order of business would be to have a field that limits the total > transaction weight, by policy only? > > Some logs related to that here: > https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb > > Related discussion on possible BIP118 modifications to mitigate this in > tapscript-spending circumstances: > https://github.com/bitcoin-inquisition/bitcoin/issues/19 > While solutions such as making annex usage opt-in or imposing size limitations may initially appear effective, they may also inadvertently foster a false sense of security, as they lack alignment with economic incentives. Relying solely on policy enforcement merely transfers responsibility to the miners, without necessarily aligning their incentives with the broader network health. This situation is reminiscent of the challenges encountered with opt-in rbf. Despite signaling for non-replaceability, miners began accepting replacements probably due to the enticing higher fee incentives. At least that's how I picked up this development. Businesses that relied on zero-confirmation payments were unexpectedly affected, leading to undesirable outcomes. While we can define policy rules, miners will ultimately operate in a manner that maximizes their profits. Consequently, if a miner identifies an opportunity to bolster their fees by replacing an annex transaction, they're likely to seize it, regardless of any policy rules. This might not be readily apparent currently with a limited number of pools dominating block production, but it is my hope that mining will be more decentralized in the future. Depending on policy to mitigate this annex malleability vector could mislead developers into believing their transactions are immune to replacement, when in fact they might not be. This potential misalignment could result in developers and businesses constructing systems based on assumptions that could be compromised in the future, mirroring the situation that unfolded with zero-confirmation payments and rbf. It may thus be more prudent to permit the utilization of the annex without restrictions, inform developers of its inherent risks, and acknowledge that Bitcoin, in its present state, might not be ideally suited for certain types of applications? Joost ___ 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
Hi David, On Sat, Jun 3, 2023 at 3:08 AM David A. Harding wrote: > Out of curiosity, what features and benefits are available today? I > know Greg Sanders wants to use annex data with LN-Symmetry[1], but > that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you > mention that it could allow putting arbitrary data into a witness > without having to commit to that data beforehand, but that would only > increase the efficiency of witness stuffing like ordinal inscriptions by > only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be > required to create an output in order to spend it. > Indeed, there's a minor efficiency gain in the reveal transaction witness, but I think the real advantage is that it eliminates the need to publish and pay for the commit transaction in the first place. Any spend of a taproot UTXO can be supplemented with arbitrary data in just a single transaction. > Is there some other way to use the annex today that would be beneficial > to users of Bitcoin? The removal of the need for a commitment transaction also enables the inclusion of data within a single transaction that relies on its own transaction identifier (txid). This is possible because the txid calculation does not incorporate the annex, where the data would be housed. This feature can be beneficial in scenarios that require the emulation of covenants through the use of presigned transactions involving an ephemeral signer. For instance, one can establish a time-locked vault using 2-of-2 multisig presigned transactions in which one of the signers is ephemeral [1]. After signing, the private key is discarded, leaving only the signature. To ensure the signature is never lost, it can be stored as a backup in the annex of the transaction that the presigned transaction spends. Such an operation would not be possible with a commit/reveal inscription. [1] https://github.com/LedgerHQ/app-bitcoin-new/issues/153 ___ 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
> I think this avoidance of a circular reference is also why LN-Symmetry uses the annex? The annex trick specifically is used to force the publication of the missing piece of the control block corresponding to the new taproot output. This is to maintain the node's O(1) state while also keeping 0.5RTT channel updates. Could have also been done with a dangling OP_RETURN, with the associated restrictions on which sighashes you can use since you now have to commit to multiple outputs(disallows SIGHASH_SINGLE). There's also a fair exchange protocol that obviates the need for it using signature adapters, but the requisite APIs don't exist yet, and doesn't lend itself naturally to 3+ party scenarios. > Depending on policy to mitigate this annex malleability vector could mislead developers into believing their transactions are immune to replacement, when in fact they might not be. The issue I'm talking about is where someone's transaction is denied entry into the mempool entirely because a counter-party decided to put in a strictly worse transaction for miners by bloating the weight of it, not adding fees. A strictly worse "API" for paying miners for no gain seems like a bad trade to me, especially when there are reasonable methods for mitigating this. > It may thus be more prudent to permit the utilization of the annex without restrictions, inform developers of its inherent risks, and acknowledge that Bitcoin, in its present state, might not be ideally suited for certain types of applications? Mempool policy should be an attempt to bridge the gap between node anti-DoS and an entity's ability to pay miners more via feerate-ordered queue. I don't think the answer to this problem is to zero out all ability to limit the sizes of multi-party, multi-input transactions for speculative use cases. Greg On Sat, Jun 3, 2023 at 7:31 AM Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Jun 3, 2023 at 9:49 AM Joost Jager wrote: > >> The removal of the need for a commitment transaction also enables the >> inclusion of data within a single transaction that relies on its own >> transaction identifier (txid). This is possible because the txid >> calculation does not incorporate the annex, where the data would be housed. >> This feature can be beneficial in scenarios that require the emulation of >> covenants through the use of presigned transactions involving an ephemeral >> signer. >> > > I think this avoidance of a circular reference is also why LN-Symmetry > uses the annex? > > Joost > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ 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
No in this case the txid is identical. Only the wtxid is malleated, with annex data stuffed to max transaction size. Cheers, Greg On Sat, Jun 3, 2023, 8:36 AM Joost Jager wrote: > > Depending on policy to mitigate this annex malleability vector could >> mislead developers into believing their transactions are immune to >> replacement, when in fact they might not be. >> >> The issue I'm talking about is where someone's transaction is denied >> entry into the mempool entirely because a counter-party decided to put in a >> strictly worse transaction for miners by bloating the weight of it, not >> adding fees. A strictly worse "API" for paying miners for no gain seems >> like a bad trade to me, especially when there are reasonable methods for >> mitigating this. >> > > Just to expand this, an example would be a transaction with inputs A' and > B' signed by two parties A and B. A has a fully signed transaction in > hands, but can't publish it because B created and published an alternative > version of it with a large annex for input B'. Wouldn't miners just accept > A's version because it's fee rate is higher? I am looking at this case > assuming the user has a direct connection to a miner, ignoring any > potential concerns related to p2p transport. > > Joost > ___ 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
> > > Depending on policy to mitigate this annex malleability vector could > mislead developers into believing their transactions are immune to > replacement, when in fact they might not be. > > The issue I'm talking about is where someone's transaction is denied entry > into the mempool entirely because a counter-party decided to put in a > strictly worse transaction for miners by bloating the weight of it, not > adding fees. A strictly worse "API" for paying miners for no gain seems > like a bad trade to me, especially when there are reasonable methods for > mitigating this. > Just to expand this, an example would be a transaction with inputs A' and B' signed by two parties A and B. A has a fully signed transaction in hands, but can't publish it because B created and published an alternative version of it with a large annex for input B'. Wouldn't miners just accept A's version because it's fee rate is higher? I am looking at this case assuming the user has a direct connection to a miner, ignoring any potential concerns related to p2p transport. Joost ___ 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
On Sat, Jun 3, 2023 at 2:43 PM Greg Sanders wrote: > No in this case the txid is identical. Only the wtxid is malleated, with > annex data stuffed to max transaction size. > This doesn't sound incentive compatible? While gathering context, I did find https://github.com/bitcoin/bitcoin/pull/24007. Apparently closed because of a lack of use case. But perhaps the desire to not limit the annex can revive that proposal? Joost > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
> The white paper describing the proposal can be found here: > https://github.com/LNP-BP/layer1/ Some questions about the Bitcoin PoW anchoring: What if a miner spends the current miner single-use-seal while creating a commitment, but makes the PMT only partially available, or entirely unavailable ? How do other miners reach consensus on whether a protocol reset is required? It seems impossible to agree on something like PMT availability (much like mempool contents). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
Hi John,
Thank you for the question. We have discussed this case in the paper, second
paragraph of the “Bitcoin PoW Anchoring” Section:
> If a party spends current miner single-use-seal without creating a commitment
> - or committing to a header without sufficient PoW, such closing is
> considered invalid; in this case, any party is allowed to create a special
> bitcoin transaction providing publically-identifiableOP_RETURNinformation
> ("announcement") about a new miner single-use-seal (protocol reset); only the
> firstOP_RETURNannouncement which is closed with a proper procedure is
> considered valid under the consensus rules.
Kind regards,
Maxim Orlovsky
On Sat, Jun 3, 2023 at 4:30 PM, John Tromp via bitcoin-dev
<[bitcoin-dev@lists.linuxfoundation.org](mailto:On Sat, Jun 3, 2023 at 4:30 PM,
John Tromp via bitcoin-dev < wrote:
>> The white paper describing the proposal can be found here:
>> https://github.com/LNP-BP/layer1/
>
> Some questions about the Bitcoin PoW anchoring:
>
> What if a miner spends the current miner single-use-seal while
> creating a commitment, but makes the PMT only partially available, or
> entirely unavailable ?
>
> How do other miners reach consensus on whether a protocol reset is
> required? It seems impossible to agree on something like PMT
> availability (much like mempool contents).
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin mail list needs an explicit moderation policy
Hi Maxim, > In this regard, I’d like to propose the following: > > 1. 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. > 2. 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”. > 3. The role of the moderator(s) must be purely executive of the policies, > without any personal preferences. > 4. 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, they can announce that publicly. In this case, the failing > moderator(s) should be removed and replaced. > 5. The incentive to work as a moderator should be reputation-based. - I doubt moderation policy would change anything as it could be interpreted differently by everyone and misused. We have seen this in [BIPs repository][0] recently. - We should change moderators regularly since everyone has their bias and mailing list is important part of discussions related to bitcoin development. - Unmoderated mailing list front end could be created using all the emails from archives and moderated section. Moderated emails have attachments that would need some [EML parser][1]. I don't even know who are the present moderators or people with access to moderation queue. There should be some transparency about it. [0]: https://github.com/bitcoin/bips/pull/1408 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020213.html /dev/fd0 floppy disk guy Sent with Proton Mail secure email. --- Original Message --- On Saturday, June 3rd, 2023 at 5:13 AM, 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: > > 1. 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. > 2. 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
Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote: > Depending on policy to mitigate this annex malleability vector could > mislead developers into believing their transactions are immune to > replacement, when in fact they might not be. This potential misalignment > could result in developers and businesses constructing systems based on > assumptions that could be compromised in the future, mirroring the > situation that unfolded with zero-confirmation payments and rbf. > > It may thus be more prudent to permit the utilization of the annex without > restrictions, inform developers of its inherent risks, and acknowledge that > Bitcoin, in its present state, might not be ideally suited for certain > types of applications? In the specific case of annex replacement leading to larger transactions, in almost all cases you only care about the annex malleability causing the transaction to take longer to get mined, due to it being larger. The fact the transaction has become larger does not matter if the transaction does in fact get mined, eg due to an out-of-band payment by the "attacker". The only exception is the rare cases where some transaction processing software/hardware has actual limits on transaction size. Eg you could imagine a hardware wallet that simply *can't* process a transaction larger than a certain size due to a lack of RAM. I don't think this is a good rational to make use of the annex standard. Quite the contrary: we should be thinking about if and how to fix annex malleability in a future soft fork. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
