Automatically reverting ("transitory") soft forks, e.g. for CTV

> Hi all,
>
> The main criticisms I'm aware of against CTV seem to be along the
> following lines:
>
> 1. Usage, either:
>    a. It won't receive significant real-world usage, or
>    b. It will be used but we'll end up using something better later
> 2. An unused CTV will need to be supported forever, creating extra
> maintenance
>     burden, increasing security surface, and making it harder to evaluate
> later
>     consensus change proposals due to their interactions with CTV
>
> Could those concerns be mitigated by making CTV an automatically
> reverting
> consensus change with an option to renew?  E.g., redefining OP_NOP4 as
> OP_CTV
> for five years from BIP119's activation date and then reverting to
> OP_NOP4.
> If, prior to the end of those five years, a second soft fork was
> activated, it
> could continue enforcing the CTV rules either for another five years or
> permanently.
>
> This would be similar in nature to the soft fork described in BIP50
> where the
> maximum block size was temporarily reduced to address the BDB locks
> issue and
> then allowed to return to its original value.  In Script terms, any use
> of
> OP_CTV would effectively be:
>
>      OP_IF
>        <arguments> OP_CTV
>      OP_ELSE
>        <5 years after activation> OP_CLTV
>      OP_ENDIF
>
> As long as we are absolutely convinced CTV will have no negative effects
> on the
> holders or receivers of non-CTV coins, I think an automatically
> reverting soft
> fork gives us some ability to experiment with new features without
> committing
> ourselves to live with them forever.
>
> The main downsides I can see are:
>
> 1. It creates a big footgun.  Anyone who uses CTV without adequately
> preparing for
>     the reversion could easily lose their money.
>
> 2. Miners would be incentivized to censor spends of the reverting
>     opcode near its reversion date.  E.g., if Alice receives 100 bitcoins
> to a
>     script secured only by OP_CTV and attempts to spend them the day
> before it
>     becomes OP_NOP4, miners might prefer to skip confirming that
> transaction even
>     if it pays a high feerate in favor of spending her 100 bitcoins to
> themselves
>     the next day after reversion.
>
>     The degree to which this is an issue will depend on the diversity of
>     hashrate and the willingness of any large percentage of hashrate to
>     deliberately reorg the chain to remove confirmed transactions.  This
> could be
>     mitigated by having OP_CTV change to OP_RETURN, destroying any
> unspent CTV-only
>     coins so that any censoring miners only benefited from the (hopefully
> slight)
>     decrease in bitcoin currency supply.
>
> 3. A bias towards keeping the change.  Even if it turned out very few
> people
>     really used CTV, I think there would be a bias at the end of five
> years towards
>     "why not just keep it".
>
> 4. The drama doesn't end.  Activating CTV now, or decisively not
> activating it,
>     may bring to an end our frequent discussions about it (though I
> wouldn't
>     count on that).  An automatically reverting soft fork would probably
>     guarantee we'll have further consensus-level discussions about CTV in
> the
>     future.
>
> Thanks for reading.  I'm curious to hear y'alls thoughts,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> The bigger issue with CTV is the miner-decision route. Either CTV has
> community support, or it doesn't. If it does, miners shouldn't have the
> ability to veto it. If it doesn't, miners shouldn't have the ability to
> activate it (making it a 51% attack more than a softfork).

> 1-2 can be mitigated to some extent by encoding an expiry height in the
> address (and pubkey?), and honouring CTV for UTXOs during the active period.
> It might take longer to remove CTV code post-deactivation, but that's simply
> a tradeoff to consider.
>
> The bigger issue with CTV is the miner-decision route. Either CTV has
> community support, or it doesn't. If it does, miners shouldn't have the
> ability to veto it. If it doesn't, miners shouldn't have the ability to
> activate it (making it a 51% attack more than a softfork).
>
> On Thursday 21 April 2022 01:04:53 David A. Harding via bitcoin-dev wrote:
>
>> Hi all,
>>
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to evaluate
>> later
>> consensus change proposals due to their interactions with CTV
>>
>> Could those concerns be mitigated by making CTV an automatically
>> reverting
>> consensus change with an option to renew? E.g., redefining OP_NOP4 as
>> OP_CTV
>> for five years from BIP119's activation date and then reverting to
>> OP_NOP4.
>> If, prior to the end of those five years, a second soft fork was
>> activated, it
>> could continue enforcing the CTV rules either for another five years or
>> permanently.
>>
>> This would be similar in nature to the soft fork described in BIP50
>> where the
>> maximum block size was temporarily reduced to address the BDB locks
>> issue and
>> then allowed to return to its original value. In Script terms, any use
>> of
>> OP_CTV would effectively be:
>>
>> OP_IF
>> <arguments> OP_CTV
>> OP_ELSE
>> <5 years after activation> OP_CLTV
>> OP_ENDIF
>>
>> As long as we are absolutely convinced CTV will have no negative effects
>> on the
>> holders or receivers of non-CTV coins, I think an automatically
>> reverting soft
>> fork gives us some ability to experiment with new features without
>> committing
>> ourselves to live with them forever.
>>
>> The main downsides I can see are:
>>
>> 1. It creates a big footgun. Anyone who uses CTV without adequately
>> preparing for
>> the reversion could easily lose their money.
>>
>> 2. Miners would be incentivized to censor spends of the reverting
>> opcode near its reversion date. E.g., if Alice receives 100 bitcoins
>> to a
>> script secured only by OP_CTV and attempts to spend them the day
>> before it
>> becomes OP_NOP4, miners might prefer to skip confirming that
>> transaction even
>> if it pays a high feerate in favor of spending her 100 bitcoins to
>> themselves
>> the next day after reversion.
>>
>> The degree to which this is an issue will depend on the diversity of
>> hashrate and the willingness of any large percentage of hashrate to
>> deliberately reorg the chain to remove confirmed transactions. This
>> could be
>> mitigated by having OP_CTV change to OP_RETURN, destroying any
>> unspent CTV-only
>> coins so that any censoring miners only benefited from the (hopefully
>> slight)
>> decrease in bitcoin currency supply.
>>
>> 3. A bias towards keeping the change. Even if it turned out very few
>> people
>> really used CTV, I think there would be a bias at the end of five
>> years towards
>> "why not just keep it".
>>
>> 4. The drama doesn't end. Activating CTV now, or decisively not
>> activating it,
>> may bring to an end our frequent discussions about it (though I
>> wouldn't
>> count on that). An automatically reverting soft fork would probably
>> guarantee we'll have further consensus-level discussions about CTV in
>> the
>> future.
>>
>> Thanks for reading. I'm curious to hear y'alls thoughts,
>>
>> -Dave
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?

> Example: Some users are not okay with witness discount in segwit
> transactions
>
> https://nitter.net/giacomozucco/status/1513614380121927682

> @LukeDashjr
>
> > The bigger issue with CTV is the miner-decision route. Either CTV has
> > community support, or it doesn't. If it does, miners shouldn't have the
> > ability to veto it. If it doesn't, miners shouldn't have the ability to
> > activate it (making it a 51% attack more than a softfork).
>
> Agree. UASF client compatible with this speedy trial release for BIP 119
> could be a better way to activate CTV. Users can decide if they prefer
> mining pools to make the decision for them or they want to enforce it
> irrespective of how many mining pools signal for it. I haven't seen any
> arguments against CTV from mining pools yet.

> While reverting Segwit wouldn't be possible, it IS entirely possible to

> additional softfork to either weigh witness data at the full 4 WU/Byte

> (same as other data), or to reduce the total weight limit so as to extend

> witness discount to non-segwit transactions (so scriptSig is similarly
> discounted).

> Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> variant which has no purpose other than to try to sabotage parallel UASF
> efforts.

> > While reverting Segwit wouldn't be possible, it IS entirely possible to
> > do an additional softfork to either weigh witness data at the full 4
> > WU/Byte rate (same as other data), or to reduce the total weight limit so
> > as to extend the witness discount to non-segwit transactions (so scriptSig
> > is similarly discounted).
>
> What if I pre signed a transaction which was valid under the discounted
> weighting, but the increase in weight would make it invalid? This would
> serve to confiscate funds. Let's not do that.

> > Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> > variant which has no purpose other than to try to sabotage parallel UASF
> > efforts.
>
> Why didn't you upstream the code that was used for the actual activation
> into Bitcoin Core in the last year?
>
> In preparing it I just used what was available in Core now, surely the last
> year you could have gotten the appropriate patches done?

> You'd be confiscating your own funds by making an absurd spending

> By this argument, ALL softforks would have to be ruled out.

> > In preparing it I just used what was available in Core now, surely the
> last
> > year you could have gotten the appropriate patches done?
>
> They were done, reviewed, and deployed in time for Taproot. You personally
>
> played a part in sabotaging efforts to get it merged into Core, and
> violating
> the community's trust in it by instead merging your BIP9 ST without
> consensus. Don't play dumb. You have nobody to blame but yourself.
>

> Hi all,
>
> The main criticisms I'm aware of against CTV seem to be along the following lines:
>
> 1. Usage, either:
>    a. It won't receive significant real-world usage, or
>    b. It will be used but we'll end up using something better later
> 2. An unused CTV will need to be supported forever, creating extra maintenance
>     burden, increasing security surface, and making it harder to evaluate later
>     consensus change proposals due to their interactions with CTV
>

> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>>    a. It won't receive significant real-world usage, or
>>    b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>>     burden, increasing security surface, and making it harder to
>> evaluate later
>>     consensus change proposals due to their interactions with CTV
>
> Also "is this even the way we should be going about covenants?"

> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,

> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.

> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.

> On 21.04.2022 04:58, Matt Corallo wrote:
>> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>>> The main criticisms I'm aware of against CTV seem to be along the following lines:
>>>
>>> 1. Usage, either:
>>>    a. It won't receive significant real-world usage, or
>>>    b. It will be used but we'll end up using something better later
>>> 2. An unused CTV will need to be supported forever, creating extra maintenance
>>>     burden, increasing security surface, and making it harder to evaluate later
>>>     consensus change proposals due to their interactions with CTV
>>
>> Also "is this even the way we should be going about covenants?"
>
> I consider this to be a version of point 1b above.  If we find a better way for going about
> covenants, then we'll activate that and let CTV automatically be retired at the end of its five years.
>
> If you still think your point is separate from point 1b, I would appreciate you helping me understand.

>> the Bitcoin technical community (or at least those interested in
>> working on covenants) doesn't even remotely show any signs of
>> consensus around any concrete proposal,
>
> This is also my assessment: neither CTV nor any other proposal currently has enough support to
> warrant a permanent change to the consensus rules.  My question to the list was whether we could use
> a transitory soft fork as a method for collecting real-world usage data about proposals.  E.g., a
> consensus change proposal could proceed along the following idealized path:
>
> - Idea (individual or small group)
> - Publication (probably to this list)
> - Draft specification and implementation
> - Riskless testing (integration tests, signet(s), testnet, etc)
> - Money-at-stake testing (availability on a pegged sidechain, an altcoin similar to Bitcoin, or in
> Bitcoin via a transitory soft fork)
> - Permanent consensus change

> We add things to Bitcoin because (a) there's some demonstrated
> use-cases and intent to use the change (which I think we definitely
> have for covenants, but which only barely, if at all, suggests
> favoring one covenant design over any other)

> (b) because its
> generally considered aligned with Bitcoin's design and goals, based on
> developer and more broad community response

> (c) because the
> technical folks who have/are wiling to spend time working on the
> specific design space think the concrete proposal is the best design
> we have

> , and finally (d) because the implementation is well-reviewed
> and complete.

> I do not see how we can make an argument for any specific covenant
> under (c) here. We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".

> we
> cannot remove the validation code for something ever, really - you
> still want to be able to validate the historical chain

> On 21.04.2022 08:39, Matt Corallo wrote:
>> We add things to Bitcoin because (a) there's some demonstrated
>> use-cases and intent to use the change (which I think we definitely
>> have for covenants, but which only barely, if at all, suggests
>> favoring one covenant design over any other)
>
> I'm unconvinced about CTV's use cases but others have made reasonable claims that it will be used.
> We could argue about this indefinitely, but I would love to give CTV proponents an opportunity to
> prove that a significant number of people would use it.

>> (b) because its
>> generally considered aligned with Bitcoin's design and goals, based on
>> developer and more broad community response
>
> I think CTV fulfills this criteria.  At least, I can't think of any way BIP119 itself
> (notwithstanding activation concerns) violates Bitcoin's designs and goals.

>> (c) because the
>> technical folks who have/are wiling to spend time working on the
>> specific design space think the concrete proposal is the best design
>> we have
>
> This is the criteria that most concerns me.  What if there is no universal best?  For example, I
> mentioned in my previous email that I'm a partisan of OP_CAT+OP_CSFS due to their min-max of
> implementation simplicity versus production flexibility.  But one problem is that spends using them
> would need to contain a lot of witness data.  In my mind, they're the best for experimentation and
> for proving the existence of demand for more optimized constructions.

>> I do not see how we can make an argument for any specific covenant
>> under (c) here. We could just as well be talking about
>> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
>> CTV can probably just as easily use those instead - ie this has
>> nothing to do with "will people use it".
>
> I'm curious how we as a technical community will be able to determine which is the best approach.
> Again, I like starting simple and general, gathering real usage data, and then optimizing for
> demonstrated needs. But the simplest and most general approaches seem to be too general for some
> people (because they enable recursive covenants), seemingly forcing us into looking only at
> application-optimized designs.  In that case, I think the main thing we want to know about these
> narrow proposals for new applications is whether the applications and the proposed consensus changes
> will actually receive significant use.  For that, I think we need some sort of test bed with real
> paying users, and ideally one that is as similar to Bitcoin mainnet as possible.

> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]

> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew?  [...]

> I agree, there is no universal best, probably. But is there a concrete
> listing of a number of use-cases and the different weights of things,
> plus flexibility especially around forward-looking designs?

> You're also writing off [...] a community of
> independent contributors who care about Bitcoin working together to
> make decisions on what is or isn't the "right way to go" [...]. Why are
> you
> suggesting its something that you "don't know how to do"?

> Again, my point *is not* "will people use CTV", I think they will. I
> think they would also use TLUV if that were activated for the exact
> same use-cases. I think they would also use CAT+CSFS if that were what
> was activated, again for the exact same use-cases. Given that, I'm not
> sure how your proposal teaches us anything at all, aside from "yes,
> there was demand for *some* kind of covenant".

> Again, you're writing off the real and nontrivial risk of doing a fork
> to begin with.

> You don't
> mention the lack of recursion in CTV vs CAT+CSFS

> But, if [it's true that "many [...] use cases [...] to use CTV for
> are very long term in nature"], that's presumably incompatible
> with any sort of sunset that's less than many decades away, so doesn't
> seem much better than just having it be available on a signet?

> If sunsetting were a good idea, one way to think about implementing it
> might be to code it as:
>
>   if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
>       !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
>   {
>       EnforceFoo();
>   }

> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.

> We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".

> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> certain usecases (respectively: Eltoo, congestion control, and
> joinpools)

> On 21.04.2022 08:39, Matt Corallo wrote:
> > We add things to Bitcoin because (a) there's some demonstrated
> > use-cases and intent to use the change (which I think we definitely
> > have for covenants, but which only barely, if at all, suggests
> > favoring one covenant design over any other)
>
> I'm unconvinced about CTV's use cases but others have made reasonable
> claims that it will be used.  We could argue about this indefinitely,
> but I would love to give CTV proponents an opportunity to prove that a
> significant number of people would use it.
>
> > (b) because its
> > generally considered aligned with Bitcoin's design and goals, based on
> > developer and more broad community response
>
> I think CTV fulfills this criteria.  At least, I can't think of any way
> BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
> designs and goals.
>
> > (c) because the
> > technical folks who have/are wiling to spend time working on the
> > specific design space think the concrete proposal is the best design
> > we have
>
> This is the criteria that most concerns me.  What if there is no
> universal best?  For example, I mentioned in my previous email that I'm
> a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
> simplicity versus production flexibility.  But one problem is that
> spends using them would need to contain a lot of witness data.  In my
> mind, they're the best for experimentation and for proving the existence
> of demand for more optimized constructions.
>
> OP_TX or OP_TXHASH would likely offer almost as much simplicity and
> flexibility but be more efficient onchain.  Does that make them better
> than OP_CAT+OP_CSFS?  I don't know how to objectively answer that
> question, and I don't feel comfortable with my subjective opinion of
> CAT+CSFS being better than OP_TX.
>
> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> certain usecases (respectively: Eltoo, congestion control, and
> joinpools), providing maximum onchain efficiency for those cases but
> requiring contortions or larger witnesses to accomplish other covenant
> usecases.  Is their increased efficiency better than more general
> constructions like CSFS or TX?  Again, I don't know how to answer that
> question objectively, although subjectively I'm ok with optimized
> constructions for cases of proven demand.
>
> > , and finally (d) because the implementation is well-reviewed
> > and complete.
>
> No comment here; I haven't followed CTV's review progress to know
> whether I'd consider it well enough reviewed or not.
>
> > I do not see how we can make an argument for any specific covenant
> > under (c) here. We could just as well be talking about
> > TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> > CTV can probably just as easily use those instead - ie this has
> > nothing to do with "will people use it".
>
> I'm curious how we as a technical community will be able to determine
> which is the best approach.  Again, I like starting simple and general,
> gathering real usage data, and then optimizing for demonstrated needs.
> But the simplest and most general approaches seem to be too general for
> some people (because they enable recursive covenants), seemingly forcing
> us into looking only at application-optimized designs.  In that case, I
> think the main thing we want to know about these narrow proposals for
> new applications is whether the applications and the proposed consensus
> changes will actually receive significant use.  For that, I think we
> need some sort of test bed with real paying users, and ideally one that
> is as similar to Bitcoin mainnet as possible.
>
> > we
> > cannot remove the validation code for something ever, really - you
> > still want to be able to validate the historical chain
>
> You and Jeremy both brought up this point.  I understand it and I
> should've addressed it better in my OP, but I'm of the opinion that
> reverting to earlier consensus rules gives future developers the
> *option* of dropping no-longer-used consensus code as a practical
> simplification of the same type we've used on several occasions before,
> and which is an optional default in newly started Bitcoin Core nodes for
> over a decade now (i.e. skipping verification of old signatures).  If
> future devs *want* to maintain code from a set of temporary rules used
> millions of blocks ago, that's great, but giving them the option to
> forget about those rules eliminates one of my concerns about making
> consensus changes without fully proven demand for that change.
>
> I just wanted to mention the above in case this discussion comes back to
> serious consideration of a transitory soft fork.  For now, I think we
> can table a debate over validating reverted rules and focus on how we'll
> come to agreement that a particular covenant-related consensus change is
> warranted.
>
> Thanks for your thoughtful response,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> The enumeration of covenants uses here excludes vaulting,
> which I see as far and away the highest utility use for covenants

> > APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> > certain usecases (respectively: Eltoo, congestion control, and
> > joinpools)
>
> The enumeration of covenants uses here excludes vaulting,
> which I see as far and away the highest utility use for covenants given
> that it allows significant derisking of custody for any user of Bitcoin
> interested in holding their own coins (which is debatably redundant
> with a strict definition of "Bitcoin user" ;).
>
> A lot of why I like CTV is the simple fact that it is a low-risk way of
> getting us vaults. That feature in itself is more than enough to
> justify (to me) CTV's added validation complexity, which is very modest
> - in contrast every other covenant proposal I've seen so far.
>
> On Thu, Apr 21, 2022 at 6:28 PM David A. Harding via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> On 21.04.2022 08:39, Matt Corallo wrote:
>> > We add things to Bitcoin because (a) there's some demonstrated
>> > use-cases and intent to use the change (which I think we definitely
>> > have for covenants, but which only barely, if at all, suggests
>> > favoring one covenant design over any other)
>>
>> I'm unconvinced about CTV's use cases but others have made reasonable
>> claims that it will be used.  We could argue about this indefinitely,
>> but I would love to give CTV proponents an opportunity to prove that a
>> significant number of people would use it.
>>
>> > (b) because its
>> > generally considered aligned with Bitcoin's design and goals, based on
>> > developer and more broad community response
>>
>> I think CTV fulfills this criteria.  At least, I can't think of any way
>> BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
>> designs and goals.
>>
>> > (c) because the
>> > technical folks who have/are wiling to spend time working on the
>> > specific design space think the concrete proposal is the best design
>> > we have
>>
>> This is the criteria that most concerns me.  What if there is no
>> universal best?  For example, I mentioned in my previous email that I'm
>> a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
>> simplicity versus production flexibility.  But one problem is that
>> spends using them would need to contain a lot of witness data.  In my
>> mind, they're the best for experimentation and for proving the existence
>> of demand for more optimized constructions.
>>
>> OP_TX or OP_TXHASH would likely offer almost as much simplicity and
>> flexibility but be more efficient onchain.  Does that make them better
>> than OP_CAT+OP_CSFS?  I don't know how to objectively answer that
>> question, and I don't feel comfortable with my subjective opinion of
>> CAT+CSFS being better than OP_TX.
>>
>> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
>> certain usecases (respectively: Eltoo, congestion control, and
>> joinpools), providing maximum onchain efficiency for those cases but
>> requiring contortions or larger witnesses to accomplish other covenant
>> usecases.  Is their increased efficiency better than more general
>> constructions like CSFS or TX?  Again, I don't know how to answer that
>> question objectively, although subjectively I'm ok with optimized
>> constructions for cases of proven demand.
>>
>> > , and finally (d) because the implementation is well-reviewed
>> > and complete.
>>
>> No comment here; I haven't followed CTV's review progress to know
>> whether I'd consider it well enough reviewed or not.
>>
>> > I do not see how we can make an argument for any specific covenant
>> > under (c) here. We could just as well be talking about
>> > TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
>> > CTV can probably just as easily use those instead - ie this has
>> > nothing to do with "will people use it".
>>
>> I'm curious how we as a technical community will be able to determine
>> which is the best approach.  Again, I like starting simple and general,
>> gathering real usage data, and then optimizing for demonstrated needs.
>> But the simplest and most general approaches seem to be too general for
>> some people (because they enable recursive covenants), seemingly forcing
>> us into looking only at application-optimized designs.  In that case, I
>> think the main thing we want to know about these narrow proposals for
>> new applications is whether the applications and the proposed consensus
>> changes will actually receive significant use.  For that, I think we
>> need some sort of test bed with real paying users, and ideally one that
>> is as similar to Bitcoin mainnet as possible.
>>
>> > we
>> > cannot remove the validation code for something ever, really - you
>> > still want to be able to validate the historical chain
>>
>> You and Jeremy both brought up this point.  I understand it and I
>> should've addressed it better in my OP, but I'm of the opinion that
>> reverting to earlier consensus rules gives future developers the
>> *option* of dropping no-longer-used consensus code as a practical
>> simplification of the same type we've used on several occasions before,
>> and which is an optional default in newly started Bitcoin Core nodes for
>> over a decade now (i.e. skipping verification of old signatures).  If
>> future devs *want* to maintain code from a set of temporary rules used
>> millions of blocks ago, that's great, but giving them the option to
>> forget about those rules eliminates one of my concerns about making
>> consensus changes without fully proven demand for that change.
>>
>> I just wanted to mention the above in case this discussion comes back to
>> serious consideration of a transitory soft fork.  For now, I think we
>> can table a debate over validating reverted rules and focus on how we'll
>> come to agreement that a particular covenant-related consensus change is
>> warranted.
>>
>> Thanks for your thoughtful response,
>>
>> -Dave
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

> This vault design (https://github.com/jamesob/simple-ctv-vault)
> is a good benchmark for evaluating covenant proposals because it's (i)
> simple and (ii) has high utility for many users of Bitcoin. I would
> love to see it implemented in one or all of these alternatives, but I
> am almost certain no one will do it in the next few months because the
> implementations, tooling, and in some cases even complete
> specifications do not exist.
>

>  > There are at least three or four separate covenants designs that have
>  > been posted to this list, and I don't see why we're even remotely
>  > talking about a specific one as something to move forward with at
>  > this point.
>
> To my knowledge none of these other proposals (drafts, really) have
> actual implementations let alone the many sample usages that exist for
> CTV.

> Given that the "covenants" discussion has been ongoing for years
> now, I think the lack of other serious proposals is indicative of the
> difficulty inherent in coming up with a preferable alternative to CTV.

> CTV is about as simple a covenant system as can be devised - its limits
> relative to more "general" covenant designs notwithstanding.
> The level of review around CTV's design is well beyond the other
> sketches for possible designs that this list has seen.

> [Rearranging Matt's text in my reply so my nitpicks come last.]
>
> On 21.04.2022 13:02, Matt Corallo wrote:
>> I agree, there is no universal best, probably. But is there a concrete
>> listing of a number of use-cases and the different weights of things,
>> plus flexibility especially around forward-looking designs?
>
> I'm sure we could make a nice list of covenant usecases, but I don't know how we would assign
> reasonable objective weights to the different things purely through group foresight.  I know I'm
> skeptical about congestion control and enthusiastic about joinpools---but I've talked to developers
> I respect who've had the opposite opinions from me about those things.  The best way I know of to
> reconcile our differing opinions is to see what real Bitcoin users actually pay for.  But to do
> that, I think they must have a way to use covenants in something like the production environment.

>> You're also writing off [...] a community of
>> independent contributors who care about Bitcoin working together to
>> make decisions on what is or isn't the "right way to go" [...]. Why are you
>> suggesting its something that you "don't know how to do"?
>
> You said we should use the best design.  I said the different designs optimize for different things,
> so it's unlikely that there's an objective best.  That implies to me that we either need to choose a
> winner (yuck) or we need to implement more than one of the designs.  In either of those cases,
> choosing what to implement would benefit from data about how much the thing will be used and how
> much users will pay for it in fees.

>> Again, you're writing off the real and nontrivial risk of doing a fork
>> to begin with.
>
> I agree this risk exists and it isn't my intention to write it off---my OP did say "we [must be]
> absolutely convinced CTV will have no negative effects on the holders or receivers of non-CTV
> coins."  I haven't been focusing on this in my replies because I think the other issues we've been
> discussing are more significant.  If we were to get everyone to agree to do a transitory soft fork,
> I think the safety concerns related to a CTV soft fork could be mitigated the same way we've
> mitigated them for previous soft forks: heaps of code review/testing and making sure a large part of
> the active community supports the change.

>
>
> On 4/21/22 6:20 PM, David A. Harding wrote:
> > [Rearranging Matt's text in my reply so my nitpicks come last.]
> >
> > On 21.04.2022 13:02, Matt Corallo wrote:
> >> I agree, there is no universal best, probably. But is there a concrete
> >> listing of a number of use-cases and the different weights of things,
> >> plus flexibility especially around forward-looking designs?
> >
> > I'm sure we could make a nice list of covenant usecases, but I don't
> know how we would assign
> > reasonable objective weights to the different things purely through
> group foresight.  I know I'm
> > skeptical about congestion control and enthusiastic about
> joinpools---but I've talked to developers
> > I respect who've had the opposite opinions from me about those things.
> The best way I know of to
> > reconcile our differing opinions is to see what real Bitcoin users
> actually pay for.  But to do
> > that, I think they must have a way to use covenants in something like
> the production environment.
>
> To get good data for this kind of question you'd need much longer than
> five years, sadly. As we've
> seen over and over again in Bitcoin deploying very nontrivial things takes
> at least five years,
> often more. While vaults may be deployed relatively more quickly, the fact
> that we haven't seen
> (AFAIK) *anyone* deploy some of the key-deletion-based vault designs that
> have been floating around
> for some time is indication that even that probably wouldn't be deployed
> quickly.
>
> >> You're also writing off [...] a community of
> >> independent contributors who care about Bitcoin working together to
> >> make decisions on what is or isn't the "right way to go" [...]. Why are
> you
> >> suggesting its something that you "don't know how to do"?
> >
> > You said we should use the best design.  I said the different designs
> optimize for different things,
> > so it's unlikely that there's an objective best.  That implies to me
> that we either need to choose a
> > winner (yuck) or we need to implement more than one of the designs.  In
> either of those cases,
> > choosing what to implement would benefit from data about how much the
> thing will be used and how
> > much users will pay for it in fees.
>
> I agree, there is no objective "best" design. But we can sill explore
> design tradeoffs and utility
> for different classes of covenants. I've seen relatively little of this so
> far, and from what I have
> seen its not been clear that CTV is really a good option, sadly.
>
>
> >> Again, you're writing off the real and nontrivial risk of doing a fork
> >> to begin with.
> >
> > I agree this risk exists and it isn't my intention to write it off---my
> OP did say "we [must be]
> > absolutely convinced CTV will have no negative effects on the holders or
> receivers of non-CTV
> > coins."  I haven't been focusing on this in my replies because I think
> the other issues we've been
> > discussing are more significant.  If we were to get everyone to agree to
> do a transitory soft fork,
> > I think the safety concerns related to a CTV soft fork could be
> mitigated the same way we've
> > mitigated them for previous soft forks: heaps of code review/testing and
> making sure a large part of
> > the active community supports the change.
>
> I'm not sure I made my point here clear - the nontrivial and real risk I
> was referring to was not
> avoidable with "moar code review" or "careful analysis to make sure the
> proposed fork doesn't cause
> damage". I mean issues that keep cropping up in many changes like "people
> start threatening to run a
> fork-causing client" or "some miners aren't validating blocks and end up
> creating a fork" or "some
> people forget to upgrade and follow such a fork" or..... there's lots and
> lots of risks to a doing a
> fork that come from the process and nature of forks, that have nothing to
> do with the actual details
> of the fork itself.
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

>> There are at least three or four separate covenants designs that have
>>> been posted to this list, and I don't see why we're even remotely
>>> talking about a specific one as something to move forward with at
>>> this point.
>>
>>> To my knowledge none of these other proposals (drafts, really) have
>>> actual implementations let alone the many sample usages that exist for
>> CTV.

> You can fix this! Don't point to something you can easily remedy in the > short-term as an argument
> for or against something in the long-term.

> 1. It creates a big footgun.  Anyone who uses CTV without adequately

> Hi all,
>
> The main criticisms I'm aware of against CTV seem to be along the
> following lines:
>
> 1. Usage, either:
>    a. It won't receive significant real-world usage, or
>    b. It will be used but we'll end up using something better later
> 2. An unused CTV will need to be supported forever, creating extra
> maintenance
>     burden, increasing security surface, and making it harder to evaluate
> later
>     consensus change proposals due to their interactions with CTV
>
> Could those concerns be mitigated by making CTV an automatically
> reverting
> consensus change with an option to renew?  E.g., redefining OP_NOP4 as
> OP_CTV
> for five years from BIP119's activation date and then reverting to
> OP_NOP4.
> If, prior to the end of those five years, a second soft fork was
> activated, it
> could continue enforcing the CTV rules either for another five years or
> permanently.
>
> This would be similar in nature to the soft fork described in BIP50
> where the
> maximum block size was temporarily reduced to address the BDB locks
> issue and
> then allowed to return to its original value.  In Script terms, any use
> of
> OP_CTV would effectively be:
>
>      OP_IF
>        <arguments> OP_CTV
>      OP_ELSE
>        <5 years after activation> OP_CLTV
>      OP_ENDIF
>
> As long as we are absolutely convinced CTV will have no negative effects
> on the
> holders or receivers of non-CTV coins, I think an automatically
> reverting soft
> fork gives us some ability to experiment with new features without
> committing
> ourselves to live with them forever.
>
> The main downsides I can see are:
>
> 1. It creates a big footgun.  Anyone who uses CTV without adequately
> preparing for
>     the reversion could easily lose their money.
>
> 2. Miners would be incentivized to censor spends of the reverting
>     opcode near its reversion date.  E.g., if Alice receives 100 bitcoins
> to a
>     script secured only by OP_CTV and attempts to spend them the day
> before it
>     becomes OP_NOP4, miners might prefer to skip confirming that
> transaction even
>     if it pays a high feerate in favor of spending her 100 bitcoins to
> themselves
>     the next day after reversion.
>
>     The degree to which this is an issue will depend on the diversity of
>     hashrate and the willingness of any large percentage of hashrate to
>     deliberately reorg the chain to remove confirmed transactions.  This
> could be
>     mitigated by having OP_CTV change to OP_RETURN, destroying any
> unspent CTV-only
>     coins so that any censoring miners only benefited from the (hopefully
> slight)
>     decrease in bitcoin currency supply.
>
> 3. A bias towards keeping the change.  Even if it turned out very few
> people
>     really used CTV, I think there would be a bias at the end of five
> years towards
>     "why not just keep it".
>
> 4. The drama doesn't end.  Activating CTV now, or decisively not
> activating it,
>     may bring to an end our frequent discussions about it (though I
> wouldn't
>     count on that).  An automatically reverting soft fork would probably
>     guarantee we'll have further consensus-level discussions about CTV in
> the
>     future.
>
> Thanks for reading.  I'm curious to hear y'alls thoughts,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> If an attacker steals the hot key, then they have the option to simply

> On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> This vault design (https://github.com/jamesob/simple-ctv-vault)
>> is a good benchmark for evaluating covenant proposals because it's (i)
>> simple and (ii) has high utility for many users of Bitcoin. I would
>> love to see it implemented in one or all of these alternatives, but I
>> am almost certain no one will do it in the next few months because the
>> implementations, tooling, and in some cases even complete
>> specifications do not exist.
>>
>
> Quoting from the link above:
> Detecting theft
>
> This unvault step is critical because it allows us to detect unexpected
> behavior. If an attacker had stolen our hot wallet keys, their only choice
> to succeed in the theft is to trigger an unvault.
>
>
> It's not the attackers *only choice to succeed*.  If an attacker steals
> the hot key, then they have the option to simply wait for the user to
> unvault their funds of their own accord and then race / outspend the users
> transaction with their own.  Indeed, this is what we expect would happen in
> the dark forest.
>
> A key feature of the MES vault design is that the destination address is
> included, and committed to, by the unvaulting step.  However, this can only
> be achieved with a less constrained design for covenants.
>
> I suppose I can see that the damage from a hot key theft could be more
> contained under some circumstances using a CTV vault, but let us not
> overstate the value of the CTV vault.
>
> And that's not even mentioning the issues already noted by the document
> regarding fee management, which would likely also benefit from a less
> constrained design for covenants.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> > If an attacker steals the hot key, then they have the option to simply
> wait for the user to unvault their funds
>
> This is definitely true. Its kind of a problem with most vault proposals.
> Its one of the primary reasons I designed an alternative proposal
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults>. The
> OP_BEFOREBLOCKVERIFY opcode I proposed solves this security hole by
> automatically swapping control of the UTXO over to the intended recipient
> after a timeout. Alternatively, if OP_BBV weren't available, OP_POS in
> conjunction with OP_CD could encode things such that the transaction
> with the hot key could only spend to the intended recipient.
>
> I'm curious if there are any other covenant proposals that have a solution
> to that problem. I'm not aware of any that do other than my proposal.
>

> It's not the attackers *only choice to succeed*.  If an attacker steals the hot key, then they have
> the option to simply wait for the user to unvault their funds of their own accord and then race /
> outspend the users transaction with their own.  Indeed, this is what we expect would happen in the
> dark forest.

> And that's not even mentioning the issues already noted by the document regarding fee management,
> which would likely also benefit from a less constrained design for covenants.

> Still trying to make sure I understand this concern, let me know if I get
> this all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > It's not the attackers *only choice to succeed*.  If an attacker steals
> the hot key, then they have
> > the option to simply wait for the user to unvault their funds of their
> own accord and then race /
> > outspend the users transaction with their own.  Indeed, this is what we
> expect would happen in the
> > dark forest.
>
> Right, a key security assumption of the CTV-based vaults would be that you
> MUST NOT EVER withdraw
> more in one go than your hot wallet risk tolerance, but given that your
> attack isn't any worse than
> simply stealing the hot wallet key immediately after a withdraw.
>
> It does have the drawback that if you ever get a hot wallet key stole you
> have to rotate all of your
> CTV outputs and your CTV outputs must never be any larger than your hot
> wallet risk tolerance
> amount, both of which are somewhat frustrating limitations, but not
> security limitations, only
> practical ones.
>
> > And that's not even mentioning the issues already noted by the document
> regarding fee management,
> > which would likely also benefit from a less constrained design for
> covenants.
>
> Of course I've always been in favor of a less constrained covenants design
> from day one for ten
> reasons, but that's a whole other rabbit hole :)
>

>@DavidHarding
>
>Interesting proposal to revert consensus changes. Is it possible to do this for soft forks that are already activated?
>
>Example: Some users are not okay with witness discount in segwit transactions
>
>https://nitter.net/giacomozucco/status/1513614380121927682

>  both of which are somewhat frustrating limitations, but not security

> the original MES vault .. commits to the destination address during

> What ways can we build a secured vault that commits to the destination

> Are there elegant ways of building secure vaults by using CTV plus

> Okay, Matt explained to me the intended application of CTV vaults off
> list, so I have a better understanding now.
>
> The CTV vault scheme is designed as an improvement over the traditional
> management of hot-wallets and cold-wallets.  The CTV vault is logically on
> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
> the hot wallet after the unvaulting delay.  In this case, the hot wallet
> funds are always at risk, so it isn't unexpected that those funds could be
> stolen.  After all, that is how hot wallets are today.  The advantage is
> that funds can be moved from the "cold" side without needing to dig out the
> cold keys.
>
> The MES vault scheme applies to a different scenario.  In the MES case it
> is the hot funds are inside the vault, and it is the hot key that unvaults
> the funds and sends them to *customer's addresses* after a delay.  If the
> hot-key is used in any unauthorised way, then funds can be sent to the
> address of the cold key (the MES vault actually does something fancy in
> case of recovery, but it could be adapted to simply send funds to a cold
> wallet).
>
> The MES vault lie somewhere between "better" and "different" when compared
> to the CTV vault.  If one is unwilling to use the MES vault on the hot side
> and have every withdrawl vetted, then, while you could use the MES design
> on the cold side like the CTV vault, it wouldn't really offer you any
> advantages over a CTV vault.  However, if you are interested in managing
> all your payments through a vault (as I've been imagining) then the CTV
> vault comes across as ineffective when compared to an MES style vault.
>
> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists@mattcorallo•com>
> wrote:
>
>> Still trying to make sure I understand this concern, let me know if I get
>> this all wrong.
>>
>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>> > It's not the attackers *only choice to succeed*.  If an attacker steals
>> the hot key, then they have
>> > the option to simply wait for the user to unvault their funds of their
>> own accord and then race /
>> > outspend the users transaction with their own.  Indeed, this is what we
>> expect would happen in the
>> > dark forest.
>>
>> Right, a key security assumption of the CTV-based vaults would be that
>> you MUST NOT EVER withdraw
>> more in one go than your hot wallet risk tolerance, but given that your
>> attack isn't any worse than
>> simply stealing the hot wallet key immediately after a withdraw.
>>
>> It does have the drawback that if you ever get a hot wallet key stole you
>> have to rotate all of your
>> CTV outputs and your CTV outputs must never be any larger than your hot
>> wallet risk tolerance
>> amount, both of which are somewhat frustrating limitations, but not
>> security limitations, only
>> practical ones.
>>
>> > And that's not even mentioning the issues already noted by the document
>> regarding fee management,
>> > which would likely also benefit from a less constrained design for
>> covenants.
>>
>> Of course I've always been in favor of a less constrained covenants
>> design from day one for ten
>> reasons, but that's a whole other rabbit hole :)
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> If you unvault an output to your hot wallet, the thief could be lying in

> However, if you compare it against a multisig wallet (eg 2 of 3), you can

> @Matt
> >  both of which are somewhat frustrating limitations, but not security
> limitations, only practical ones.
>
> So I think the first limitation you mentioned (that if your hot wallet's
> key gets stolen you need) can be legitimately considered a security
> limitation. Not because you need to rotate your keys, but because you might
> *not know* your hot wallet key has been stolen. If you unvault an output to
> your hot wallet, the thief could be lying in wait, ready to steal those
> funds upon them landing. At that point, you would then know your hot wallet
> key was compromised and could rotate your vault keys in order to prevent
> further theft. However, the fact that there is a clear theft vulnerability
> is something I would say should be considered a "security limitation".
>
> As you mentioned, this is of course also a security limitation of a hot
> wallet, so this setup definitely has a lot of advantages over a simple hot
> wallet. However, if you compare it against a multisig wallet (eg 2 of 3),
> you can see that while theft of a single key would never result in any
> theft in that setup, it could in a CTV vault. The other trade offs there
> are ones of practicality and convenience.
>
> This isn't to say a CTV vault wouldn't be useful. Just that it has
> significant trade offs.
>
> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> *might* do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be
> specified as a number indicating the number of stack items in the pattern,
> followed by that number of stack items. If that's how it is done, I can see
> the user inputting an intended destination script (corresponding to the
> intended destination address) which would then be somehow rotated in to the
> right spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>
> However, my assumptions might be incorrect. If you think OP_COV would be a
> useful opcode, I would encourage you to write up a complete specification.
>
> > What ways can we build a secured vault that commits to the destination
> address?
>
> Some kind of passed-through state allows doing this. With OP_COV (if my
> assumptions above are correct), the intended destination can be passed
> through the output script pattern(s). With my own proposed
> op_pushoutputstack
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>,
> state is passed as an attachment on the output more directly. Curious what
> you think about that proposal.
>
> > Are there elegant ways of building secure vaults by using CTV plus
> something else.
>
> Since CTV predefines all the transactions that can happen under its
> control, passed state like this can't help because any dynamic state would
> change the template and render the CTV transaction invalid. I don't see any
> way of solving this problem for CTV.
>
> I'm curious how you think op_cat could enable this with CTV (other than
> the cat+schnorr tricks that don't require CTV at all).
>
>
>
> On Sat, Apr 23, 2022 at 2:31 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> Okay, Matt explained to me the intended application of CTV vaults off
>> list, so I have a better understanding now.
>>
>> The CTV vault scheme is designed as an improvement over the traditional
>> management of hot-wallets and cold-wallets.  The CTV vault is logically on
>> the "cold-side" and lets funds be sent from the "cold" side to *one's own*
>> the hot wallet after the unvaulting delay.  In this case, the hot wallet
>> funds are always at risk, so it isn't unexpected that those funds could be
>> stolen.  After all, that is how hot wallets are today.  The advantage is
>> that funds can be moved from the "cold" side without needing to dig out the
>> cold keys.
>>
>> The MES vault scheme applies to a different scenario.  In the MES case it
>> is the hot funds are inside the vault, and it is the hot key that unvaults
>> the funds and sends them to *customer's addresses* after a delay.  If the
>> hot-key is used in any unauthorised way, then funds can be sent to the
>> address of the cold key (the MES vault actually does something fancy in
>> case of recovery, but it could be adapted to simply send funds to a cold
>> wallet).
>>
>> The MES vault lie somewhere between "better" and "different" when
>> compared to the CTV vault.  If one is unwilling to use the MES vault on the
>> hot side and have every withdrawl vetted, then, while you could use the MES
>> design on the cold side like the CTV vault, it wouldn't really offer you
>> any advantages over a CTV vault.  However, if you are interested in
>> managing all your payments through a vault (as I've been imagining) then
>> the CTV vault comes across as ineffective when compared to an MES style
>> vault.
>>
>> On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists@mattcorallo•com>
>> wrote:
>>
>>> Still trying to make sure I understand this concern, let me know if I
>>> get this all wrong.
>>>
>>> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
>>> > It's not the attackers *only choice to succeed*.  If an attacker
>>> steals the hot key, then they have
>>> > the option to simply wait for the user to unvault their funds of their
>>> own accord and then race /
>>> > outspend the users transaction with their own.  Indeed, this is what
>>> we expect would happen in the
>>> > dark forest.
>>>
>>> Right, a key security assumption of the CTV-based vaults would be that
>>> you MUST NOT EVER withdraw
>>> more in one go than your hot wallet risk tolerance, but given that your
>>> attack isn't any worse than
>>> simply stealing the hot wallet key immediately after a withdraw.
>>>
>>> It does have the drawback that if you ever get a hot wallet key stole
>>> you have to rotate all of your
>>> CTV outputs and your CTV outputs must never be any larger than your hot
>>> wallet risk tolerance
>>> amount, both of which are somewhat frustrating limitations, but not
>>> security limitations, only
>>> practical ones.
>>>
>>> > And that's not even mentioning the issues already noted by the
>>> document regarding fee management,
>>> > which would likely also benefit from a less constrained design for
>>> covenants.
>>>
>>> Of course I've always been in favor of a less constrained covenants
>>> design from day one for ten
>>> reasons, but that's a whole other rabbit hole :)
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
> *might* do that.
>
> One possibility is that the intended destination is predetermined and
> hardcoded. This wouldn't be very useful, and also wouldn't be different
> than how CTV could do it, so I assume that isn't what you envisioned this
> doing.
>
> I can imagine instead that the definition of the pattern could be
> specified as a number indicating the number of stack items in the pattern,
> followed by that number of stack items. If that's how it is done, I can see
> the user inputting an intended destination script (corresponding to the
> intended destination address) which would then be somehow rotated in to the
> right spot within the pattern, allowing the pattern to specify the coins
> eventually reaching an address with that script. However, this could be
> quite cumbersome, and would require fully specifying the scripts along the
> covenant pathways leading to a fair amount of information duplication
> (since scripts must be specified both in the covenant and in spending the
> subsequent output). Both of these things would seem to make OP_COV in
> practice quite an expensive opcode to spend with. It also means that, since
> the transactor must fully specify the script, its not possible to take
> advantage of taproot's script hiding capabilities (were it to send to a
> taproot address).
>

> OP_PUBKEY, and OP_PUBKEYHASH as wildcards

> You can have a CTV vault where the hot key signer is a multisig to get

> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail•com>
> wrote:
>
>> @Russel
>> > the original MES vault .. commits to the destination address during
>> unvaulting
>>
>> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
>> for me to understand that it does that. However, I can imagine how it
>> *might* do that.
>>
>> One possibility is that the intended destination is predetermined and
>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>> than how CTV could do it, so I assume that isn't what you envisioned this
>> doing.
>>
>> I can imagine instead that the definition of the pattern could be
>> specified as a number indicating the number of stack items in the pattern,
>> followed by that number of stack items. If that's how it is done, I can see
>> the user inputting an intended destination script (corresponding to the
>> intended destination address) which would then be somehow rotated in to the
>> right spot within the pattern, allowing the pattern to specify the coins
>> eventually reaching an address with that script. However, this could be
>> quite cumbersome, and would require fully specifying the scripts along the
>> covenant pathways leading to a fair amount of information duplication
>> (since scripts must be specified both in the covenant and in spending the
>> subsequent output). Both of these things would seem to make OP_COV in
>> practice quite an expensive opcode to spend with. It also means that, since
>> the transactor must fully specify the script, its not possible to take
>> advantage of taproot's script hiding capabilities (were it to send to a
>> taproot address).
>>
>
> So my understanding is that the COV proposal in MES lets you check that
> the output's scriptPubKey matches the corresponding script item from the
> stack, but the script item's value additionally allows some wildcard
> values.  In particular, it makes use of the otherwise reserved opcodes
> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
> 32-byte or 20-byte push value.
>
> If you just used COV by itself, then these wildcards would be third-party
> malleable, but you also have to sign the transaction with the hot wallet
> key, which removes the malleability.
>
> No need to rotate anything into place.
>
> I hope this makes sense.
>

> The whole point of a wallet vault is that you can get the security of a

> @Russell
> > OP_PUBKEY, and OP_PUBKEYHASH as wildcards
>
> Ah I see. Very interesting. Thanks for clarifying.
>
> @Nadav
> > You can have a CTV vault where the hot key signer is a multisig to get
> the advantages of both.
>
> Yes, you can create a CTV vault setup where you unvault to a multisig
> wallet, but you don't get the advantages of both. Rather you get none of
> the advantages and still have all the downsides you get with a multisig
> wallet. The whole point of a wallet vault is that you can get the security
> of a multisig wallet without having to sign using as many keys.
>
> On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <roconnor@blockstream•com>
> wrote:
>
>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail•com>
>> wrote:
>>
>>> @Russel
>>> > the original MES vault .. commits to the destination address during
>>> unvaulting
>>>
>>> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
>>> for me to understand that it does that. However, I can imagine how it
>>> *might* do that.
>>>
>>> One possibility is that the intended destination is predetermined and
>>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>>> than how CTV could do it, so I assume that isn't what you envisioned this
>>> doing.
>>>
>>> I can imagine instead that the definition of the pattern could be
>>> specified as a number indicating the number of stack items in the pattern,
>>> followed by that number of stack items. If that's how it is done, I can see
>>> the user inputting an intended destination script (corresponding to the
>>> intended destination address) which would then be somehow rotated in to the
>>> right spot within the pattern, allowing the pattern to specify the coins
>>> eventually reaching an address with that script. However, this could be
>>> quite cumbersome, and would require fully specifying the scripts along the
>>> covenant pathways leading to a fair amount of information duplication
>>> (since scripts must be specified both in the covenant and in spending the
>>> subsequent output). Both of these things would seem to make OP_COV in
>>> practice quite an expensive opcode to spend with. It also means that, since
>>> the transactor must fully specify the script, its not possible to take
>>> advantage of taproot's script hiding capabilities (were it to send to a
>>> taproot address).
>>>
>>
>> So my understanding is that the COV proposal in MES lets you check that
>> the output's scriptPubKey matches the corresponding script item from the
>> stack, but the script item's value additionally allows some wildcard
>> values.  In particular, it makes use of the otherwise reserved opcodes
>> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
>> 32-byte or 20-byte push value.
>>
>> If you just used COV by itself, then these wildcards would be third-party
>> malleable, but you also have to sign the transaction with the hot wallet
>> key, which removes the malleability.
>>
>> No need to rotate anything into place.
>>
>> I hope this makes sense.
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

>  the point of a vault is the ability to keep your primary wallet keys in

> > The whole point of a wallet vault is that you can get the security of a
> multisig wallet without having to sign using as many keys.
>
> In my view, the point of a vault is the ability to keep your primary
> wallet keys in *highly* deep cold storage (e.g. metal backup only, not
> loaded on any HW wallets, with geographically distributed shares and a slow
> cumbersome process for collecting them), which is made possible because
> you're not supposed to actually need to use these keys, except for the
> extraordinary (typically once or twice in a lifetime?) circumstances of
> theft.
>
> The user can then use a warmer model for the keys they use more frequently
> for the covenant-encumbered two-step spending. But these warmer keys can
> themselves also be cold and/or multi-sig, yet more accessible. For example,
> a 2-of-2 with standard hardware wallets you have within reach in your
> apartment.
>
> So if you have a cold wallet that you anticipate having to access once
> every, say, 2-3 months, no matter what scheme you currently use to secure
> it, you can improve your overall security by using that same scheme for
> securing the covenant-encumbered keys, then use a colder more secure scheme
> for your primary keys under the assumption that you'll only have to access
> them at most once every several years.
>
> IIUC what you were describing is that you can use your regular multisig
> scheme for the primary cold wallet keys, and a 1-of-1 for the
> covenant-encumbered keys (which can even be hot on your phone etc).
>
> Both approaches are valid, one gets you more security while the other gets
> you more convenience. And there is of course a whole range of options that
> can be chosen in between that gets you some of both.
>
> shesek
>
> On Wed, Apr 27, 2022 at 11:09 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> @Russell
>> > OP_PUBKEY, and OP_PUBKEYHASH as wildcards
>>
>> Ah I see. Very interesting. Thanks for clarifying.
>>
>> @Nadav
>> > You can have a CTV vault where the hot key signer is a multisig to get
>> the advantages of both.
>>
>> Yes, you can create a CTV vault setup where you unvault to a multisig
>> wallet, but you don't get the advantages of both. Rather you get none of
>> the advantages and still have all the downsides you get with a multisig
>> wallet. The whole point of a wallet vault is that you can get the security
>> of a multisig wallet without having to sign using as many keys.
>>
>> On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <
>> roconnor@blockstream•com> wrote:
>>
>>> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud@gmail•com>
>>> wrote:
>>>
>>>> @Russel
>>>> > the original MES vault .. commits to the destination address during
>>>> unvaulting
>>>>
>>>> I see. Looking at the MES16 paper, OP_COV isn't described clearly
>>>> enough for me to understand that it does that. However, I can imagine how
>>>> it *might* do that.
>>>>
>>>> One possibility is that the intended destination is predetermined and
>>>> hardcoded. This wouldn't be very useful, and also wouldn't be different
>>>> than how CTV could do it, so I assume that isn't what you envisioned this
>>>> doing.
>>>>
>>>> I can imagine instead that the definition of the pattern could be
>>>> specified as a number indicating the number of stack items in the pattern,
>>>> followed by that number of stack items. If that's how it is done, I can see
>>>> the user inputting an intended destination script (corresponding to the
>>>> intended destination address) which would then be somehow rotated in to the
>>>> right spot within the pattern, allowing the pattern to specify the coins
>>>> eventually reaching an address with that script. However, this could be
>>>> quite cumbersome, and would require fully specifying the scripts along the
>>>> covenant pathways leading to a fair amount of information duplication
>>>> (since scripts must be specified both in the covenant and in spending the
>>>> subsequent output). Both of these things would seem to make OP_COV in
>>>> practice quite an expensive opcode to spend with. It also means that, since
>>>> the transactor must fully specify the script, its not possible to take
>>>> advantage of taproot's script hiding capabilities (were it to send to a
>>>> taproot address).
>>>>
>>>
>>> So my understanding is that the COV proposal in MES lets you check that
>>> the output's scriptPubKey matches the corresponding script item from the
>>> stack, but the script item's value additionally allows some wildcard
>>> values.  In particular, it makes use of the otherwise reserved opcodes
>>> OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say,
>>> 32-byte or 20-byte push value.
>>>
>>> If you just used COV by itself, then these wildcards would be
>>> third-party malleable, but you also have to sign the transaction with the
>>> hot wallet key, which removes the malleability.
>>>
>>> No need to rotate anything into place.
>>>
>>> I hope this makes sense.
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>