Nostr notes by Nadav Ivgi [ARCHIVE]

📅 Original date posted:2022-05-01 📝 Original message:> ...

2023-06-07T23:08:53Z

In reply to nevent1q…mjcy
_________________________

📅 Original date posted:2022-05-01
📝 Original message:> via `sha_sequences`

Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.

Not committing to the nSequence of other inputs gives them the freedom to
set it independently, so for example you can spend a CSV-encumbered output
alongside the covenant. And there seems to be no downside to doing this [1].

APO/APOAS already commits to the nSequence of the current input. And since
APO is Taproot-only, the scriptSig of the covenant input is guarrnated to
be empty, so it is also already committed to in a way.

However, without committing to all the nSequences which implicitly commits
to the number of inputs, the number has to be committed separately.

So my suggestion is to explicitly commit to the number of inputs, instead
of commiting to `sha_sequences`.

Cheers
shesek

[0] the additional input(s) will be third-party malleable, since their
prevouts can be replaced with an entirely different txid:vout
[1] BIP 119's rationale for committing to the nSequences is txid
malleability:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-sequences-hash

On Sat, Apr 30, 2022 at 11:09 AM Nadav Ivgi <nadav at shesek.info> wrote:

> Hi darosior,
>
> It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY
> behaviour and without covering the spent input index) has some interesting
> uses for cases where the covenant only needs to restrict a single output
> (so useful for e.g. vaults or spacechains, but not for batch channels or
> congestion control).
>
> For example in the vault use-case, it makes it possible to bump fees on
> the unvault tx by adding more inputs and a change output, as well as
> unvault multiple vaulted outputs in a single transaction.
>
> For spacechains, it makes it possible to add the spaceblock hash OP_RETURN
> and pay fees directly in the tx chain, instead of having to use an
> additional tx to prepare an output that gets spent in the tx chain (see
> the diagram in [0]).
>
> > via `sha_sequences` and maybe also `sha_amounts`
>
> CTV does not commit to the input amounts. This has some practical
> implications:
>
> 1. If it is committed, sending an even slightly incorrect amount will make
> the covenant-encumbered spend path unusable.
>
> With CTV, sending a slightly lower amount results in slightly lower fees,
> while any extra gets spent/burned on fees. The covenant spend path only
> becomes unusable if the amount is too low to cover for the outputs (+relay
> fee for it to also be standard).
>
> 2. The ability to allow for additional inputs with unknown amounts makes
> it possible to fee-bump the covenant spending transaction (with whole utxos
> and no change). You can have one tapleaf for spending the covenant output
> alone, and another one for attaching an extra fee input to it.
>
> This also makes it possible to resolve the under-payment issue described
> in (1), by adding an input that covers the original intended amount.
>
> So my suggestion would be to either not cover `sha_amounts` in the msg
> hash, or to make it optional behind a flag.
>
> shesek
>
> [0] https://github.com/fiatjaf/simple-ctv-spacechain
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would like to know people's sentiment about doing (a very slightly
>> tweaked version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>> over 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if
>> i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>> optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
>> expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase.
>> Although as someone who've been trying to
>> implement practical vaults for the past 2 years i doubt CTV is necessary
>> nor sufficient for this (but still
>> useful!), using APO-AS covers it. And it's not a couple dozen more
>> virtual bytes that are going to matter for
>> a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated
>> usecases are proven wrong by onchain
>> usage of a less efficient construction to achieve the same goal, we could
>> roll-out CTV as an optimization. In
>> the meantime others will have been able to deploy new applications
>> leveraging ANYPREVOUT (Eltoo, blind
>> statechains, etc..[1]).
>>
>>
>> Given the interest in, and demand for, both simple covenants and better
>> offchain protocols it seems to me that
>> BIP118 is a soft fork candidate that could benefit more (if not most of)
>> Bitcoin users.
>> Actually i'd also be interested in knowing if people would oppose the
>> APO-AS part of BIP118, since it enables
>> CTV's features, for the same reason they'd oppose BIP119.
>>
>>
>> [0] That is, to not commit to the other inputs of the transaction (via
>> `sha_sequences` and maybe also
>> `sha_amounts`). Cf
>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
>> .
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220501/515b1504/attachment.html>;

📅 Original date posted:2022-04-29 📝 Original ...

2023-06-07T23:08:03Z

In reply to nevent1q…jr5n
_________________________

📅 Original date posted:2022-04-29
📝 Original message:Here's a summary of the trade-offs I see for using APO as a CTV alternative:

1. The resulting txids are not stable.

CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).

This property could be important for some of the proposed CTV use-cases,
like channel factories.

2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])

3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).

4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).

5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.

If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].

Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).

This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.

shesek

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/08486216/attachment.html>;

📅 Original date posted:2022-04-25 📝 Original ...

2023-06-07T23:08:02Z

In reply to nevent1q…lv38
_________________________

📅 Original date posted:2022-04-25
📝 Original message:darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this

I would be interested to hear more on this.

Is it not necessary because you can exchange and store pre-signed
transactions instead?

What purpose is it not sufficient for? There are some vault designs out
there that are able to achieve interesting properties with CTV, like James
O'Beirne's simple-ctv-vault:

https://github.com/jamesob/simple-ctv-vault
(the basic design expressed in Minsc:
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/cd6fa22e/attachment-0001.html>;

📅 Original date posted:2022-04-25 📝 Original ...

2023-06-07T23:08:01Z

In reply to nevent1q…pzsk
_________________________

📅 Original date posted:2022-04-25
📝 Original message:darosior via bitcoin-dev wrote:

> CTV advocates have been presenting vaults as the flagship usecase.
Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more
virtual bytes that are going to matter for
> a potential vault user.

Some potential vault users looking to store funds for long time periods
(say of decades) might have quantumphobia and prefer to avoid Taproot for
that reason.

One of the arguments presented for not using pubkey hashes in Taproot is
that quantumphobic people could choose to continue using non-Taproot
outputs. Making a feature that's targeted for long-term cold-storage vaults
available on Taproot only might be less ideal in that view.

Cheers
shesek

On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
>
> [0] That is, to not commit to the other inputs of the transaction (via
> `sha_sequences` and maybe also
> `sha_amounts`). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/598ecaae/attachment.html>;