darosior [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-29 📝 Original message:Hi Shesek, > 1. The ...
📅 Original date posted:2022-04-29
📝 Original message:Hi Shesek,
> 1. The resulting txids are not stable.
This is *literally* what the post you are replying to is proposing to solve.
> This property could be important for some of the proposed CTV use-cases, like channel factories.
Hmm? You can't have channel factories without Eltoo. (Well, you can in theory but good luck.)
Maybe you are refering to non-interactive channel creation? The case for stable txids is less strong if wehave APO (and therefore Eltoo). [0]
> 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])
This has been addressed over and over and over again. If a QC is able overnight to spend a large fraction of
the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant (that would eventually become
vulnerable when trying to use it) are worthless.[1]
Sorry for being sarcastic, but at this point it's not fair to use quantum-computer FUD to justify theactivation of CTV over APO, or encourage the use of legacy transactions over Taproot ones.
> 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).
Again, this is what my post discusses. Here are the arguments from my post about why i don't think it's a big deal:
1. You can in this case see CTV as an optimization of (tweaked) APOAS. A lot of us are doubtful about CTV
usecases for real people. So much that it was even proposed to temporarily activate it to see if it would
ever have any real traction! [2]
My point with this post was: what if we do (a slightly tweaked) BIP118, that is otherwise useful. And
if this use of covenants is really getting traction then we can roll out an optimization in the form of
CTV (or better covenants, as we'd have had more research put into it by this time).
2. CTV is mainly sold for its usage inside vaults. While i'm not convinced, a few more vbytes should not
matter for this usecase.
Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25 vbytes).
Aside, you can also use the internal key optimization with APO. But i don't think it's desirable just to save32 WU, as you can't have NUMS-ness then. [3]
> 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).
Are APO signatures more expensive to verify? If not i don't think this should be a reason to constrain us to a
much less useful construction, as the cost for the network of validating signatures already exists today. Evenif it didn't, the tradeoff of cost/usefulness needs to be considered.
> 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).
Yes! And as i mentioned on Twitter also committing to the input index which i forgot to add in the OP here.
While i don't think the specific points are valid, i appreciate your reply and your efforts to explore the
tradeoffs between the two approaches.
Thanks,
Antoine
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[1] https://bitcoin.stackexchange.com/a/91050/101498
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
[3] https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
> 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/54863559/attachment-0001.html>;
📝 Original message:Hi Shesek,
> 1. The resulting txids are not stable.
This is *literally* what the post you are replying to is proposing to solve.
> This property could be important for some of the proposed CTV use-cases, like channel factories.
Hmm? You can't have channel factories without Eltoo. (Well, you can in theory but good luck.)
Maybe you are refering to non-interactive channel creation? The case for stable txids is less strong if wehave APO (and therefore Eltoo). [0]
> 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])
This has been addressed over and over and over again. If a QC is able overnight to spend a large fraction of
the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant (that would eventually become
vulnerable when trying to use it) are worthless.[1]
Sorry for being sarcastic, but at this point it's not fair to use quantum-computer FUD to justify theactivation of CTV over APO, or encourage the use of legacy transactions over Taproot ones.
> 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).
Again, this is what my post discusses. Here are the arguments from my post about why i don't think it's a big deal:
1. You can in this case see CTV as an optimization of (tweaked) APOAS. A lot of us are doubtful about CTV
usecases for real people. So much that it was even proposed to temporarily activate it to see if it would
ever have any real traction! [2]
My point with this post was: what if we do (a slightly tweaked) BIP118, that is otherwise useful. And
if this use of covenants is really getting traction then we can roll out an optimization in the form of
CTV (or better covenants, as we'd have had more research put into it by this time).
2. CTV is mainly sold for its usage inside vaults. While i'm not convinced, a few more vbytes should not
matter for this usecase.
Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25 vbytes).
Aside, you can also use the internal key optimization with APO. But i don't think it's desirable just to save32 WU, as you can't have NUMS-ness then. [3]
> 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).
Are APO signatures more expensive to verify? If not i don't think this should be a reason to constrain us to a
much less useful construction, as the cost for the network of validating signatures already exists today. Evenif it didn't, the tradeoff of cost/usefulness needs to be considered.
> 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).
Yes! And as i mentioned on Twitter also committing to the input index which i forgot to add in the OP here.
While i don't think the specific points are valid, i appreciate your reply and your efforts to explore the
tradeoffs between the two approaches.
Thanks,
Antoine
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[1] https://bitcoin.stackexchange.com/a/91050/101498
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
[3] https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
> 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/54863559/attachment-0001.html>;