Standardisation of an unstructured taproot annex

Standardisation of an unstructured taproot annex
2023-06-03  1:08 ` David A. Harding
                   ` (2 more replies)
  
From: Joost Jager @ 2023-06-02 15:00 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

Hi,

As it stands, the taproot annex is consensus valid but non-standard. The
conversations around standardization seem to be leaning towards the
adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
that this approach has considerable potential. However, settling on an
exact format may require a significant amount of time.

In the interim, the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing developers
to utilize the taproot annex without delay, we can take advantage of its
features today, without the need to wait for the finalization of a more
lengthy standardization process.

With this in view, I am proposing that we define any annex that begins with
'0' as free-form, without any additional constraints. This strategy offers
several distinct benefits:

Immediate utilization: This opens the door for developers to make use of
the taproot annex for a variety of applications straight away, thus
eliminating the need to wait for the implementation of TLV or any other
structured format.

Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
options open for future developments and structure improvements. As we
forge ahead in determining the best way to standardize the annex, this
strategy ensures we do not limit ourselves by setting its structure in
stone prematurely.

Chainspace efficiency: Non-structured data may require fewer bytes compared
to a probable TLV format, which would necessitate the encoding of length
even when there's only a single field.

In conclusion, adopting this approach will immediately broaden the
utilization scope of the taproot annex while preserving the possibility of
transitioning to a more structured format in the future. I believe this is
a pragmatic and efficient route, one that can yield substantial benefits in
both the short and long term.

Joost

[1] https://github.com/bitcoin/bips/pull/1381

[-- Attachment #2: Type: text/html, Size: 2110 bytes --]

 permalink raw reply	[|nested]
2023-06-03  1:08 ` 
                   ` 
  
From: Joost Jager @ 2023-06-02 15:00 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

Hi,

As it stands, the taproot annex is consensus valid but non-standard. The
conversations around standardization seem to be leaning towards the
adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
that this approach has considerable potential. However, settling on an
exact format may require a significant amount of time.

In the interim, the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing developers
to utilize the taproot annex without delay, we can take advantage of its
features today, without the need to wait for the finalization of a more
lengthy standardization process.

With this in view, I am proposing that we define any annex that begins with
'0' as free-form, without any additional constraints. This strategy offers
several distinct benefits:

Immediate utilization: This opens the door for developers to make use of
the taproot annex for a variety of applications straight away, thus
eliminating the need to wait for the implementation of TLV or any other
structured format.

Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
options open for future developments and structure improvements. As we
forge ahead in determining the best way to standardize the annex, this
strategy ensures we do not limit ourselves by setting its structure in
stone prematurely.

Chainspace efficiency: Non-structured data may require fewer bytes compared
to a probable TLV format, which would necessitate the encoding of length
even when there's only a single field.

In conclusion, adopting this approach will immediately broaden the
utilization scope of the taproot annex while preserving the possibility of
transitioning to a more structured format in the future. I believe this is
a pragmatic and efficient route, one that can yield substantial benefits in
both the short and long term.

Joost

[1] https://github.com/bitcoin/bips/pull/1381

[-- Attachment #2: Type: text/html, Size: 2110 bytes --]

 permalink raw reply	[|nested]
2023-06-03  1:08 ` David A. Harding

  2023-06-03  9:14     ` Joost Jager
  2023-06-15  9:36     ` Joost Jager
  2023-06-03  7:49   ` Joost Jager
  
From: Greg Sanders @ 2023-06-03  1:14 UTC (permalink / raw)
  To: David A. Harding, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

Hello Joost, David,

Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.

It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
bitcoin-inquisition has included
the `annexcarrier` option. I have a particular use for APO-enabled payment
channel designs
that doesn't require consensus meaning, so some effort was put in to try
something out there.

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

Anyways, curious to hear what people think and want to make sure everyone
is on the same page.

Best,
Greg

On Fri, Jun 2, 2023 at 9:08 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> > the benefits of making the annex available in a
> > non-structured form are both evident and immediate. By allowing
> > developers to utilize the taproot annex without delay, we can take
> > advantage of its features today,
>
> Hi Joost,
>
> 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.
>
> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?
>
> -Dave
>
> [1]
>
> https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5152 bytes --]

 permalink raw reply	[|nested]
2023-06-03  1:08 ` David A. Harding
  2023-06-03  1:14   ` Greg Sanders

  2023-06-03  8:06     ` Joost Jager
  
From: Joost Jager @ 2023-06-03  7:49 UTC (permalink / raw)
  To: David A. Harding;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

Hi David,

On Sat, Jun 3, 2023 at 3:08 AM David A. Harding <dave@dtrt•org> 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

[-- Attachment #2: Type: text/html, Size: 2595 bytes --]

 permalink raw reply	[|nested]
2023-06-03  7:49   ` Joost Jager

  2023-06-03 12:05       ` Greg Sanders
  
From: Joost Jager @ 2023-06-03  8:06 UTC (permalink / raw)
  To: David A. Harding;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Sat, Jun 3, 2023 at 9:49 AM Joost Jager <joost.jager@gmail•com> 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

[-- Attachment #2: Type: text/html, Size: 948 bytes --]

 permalink raw reply	[|nested]
2023-06-03  1:14   ` Greg Sanders

  2023-06-03 15:50       ` Peter Todd
  2023-06-15  9:36     ` Joost Jager
  
From: Joost Jager @ 2023-06-03  9:14 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]

HI Greg,

On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders <gsanders87@gmail•com> 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

[-- Attachment #2: Type: text/html, Size: 4416 bytes --]

 permalink raw reply	[|nested]
2023-06-03  8:06     ` Joost Jager

  2023-06-03 12:35         ` Joost Jager
  
From: Greg Sanders @ 2023-06-03 12:05 UTC (permalink / raw)
  To: Joost Jager, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

> 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 <joost.jager@gmail•com> 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
>

[-- Attachment #2: Type: text/html, Size: 3836 bytes --]

 permalink raw reply	[|nested]
2023-06-03 12:05       ` Greg Sanders

  2023-06-03 12:43           ` Greg Sanders
  
From: Joost Jager @ 2023-06-03 12:35 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

>
> > 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

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

 permalink raw reply	[|nested]
2023-06-03 12:35         ` Joost Jager

  2023-06-03 12:55             ` Joost Jager
  
From: Greg Sanders @ 2023-06-03 12:43 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

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 <joost.jager@gmail•com> 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
>

[-- Attachment #2: Type: text/html, Size: 1933 bytes --]

 permalink raw reply	[|nested]
2023-06-03 12:43           ` Greg Sanders

  
From: Joost Jager @ 2023-06-03 12:55 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On Sat, Jun 3, 2023 at 2:43 PM Greg Sanders <gsanders87@gmail•com> 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

>

[-- Attachment #2: Type: text/html, Size: 1149 bytes --]

 permalink raw reply	[|nested]
2023-06-03  9:14     ` Joost Jager

  
From: Peter Todd @ 2023-06-03 15:50 UTC (permalink / raw)
  To: Joost Jager, Bitcoin Protocol Discussion;  Greg Sanders

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2023-06-02 15:00 [bitcoin-dev] Standardisation of an unstructured taproot annex Joost Jager
  2023-06-03  1:08 ` David A. Harding

  2023-06-10  0:23 ` Antoine Riard
  
From: Joost Jager @ 2023-06-08  9:16 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

Hi,

In the proposal below, any annex that begins with `0x00` is defined as
free-form. This isn't the most efficient format though because there is
always one byte lost on signalling. In a future where unstructured annex
data turns out to be the predominant use case, this may be relevant. Also
for very short annexes, the lost byte may weigh relatively heavy.

Without sacrificing future extensions to structured annex data, one could
also store the annex data as is except for the case where the data starts
with `0x21` (or any other 'uncommon' byte). If the data starts with `0x21`,
this byte needs to be repeated first and then followed by the remainder of
the data.

Examples:

Data: [01 02 03]
Encoding [01 02 03]

Data: [21 22 23]
Encoding: [21 21 22 23]

The prefixes [21 (not 21)] are available for future upgrades.

Joost

On Fri, Jun 2, 2023 at 5:00 PM Joost Jager <joost.jager@gmail•com> wrote:

> Hi,
>
> As it stands, the taproot annex is consensus valid but non-standard. The
> conversations around standardization seem to be leaning towards the
> adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
> that this approach has considerable potential. However, settling on an
> exact format may require a significant amount of time.
>
> In the interim, the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing developers
> to utilize the taproot annex without delay, we can take advantage of its
> features today, without the need to wait for the finalization of a more
> lengthy standardization process.
>
> With this in view, I am proposing that we define any annex that begins
> with '0' as free-form, without any additional constraints. This strategy
> offers several distinct benefits:
>
> Immediate utilization: This opens the door for developers to make use of
> the taproot annex for a variety of applications straight away, thus
> eliminating the need to wait for the implementation of TLV or any other
> structured format.
>
> Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
> options open for future developments and structure improvements. As we
> forge ahead in determining the best way to standardize the annex, this
> strategy ensures we do not limit ourselves by setting its structure in
> stone prematurely.
>
> Chainspace efficiency: Non-structured data may require fewer bytes
> compared to a probable TLV format, which would necessitate the encoding of
> length even when there's only a single field.
>
> In conclusion, adopting this approach will immediately broaden the
> utilization scope of the taproot annex while preserving the possibility of
> transitioning to a more structured format in the future. I believe this is
> a pragmatic and efficient route, one that can yield substantial benefits in
> both the short and long term.
>
> Joost
>
> [1] https://github.com/bitcoin/bips/pull/1381
>

[-- Attachment #2: Type: text/html, Size: 3528 bytes --]

 permalink raw reply	[|nested]
2023-06-02 15:00 [bitcoin-dev] Standardisation of an unstructured taproot annex Joost Jager
  2023-06-03  1:08 ` David A. Harding
  2023-06-08  9:16 ` Joost Jager

  2023-06-10  7:43   ` Joost Jager
  
From: Antoine Riard @ 2023-06-10  0:23 UTC (permalink / raw)
  To: Joost Jager, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]

Hi Joost,

Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.

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 ? 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.

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.

Best,
Antoine

Le ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

> Hi,
>
> As it stands, the taproot annex is consensus valid but non-standard. The
> conversations around standardization seem to be leaning towards the
> adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
> that this approach has considerable potential. However, settling on an
> exact format may require a significant amount of time.
>
> In the interim, the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing developers
> to utilize the taproot annex without delay, we can take advantage of its
> features today, without the need to wait for the finalization of a more
> lengthy standardization process.
>
> With this in view, I am proposing that we define any annex that begins
> with '0' as free-form, without any additional constraints. This strategy
> offers several distinct benefits:
>
> Immediate utilization: This opens the door for developers to make use of
> the taproot annex for a variety of applications straight away, thus
> eliminating the need to wait for the implementation of TLV or any other
> structured format.
>
> Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
> options open for future developments and structure improvements. As we
> forge ahead in determining the best way to standardize the annex, this
> strategy ensures we do not limit ourselves by setting its structure in
> stone prematurely.
>
> Chainspace efficiency: Non-structured data may require fewer bytes
> compared to a probable TLV format, which would necessitate the encoding of
> length even when there's only a single field.
>
> In conclusion, adopting this approach will immediately broaden the
> utilization scope of the taproot annex while preserving the possibility of
> transitioning to a more structured format in the future. I believe this is
> a pragmatic and efficient route, one that can yield substantial benefits in
> both the short and long term.
>
> Joost
>
> [1] https://github.com/bitcoin/bips/pull/1381
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4482 bytes --]

 permalink raw reply	[|nested]
2023-06-10  0:23 ` Antoine Riard

  2023-06-10 22:09     ` David A. Harding
                       ` (2 more replies)
  
From: Joost Jager @ 2023-06-10  7:43 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

Hi Antoine,

On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard <antoine.riard@gmail•com>
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] https://github.com/bitcoin/bips/pull/1421
[3] https://github.com/bitcoin/bitcoin/pull/24007

[-- Attachment #2: Type: text/html, Size: 5336 bytes --]

 permalink raw reply	[|nested]
2023-06-10  0:23 ` Antoine Riard

  2023-06-10 22:09     ` 
                       ` 
  
From: Joost Jager @ 2023-06-10  7:43 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

Hi Antoine,

On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard <antoine.riard@gmail•com>
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] https://github.com/bitcoin/bips/pull/1421
[3] https://github.com/bitcoin/bitcoin/pull/24007

[-- Attachment #2: Type: text/html, Size: 5336 bytes --]

 permalink raw reply	[|nested]
2023-06-10 22:09     ` David A. Harding

  2023-06-12  3:16         ` Antoine Riard
  2023-06-13  8:51         ` David A. Harding
  
From: Joost Jager @ 2023-06-11 19:25 UTC (permalink / raw)
  To: David A. Harding;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

Hi Dave,

On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave@dtrt•org> wrote:

> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>     #1 and pushes a serialized partial signature for the ephemeral key
>     from #2 onto the stack, where it's immediately dropped by the
>     interpreter (but is permanently stored on the block chain).  She also
>     attaches a regular signature for the OP_CHECKSIG opcode.
>

Isn't it the case that that op-dropped partial signature for the ephemeral
key isn't committed to and thus can be modified by anyone before it is
mined, effectively deleting the keys to the vault? If not, this would be a
great alternative!

Even better, I think you can achieve nearly the same safety without
> putting any data on the chain.  All you need is a widely used
> decentralized protocol that allows anyone who can prove ownership of a
> UTXO to store some data.
>

I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.

By comparison, rolling
> out relay of the annex and witness replacement may take months of review
> and years for >90% deployment among nodes, would allow an attacker to
> lower the feerate of coinjoin-style transactions by up to 4.99%, would
> allow an attacker to waste 8 million bytes of bandwidth per relay node
> for the same cost they'd have to pay to today to waste 400 thousand
> bytes, and might limit the flexibility and efficiency of future
> consensus changes that want to use the annex.


That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay transactions to miners
besides the p2p network?

I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.

Joost

[-- Attachment #2: Type: text/html, Size: 2719 bytes --]

 permalink raw reply	[|nested]
2023-06-11 19:25       ` Joost Jager

  2023-06-13  8:51         ` David A. Harding
  
From: Antoine Riard @ 2023-06-12  3:16 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 8565 bytes --]

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
use-cases are coming with their own specifics.

> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witnesses
would provide a viable solution?

To be honest, in terms of DoS, I wouldn't give a strong opinion before
better formalization or consensus of the use-case requirements. From
experience of Core's mempools PRs, you have few subcomponents that can be
involved (replacement, block template, broadcast backend of L2s, etc).

> That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay
> transactions to miners besides the p2p network?

Assuming an alternative p2p network, I don't think we can avoid some
standardization of fundamental data structures between those p2p network.
Most of L2s are pre-signing transactions/packages and might not be able to
alter the validity of such set of transactions in a unilateral fashion
without re-introducing some “bad” malleability. And a L2 node has an
interest to use multiple p2p networks to mitigate against things like
time-dilation attacks.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html

Le dim. 11 juin 2023 à 20:26, Joost Jager <joost.jager@gmail•com> a écrit :

> Hi Dave,
>
> On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave@dtrt•org> wrote:
>
>> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>>     #1 and pushes a serialized partial signature for the ephemeral key
>>     from #2 onto the stack, where it's immediately dropped by the
>>     interpreter (but is permanently stored on the block chain).  She also
>>     attaches a regular signature for the OP_CHECKSIG opcode.
>>
>
> Isn't it the case that that op-dropped partial signature for the ephemeral
> key isn't committed to and thus can be modified by anyone before it is
> mined, effectively deleting the keys to the vault? If not, this would be a
> great alternative!
>
> Even better, I think you can achieve nearly the same safety without
>> putting any data on the chain.  All you need is a widely used
>> decentralized protocol that allows anyone who can prove ownership of a
>> UTXO to store some data.
>>
>
> I appreciate the suggestion, but I am really looking for a bitcoin-native
> solution to leverage bitcoin's robustness and security properties.
>
> By comparison, rolling
>> out relay of the annex and witness replacement may take months of review
>> and years for >90% deployment among nodes, would allow an attacker to
>> lower the feerate of coinjoin-style transactions by up to 4.99%, would
>> allow an attacker to waste 8 million bytes of bandwidth per relay node
>> for the same cost they'd have to pay to today to waste 400 thousand
>> bytes, and might limit the flexibility and efficiency of future
>> consensus changes that want to use the annex.
>
>
> That years-long timeline that you sketch for witness replacement (or any
> other policy change I presume?) to become effective is perhaps indicative
> of the need to have an alternative way to relay transactions to miners
> besides the p2p network?
>
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
>
> Joost
>

[-- Attachment #2: Type: text/html, Size: 10490 bytes --]

 permalink raw reply	[|nested]
2023-06-10  7:43   ` Joost Jager
  2023-06-10 22:09     ` David A. Harding

  2023-06-20 12:30     ` Joost Jager
  
From: Greg Sanders @ 2023-06-12 13:03 UTC (permalink / raw)
  To: Joost Jager, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 5407 bytes --]

> 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 <antoine.riard@gmail•com>
> 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] https://github.com/bitcoin/bips/pull/1421
> [3] https://github.com/bitcoin/bitcoin/pull/24007
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7014 bytes --]

 permalink raw reply	[|nested]
2023-06-11 19:25       ` Joost Jager
  2023-06-12  3:16         ` Antoine Riard

  2023-06-13 10:38           ` Joost Jager
  
From: David A. Harding @ 2023-06-13  8:51 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

On 2023-06-11 09:25, Joost Jager wrote:
> Isn't it the case that that op-dropped partial signature for the
> ephemeral key isn't committed to and thus can be modified by anyone
> before it is mined

That's correct; I hadn't thought of that, sorry.

> I am really looking for a bitcoin-native solution to leverage
> bitcoin's robustness and security properties.

I understand.  I would briefly point out that there are other advantages
to not storing a signature for an ephemeral key in the annex.  For
example, if you want to generate multiple different potential spending
transactions, you need to store one signature for each potential
transaction.  The more data you store in the annex, the less scalable
the vault protocol becomes; by comparison, it's possible to cheaply
store a very large amount of data offchain with high robustness.

Also, depending on construction of the vault, a possible advantage of a
presigned vault (without using the annex) over a solution like OP_VAULT
is that all actions might be able to use keypath spends.  That would be
highly efficient, increasing the usability of vaults.  It would also be
more private, which may be important to certain classes of vault users.
Even if OP_VAULT was added to Bitcoin, it would be interesting to have
an alternative vault protocol that offered different tradeoffs.

> That years-long timeline that you sketch for witness replacement (or
> any other policy change I presume?) to become effective is perhaps
> indicative of the need to have an alternative way to relay
> transactions to miners besides the p2p network?

The speed depends on the policy change.  In this case, I think there's a
reasonable argument to be made that a mitigation for the problems of
annex relay should be widely deployed before we enable annex relay.

Bitcoin Core's policy is designed to both prevent the abuse of relay
node resources and also serve the transaction selection needs of miners.
Any alternative relay system will need to solve the same general
problems: how to prevent abuse of the relayers and help miners choose
the best transactions.  Ideas for alternative relay like those
previously proposed on this list[1] avoid certain problems but also
(AFAICT) create new problems.

To be specific towards this proposal, if an alternative relay network
naively implemented annex relay, any miners who used that network could
receive a coinjoin-style transaction with a large annex that
significantly reduced the transaction's feerate.  By comparison, any
miners who continued to only receive transactions from the P2P network
of Bitcoin Core (or similar) nodes would have received the transaction
without an annex at its original (higher) feerate, allowing them to to
receive greater revenue if they mined it.  If, instead, the alternative
relay network implemented the witness replacement proposal you've linked
to, those miners could still receive up to 4.99% less revenue than
Bitcoin Core-based miners and the operators of the alternative relay
network might have had to pay extra costs for the replacement relays.
You can tweak the proposal to tweak those ratios, but I'm not sure
there's a case where an alternative relay network comes up as a clear
winner over the existing network for general purpose transactions.
Instead, like many things, it's a matter of tradeoffs.

> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.

Apologies for the salt, but there is a good solution: don't use the
block chain to store backup data.

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html


 permalink raw reply	[|nested]
2023-06-13  8:51         ` David A. Harding

  
From: Joost Jager @ 2023-06-13 10:38 UTC (permalink / raw)
  To: David A. Harding;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 5071 bytes --]

On Tue, Jun 13, 2023 at 10:51 AM David A. Harding <dave@dtrt•org> wrote:

> > I am really looking for a bitcoin-native solution to leverage
> > bitcoin's robustness and security properties.
>
> I understand.  I would briefly point out that there are other advantages
> to not storing a signature for an ephemeral key in the annex.  For
> example, if you want to generate multiple different potential spending
> transactions, you need to store one signature for each potential
> transaction.  The more data you store in the annex, the less scalable
> the vault protocol becomes; by comparison, it's possible to cheaply
> store a very large amount of data offchain with high robustness.
>

Each byte on-chain indeed has a cost. Though for practical vault usage, you
may only need two spend paths - one for the unvaulting transaction and
another for an emergency transaction.

Also, depending on construction of the vault, a possible advantage of a
> presigned vault (without using the annex) over a solution like OP_VAULT
> is that all actions might be able to use keypath spends.  That would be
> highly efficient, increasing the usability of vaults.  It would also be
> more private, which may be important to certain classes of vault users.
> Even if OP_VAULT was added to Bitcoin, it would be interesting to have
> an alternative vault protocol that offered different tradeoffs.
>

It would indeed be interesting to compare the on-chain footprint of both
vault protocols. The main downside of presigned transactions of course is
the requirement for an ephemeral signer and key deletion. I am not sure if
a potentially smaller on-chain footprint is able to compensate for that.
But the landscape of tradeoffs is complicated, and hard to say what users
prefer if both options would be available to them.


> > That years-long timeline that you sketch for witness replacement (or
> > any other policy change I presume?) to become effective is perhaps
> > indicative of the need to have an alternative way to relay
> > transactions to miners besides the p2p network?
>
> The speed depends on the policy change.  In this case, I think there's a
> reasonable argument to be made that a mitigation for the problems of
> annex relay should be widely deployed before we enable annex relay.
>

On the other hand, maybe we are inside a window of opportunity where the
annex can still be enabled without mitigating this problem fully. Taproot
is still young and you could argue that there are not that many
applications that would be affected by this yet. By clearly communicating
the lack of witness replacement by commonly used node software now,
developers may want to hold off on implementing these applications, rather
than giving them a false sense of security offered by policy. But we've
covered that in this thread before.


> To be specific towards this proposal, if an alternative relay network
> naively implemented annex relay, any miners who used that network could
> receive a coinjoin-style transaction with a large annex that
> significantly reduced the transaction's feerate.  By comparison, any
> miners who continued to only receive transactions from the P2P network
> of Bitcoin Core (or similar) nodes would have received the transaction
> without an annex at its original (higher) feerate, allowing them to to
> receive greater revenue if they mined it.  If, instead, the alternative
> relay network implemented the witness replacement proposal you've linked
> to, those miners could still receive up to 4.99% less revenue than
> Bitcoin Core-based miners


Perhaps way to fix this is to combine the 5% (or whatever constant is
chosen) with Greg's proposal above to also always allow replacement by an
empty annex? That way it's always possible to put in an annex-less
transaction that is part of an annex-less protocol, regardless of how few
extra bytes the annex was inflated with in a previous version of that tx.


> and the operators of the alternative relay
> network might have had to pay extra costs for the replacement relays.
> You can tweak the proposal to tweak those ratios, but I'm not sure
> there's a case where an alternative relay network comes up as a clear
> winner over the existing network for general purpose transactions.
> Instead, like many things, it's a matter of tradeoffs.
>

It is the question whether those 5% replacement DoS attacks are powerful
enough to make it worthwhile for an attacker. And in the case for example
the nostr proposal, there could be anti DoS on a different level as well.


> > I agree though that it would be ideal if there is a good solution that
> > doesn't require any protocol changes or upgrade path.
>
> Apologies for the salt, but there is a good solution: don't use the
> block chain to store backup data.
>

Any auxiliary system that is required for operating a vault adds risk.
Whether it is still good enough is debatable, but I expect some users to
hold the opinion that it isn't.

Joost

[-- Attachment #2: Type: text/html, Size: 6335 bytes --]

 permalink raw reply	[|nested]
2023-06-03  1:14   ` Greg Sanders
  2023-06-03  9:14     ` Joost Jager

  2023-06-15 10:39       ` Greg Sanders
  
From: Joost Jager @ 2023-06-15  9:36 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hi Greg,

Getting back to this:

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.
>

Ignoring the argument that policy may provide a false sense of security, I
think this is an interesting idea. Opt-in would enable convenants through
presigned txes with atomic on-chain signature backup, without needing to
worry about non-annex multi-party protocols (coinjoin and dual funded
lightning mentioned previously) that may suffer from annex inflation or the
last signer presenting an unexpected annex. The downside is just that extra
empty annex byte per input, if there are other inputs involved. To me that
would be a reasonable trade-off.

Would it then still be necessary to restrict the annex to a maximum size?
Perhaps not opting into annex for multi-party protocols is sufficient. Or
otherwise, #24007 may be helpful. It is hard to pick a constant usually.

Joost.

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

 permalink raw reply	[|nested]
2023-06-15  9:36     ` Joost Jager

  2023-06-16 11:26         ` Joost Jager
  
From: Greg Sanders @ 2023-06-15 10:39 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

Hi Joost,

> Ignoring the argument that policy may provide a false sense of security

This may take longer form arguments than I'm willing to make on this
thread, but I think this only true in a shallower sense that we cannot know
for sure that anything will be confirmed quickly. When crafting policy, we
are trying to make as reliable-as-possible systems to allow people to pay
miners. That may mean opening up the annex to potential use-cases, but it
certainly means allowing current users of the p2p network to make
reasonable feerate transactions in coinjoin-like scenarios. Ideally we
shoot for as many use cases as we can, to pay these miners.

> Would it then still be necessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and can also
be used for other anti-pinning efforts(though clearly not sufficient by
itself for the many many pinning vectors we have :) )

Cheers,
Greg

On Thu, Jun 15, 2023 at 5:36 AM Joost Jager <joost.jager@gmail•com> wrote:

> Hi Greg,
>
> Getting back to this:
>
> 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.
>>
>
> Ignoring the argument that policy may provide a false sense of security, I
> think this is an interesting idea. Opt-in would enable convenants through
> presigned txes with atomic on-chain signature backup, without needing to
> worry about non-annex multi-party protocols (coinjoin and dual funded
> lightning mentioned previously) that may suffer from annex inflation or the
> last signer presenting an unexpected annex. The downside is just that extra
> empty annex byte per input, if there are other inputs involved. To me that
> would be a reasonable trade-off.
>
> Would it then still be necessary to restrict the annex to a maximum size?
> Perhaps not opting into annex for multi-party protocols is sufficient. Or
> otherwise, #24007 may be helpful. It is hard to pick a constant usually.
>
> Joost.
>

[-- Attachment #2: Type: text/html, Size: 3075 bytes --]

 permalink raw reply	[|nested]
2023-06-15 10:39       ` Greg Sanders

  2023-06-16 13:30           ` Greg Sanders
  
From: Joost Jager @ 2023-06-16 11:26 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Hi Greg,

On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87@gmail•com> wrote:

> > Would it then still be necessary to restrict the annex to a maximum size?
>
> I think it's worth thinking about to protect the opt-in users, and can
> also be used for other anti-pinning efforts(though clearly not sufficient
> by itself for the many many pinning vectors we have :) )
>

Thinking about the most restrictive policy that would still enable
annex-vaults (which I believe has great potential for improving bitcoin
custody) and is in line with work already done, I get to:

* Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
* Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
future extensibility
* Only allow tlv record 0 - unstructured data -> future extensibility
* Limit maximum size of the value to 256 bytes -> protect opt-in users

Unfortunately the limit of 126 bytes in
https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient for
these types of vaults. If there are two presigned txes (unvault and
emergency), those signatures would already take up 2*64=128 bytes. Then you
also want to store 32 bytes for the ephemeral key itself as the key can't
be reconstructed from the schnorr signature. The remaining bytes could be
used for a third presigned tx and/or additional vault parameters.

Can you think of remaining practical objections to making the annex
standard under the conditions listed above?

Joost

>

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

 permalink raw reply	[|nested]
2023-06-16 11:26         ` Joost Jager

  2023-06-18 20:32             ` Antoine Riard
  
From: Greg Sanders @ 2023-06-16 13:30 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

Hi Joost,

I haven't thought a ton about the specific TLV format, but that seems like
a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspective.
It also can be further relaxed in the future if we so decide by using max
tx size policy "hints" in an annex field.

I'll let others chime in at this point!

Cheers,
Greg

On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager@gmail•com> wrote:

> Hi Greg,
>
> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87@gmail•com>
> wrote:
>
>> > Would it then still be necessary to restrict the annex to a maximum
>> size?
>>
>> I think it's worth thinking about to protect the opt-in users, and can
>> also be used for other anti-pinning efforts(though clearly not sufficient
>> by itself for the many many pinning vectors we have :) )
>>
>
> Thinking about the most restrictive policy that would still enable
> annex-vaults (which I believe has great potential for improving bitcoin
> custody) and is in line with work already done, I get to:
>
> * Opt-in annex (every input must commit to an annex even if its is empty)
> -> make sure existing multi-party protocols remain unaffected
> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
> future extensibility
> * Only allow tlv record 0 - unstructured data -> future extensibility
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> Unfortunately the limit of 126 bytes in
> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
> for these types of vaults. If there are two presigned txes (unvault and
> emergency), those signatures would already take up 2*64=128 bytes. Then you
> also want to store 32 bytes for the ephemeral key itself as the key can't
> be reconstructed from the schnorr signature. The remaining bytes could be
> used for a third presigned tx and/or additional vault parameters.
>
> Can you think of remaining practical objections to making the annex
> standard under the conditions listed above?
>
> Joost
>
>>

[-- Attachment #2: Type: text/html, Size: 3397 bytes --]

 permalink raw reply	[|nested]
2023-06-16 13:30           ` Greg Sanders

  2023-06-18 20:40               ` Greg Sanders
  2023-06-20 12:50               ` Joost Jager
  
From: Antoine Riard @ 2023-06-18 20:32 UTC (permalink / raw)
  To: Greg Sanders, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3536 bytes --]

Hi all,

> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected

By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
absent ?

If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest. This would be quite a
mandatory upgrade for Lightning nodes, as failure to do so would break
propagations of their `option_taproot` channel transactions.

> * Limit maximum size of the value to 256 bytes -> protect opt-in users

There is another approach where the maximum size/weight of the
witness/transaction is introduced as a TLV record itself:
https://github.com/bitcoin-inquisition/bitcoin/pull/28

Note this branch also implements the "only allow tlv record 0" with the TLV
format from bips #1381.

Best,
Antoine

Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

> Hi Joost,
>
> I haven't thought a ton about the specific TLV format, but that seems like
> a reasonable place to start as it shouldn't unduly
> impact current users, and is pretty simple from an accounting perspective.
> It also can be further relaxed in the future if we so decide by using max
> tx size policy "hints" in an annex field.
>
> I'll let others chime in at this point!
>
> Cheers,
> Greg
>
> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager@gmail•com> wrote:
>
>> Hi Greg,
>>
>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87@gmail•com>
>> wrote:
>>
>>> > Would it then still be necessary to restrict the annex to a maximum
>>> size?
>>>
>>> I think it's worth thinking about to protect the opt-in users, and can
>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>> by itself for the many many pinning vectors we have :) )
>>>
>>
>> Thinking about the most restrictive policy that would still enable
>> annex-vaults (which I believe has great potential for improving bitcoin
>> custody) and is in line with work already done, I get to:
>>
>> * Opt-in annex (every input must commit to an annex even if its is empty)
>> -> make sure existing multi-party protocols remain unaffected
>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
>> future extensibility
>> * Only allow tlv record 0 - unstructured data -> future extensibility
>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>
>> Unfortunately the limit of 126 bytes in
>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
>> for these types of vaults. If there are two presigned txes (unvault and
>> emergency), those signatures would already take up 2*64=128 bytes. Then you
>> also want to store 32 bytes for the ephemeral key itself as the key can't
>> be reconstructed from the schnorr signature. The remaining bytes could be
>> used for a third presigned tx and/or additional vault parameters.
>>
>> Can you think of remaining practical objections to making the annex
>> standard under the conditions listed above?
>>
>> Joost
>>
>>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5745 bytes --]

 permalink raw reply	[|nested]
2023-06-18 20:32             ` Antoine Riard

  2023-06-19  1:14                 ` Antoine Riard
  2023-06-20 12:50               ` Joost Jager
  
From: Greg Sanders @ 2023-06-18 20:40 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4273 bytes --]

Hi Antoine,

> If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest.

huh?

Going to need a citation for this.

People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
and we should not be encumbered by these premature choices if so. Maybe I'm
misunderstanding, which is why a citation
would be handy.

Best,
Greg

On Sun, Jun 18, 2023 at 4:32 PM Antoine Riard <antoine.riard@gmail•com>
wrote:

> Hi all,
>
> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do you
> mean rejecting a transaction where the minimal annex with its 0x50 tag is
> absent ?
>
> If I understand correctly, this would require modifying current Taproot
> support on the Lightning-side, where all P2TR spends must add an annex and
> commit to it in the BIP341 signature digest. This would be quite a
> mandatory upgrade for Lightning nodes, as failure to do so would break
> propagations of their `option_taproot` channel transactions.
>
> > * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> There is another approach where the maximum size/weight of the
> witness/transaction is introduced as a TLV record itself:
> https://github.com/bitcoin-inquisition/bitcoin/pull/28
>
> Note this branch also implements the "only allow tlv record 0" with the
> TLV format from bips #1381.
>
> Best,
> Antoine
>
> Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> a écrit :
>
>> Hi Joost,
>>
>> I haven't thought a ton about the specific TLV format, but that seems
>> like a reasonable place to start as it shouldn't unduly
>> impact current users, and is pretty simple from an accounting perspective.
>> It also can be further relaxed in the future if we so decide by using max
>> tx size policy "hints" in an annex field.
>>
>> I'll let others chime in at this point!
>>
>> Cheers,
>> Greg
>>
>> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager@gmail•com>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87@gmail•com>
>>> wrote:
>>>
>>>> > Would it then still be necessary to restrict the annex to a maximum
>>>> size?
>>>>
>>>> I think it's worth thinking about to protect the opt-in users, and can
>>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>>> by itself for the many many pinning vectors we have :) )
>>>>
>>>
>>> Thinking about the most restrictive policy that would still enable
>>> annex-vaults (which I believe has great potential for improving bitcoin
>>> custody) and is in line with work already done, I get to:
>>>
>>> * Opt-in annex (every input must commit to an annex even if its is
>>> empty) -> make sure existing multi-party protocols remain unaffected
>>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
>>> future extensibility
>>> * Only allow tlv record 0 - unstructured data -> future extensibility
>>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>>
>>> Unfortunately the limit of 126 bytes in
>>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
>>> for these types of vaults. If there are two presigned txes (unvault and
>>> emergency), those signatures would already take up 2*64=128 bytes. Then you
>>> also want to store 32 bytes for the ephemeral key itself as the key can't
>>> be reconstructed from the schnorr signature. The remaining bytes could be
>>> used for a third presigned tx and/or additional vault parameters.
>>>
>>> Can you think of remaining practical objections to making the annex
>>> standard under the conditions listed above?
>>>
>>> Joost
>>>
>>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 6571 bytes --]

 permalink raw reply	[|nested]
2023-06-18 20:40               ` Greg Sanders

  
From: Antoine Riard @ 2023-06-19  1:14 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 6670 bytes --]

Hi Greg,

> Going to need a citation for this.

Sorry for the confusion, this was in reply to Joost's point on "Opt-in
annex (every input must commit to an annex even if its is empty) -> make
sure existing multi-party protocols remain unaffected"

What is unclear to me is if we're talking about opt-in of non-deployed-yet
protocols like the pre-signed vaults or deployed protocols like
coinjoin/lightning spending P2TR outputs, where a counterparty script spend
path can inflate the witness, and we would like to commit *now* to avoid
future interferences. E.g 0-conf dual-funding and we loosened the limit
from 126 bytes to 256, the worst-case liquidity griefing is not the same
anymore.

If the opt-in mechanism we're talking about is just adding an annex for
non-deployed-yet protocols as a script spend path of a currently deployed
protocol could always be opted-in to the new annex policy through script
spend path in the context of collaborative added inputs, no ?

> People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
and we should not be encumbered by these premature choices if so.

> People should really not be building protocols that are meant to go into
production on top of undeveloped upgrade hooks,
> and we should not be encumbered by these premature choices if so. Maybe
I'm misunderstanding, which is why a citation
> would be handy.

Yes ideally we should not be encumbered by these premature choices. Still
if those use-cases catched up in terms of economic weight, the coordination
cost of deploying a new policy might be prohibitive, or require very long
periods, somehow like we're seeing with mempoolfullrbf. And I don't think
we can say the use-cases would be illegitimate, or that base-layer policy
should always have the last word. In the example of lightning, we're doing
major re-work of the mempool, partially to improve lightning operations.
Personally, I think we should care more about sound and "firewalled"
signaling and upgrading mechanisms that let us deploy new policy rules for
new use-cases more smoothly.

Best,
Antoine

Le dim. 18 juin 2023 à 21:41, Greg Sanders <gsanders87@gmail•com> a écrit :

> Hi Antoine,
>
> > If I understand correctly, this would require modifying current Taproot
> support on the Lightning-side, where all P2TR spends must add an annex and
> commit to it in the BIP341 signature digest.
>
> huh?
>
> Going to need a citation for this.
>
> People should really not be building protocols that are meant to go into
> production on top of undeveloped upgrade hooks,
> and we should not be encumbered by these premature choices if so. Maybe
> I'm misunderstanding, which is why a citation
> would be handy.
>
> Best,
> Greg
>
> On Sun, Jun 18, 2023 at 4:32 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
>
>> Hi all,
>>
>> > * Opt-in annex (every input must commit to an annex even if its is
>> empty) -> make sure existing multi-party protocols remain unaffected
>>
>> By requiring every input to commit to an annex even if it is empty, do
>> you mean rejecting a transaction where the minimal annex with its 0x50 tag
>> is absent ?
>>
>> If I understand correctly, this would require modifying current Taproot
>> support on the Lightning-side, where all P2TR spends must add an annex and
>> commit to it in the BIP341 signature digest. This would be quite a
>> mandatory upgrade for Lightning nodes, as failure to do so would break
>> propagations of their `option_taproot` channel transactions.
>>
>> > * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>
>> There is another approach where the maximum size/weight of the
>> witness/transaction is introduced as a TLV record itself:
>> https://github.com/bitcoin-inquisition/bitcoin/pull/28
>>
>> Note this branch also implements the "only allow tlv record 0" with the
>> TLV format from bips #1381.
>>
>> Best,
>> Antoine
>>
>> Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> a écrit :
>>
>>> Hi Joost,
>>>
>>> I haven't thought a ton about the specific TLV format, but that seems
>>> like a reasonable place to start as it shouldn't unduly
>>> impact current users, and is pretty simple from an accounting
>>> perspective.
>>> It also can be further relaxed in the future if we so decide by using
>>> max tx size policy "hints" in an annex field.
>>>
>>> I'll let others chime in at this point!
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager@gmail•com>
>>> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87@gmail•com>
>>>> wrote:
>>>>
>>>>> > Would it then still be necessary to restrict the annex to a maximum
>>>>> size?
>>>>>
>>>>> I think it's worth thinking about to protect the opt-in users, and can
>>>>> also be used for other anti-pinning efforts(though clearly not sufficient
>>>>> by itself for the many many pinning vectors we have :) )
>>>>>
>>>>
>>>> Thinking about the most restrictive policy that would still enable
>>>> annex-vaults (which I believe has great potential for improving bitcoin
>>>> custody) and is in line with work already done, I get to:
>>>>
>>>> * Opt-in annex (every input must commit to an annex even if its is
>>>> empty) -> make sure existing multi-party protocols remain unaffected
>>>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381
>>>> -> future extensibility
>>>> * Only allow tlv record 0 - unstructured data -> future extensibility
>>>> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>>>>
>>>> Unfortunately the limit of 126 bytes in
>>>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't
>>>> sufficient for these types of vaults. If there are two presigned txes
>>>> (unvault and emergency), those signatures would already take up 2*64=128
>>>> bytes. Then you also want to store 32 bytes for the ephemeral key itself as
>>>> the key can't be reconstructed from the schnorr signature. The remaining
>>>> bytes could be used for a third presigned tx and/or additional vault
>>>> parameters.
>>>>
>>>> Can you think of remaining practical objections to making the annex
>>>> standard under the conditions listed above?
>>>>
>>>> Joost
>>>>
>>>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

[-- Attachment #2: Type: text/html, Size: 9689 bytes --]

 permalink raw reply	[|nested]
2023-06-10  7:43   ` Joost Jager
  2023-06-10 22:09     ` David A. Harding
  2023-06-12 13:03     ` Greg Sanders

  2023-07-04 20:18       ` Antoine Riard
  
From: Joost Jager @ 2023-06-20 12:30 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

Hi all,

On Sat, Jun 10, 2023 at 9:43 AM Joost Jager <joost.jager@gmail•com> wrote:

> 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.
>

To support this use case of the taproot annex, I've create a simple demo
application here: https://github.com/joostjager/annex-covenants

This demo shows how a coin can be spent to a special address from which it
can - at a later stage - only move to a pre-defined final destination. It
makes use of the annex to store the ephemeral signature for the presigned
transaction so that the coin cannot get lost. This is assuming that nodes
do not prune witness data en masse and also that the destination address
itself is known.

The application may not be the most practically useful, but more advanced
covenants such as time-locked vaults can be implemented similarly.

Hopefully this further raises awareness of the on-chain ephemeral signature
backup functionality that the annex uniquely enables.

Joost

[-- Attachment #2: Type: text/html, Size: 3175 bytes --]

 permalink raw reply	[|nested]
2023-06-18 20:32             ` Antoine Riard
  2023-06-18 20:40               ` Greg Sanders

  
From: Joost Jager @ 2023-06-20 12:50 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Protocol Discussion, Greg Sanders

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Hi Antoine,

On Sun, Jun 18, 2023 at 10:32 PM Antoine Riard <antoine.riard@gmail•com>
wrote:

> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do you
> mean rejecting a transaction where the minimal annex with its 0x50 tag is
> absent ?
>

No what I meant, and what was mentioned by Greg in a previous email, is
that either none of the inputs have an annex, or all of them have one.

So if you're part of a multi-party transaction and you don't commit to an
annex, you can be sure that no version of that tx will appear where another
signer surprises you with a potentially large annex.

For future protocols that rely on the annex, everyone would need to opt-in
by committing to an annex (which can be empty just to signal opt-in).

Joost

[-- Attachment #2: Type: text/html, Size: 1347 bytes --]

 permalink raw reply	[|nested]
2023-06-20 12:30     ` Joost Jager

  
From: Antoine Riard @ 2023-07-04 20:18 UTC (permalink / raw)
  To: Joost Jager;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4111 bytes --]

Hi Joost,

> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.

From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex standard.

There is the observation that other critical elements of vault's
application state could be backed up in this way (e.g pubkeys and amounts
of the destination output) to rebuild from scratch a pre-signed withdrawal.
The unstructured data could be even marked by an application-level "tag" or
"signaling" to identify all the backup annexes composing your vault
application state.

Of course, such backing up of more critical elements comes with its own
drawbacks in terms of confidentiality, as you would leak your vault policy
on-chain, so they would need to be ciphered first, I think.

It sounds to me another economically rational set of use-cases can be to
simplify protocols using the chain as a publication space for collectibles.
Using the annex as a publication space enables a clear chain of collectible
ownership thanks to the key signing the annex, which is not permissible
with op_return outputs today.

Best,
Antoine


Le mar. 20 juin 2023 à 13:30, Joost Jager <joost.jager@gmail•com> a écrit :

> Hi all,
>
> On Sat, Jun 10, 2023 at 9:43 AM Joost Jager <joost.jager@gmail•com> wrote:
>
>> 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.
>>
>
> To support this use case of the taproot annex, I've create a simple demo
> application here: https://github.com/joostjager/annex-covenants
>
> This demo shows how a coin can be spent to a special address from which it
> can - at a later stage - only move to a pre-defined final destination. It
> makes use of the annex to store the ephemeral signature for the presigned
> transaction so that the coin cannot get lost. This is assuming that nodes
> do not prune witness data en masse and also that the destination address
> itself is known.
>
> The application may not be the most practically useful, but more advanced
> covenants such as time-locked vaults can be implemented similarly.
>
> Hopefully this further raises awareness of the on-chain ephemeral
> signature backup functionality that the annex uniquely enables.
>
> Joost
>

[-- Attachment #2: Type: text/html, Size: 5121 bytes --]

 permalink raw reply	[|nested]