[bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding]

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr]

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[alicexbt]

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

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

Sent with [ProtonMail](https://protonmail.com/) secure email.
------- Original Message -------
On Thursday, April 21st, 2022 at 7:35 AM, Luke Dashjr via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:

> 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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr]

On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> @DavidHarding
>
> Interesting proposal to revert consensus changes. Is it possible to do this
> for soft forks that are already activated?

Generally, no. Reverting a softfork without a built-in expiry would be a 
hardfork.

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

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

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

We had that for Taproot, and now certain people are trying to say Speedy Trial 
activated Taproot rather than the BIP8 client, and otherwise creating 
confusion and ambiguity.

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.

At this point, it is probably better for any Speedy Trial attempts to be 
rejected by the community and fail outright. Perhaps even preparing a real 
counter-softfork to invalidate blocks signalling for it.

Luke

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin]

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

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


--
@JeremyRubin <https://twitter.com/JeremyRubin>

On Thu, Apr 21, 2022 at 12:57 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> > @DavidHarding
> >
> > Interesting proposal to revert consensus changes. Is it possible to do
> this
> > for soft forks that are already activated?
>
> Generally, no. Reverting a softfork without a built-in expiry would be a
> hardfork.
>
> > Example: Some users are not okay with witness discount in segwit
> > transactions
> >
> > https://nitter.net/giacomozucco/status/1513614380121927682
>
> 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).
>
> > @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.
>
> We had that for Taproot, and now certain people are trying to say Speedy
> Trial
> activated Taproot rather than the BIP8 client, and otherwise creating
> confusion and ambiguity.
>
> 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.
>
> At this point, it is probably better for any Speedy Trial attempts to be
> rejected by the community and fail outright. Perhaps even preparing a real
> counter-softfork to invalidate blocks signalling for it.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr]

On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote:
> > 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.

You'd be confiscating your own funds by making an absurd spending condition.
By this argument, ALL softforks would have to be ruled out.

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

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.

Luke

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin]

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

> You'd be confiscating your own funds by making an absurd spending
condition.
> By this argument, ALL softforks would have to be ruled out.

The argument is that transactions which can be relayed and in the mempool
and then confirmed should not ever be restricted.

This is so that old node's mempools don't produce invalid blocks after an
upgrade.

This is what a good chunk of policy is for, and we (being core) do bounce
these txns to make clear what might be upgraded.

Changing the detail you mentioned represents a tweak that could make old
nodes mine invalid blocks. That's all I'm ruling 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.
>


Even if I accept full responsibility for BIP9 ST without consensus, you
still had the last year to convince the rest of the maintainers to review
and merge your activation code, which you did not do.

Don't confuse consensus-seeking with preference. My preference was to leave
versionbits entirely.

Nor am I blame seeking. I'm simply asking why, if this is _the_ most
important thing for Bitcoin (as I've heard some BIP8 LOT=true people
remark), did you not spend the last year improving your advocacy. And I'm
suggesting that you redouble those efforts by, e.g., opening a new PR for
Core with logic you find acceptable and continuing to drive the debate
forward. None of these things happen without advocacy.

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Peter Todd]

On April 21, 2022 5:10:02 AM GMT+02:00, alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>@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

That specific case isn't a good example as reverting the discount would actually be a soft fork, as it is a tightening of existing rules. In fact, it'd be a block size decrease.

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo]

On 4/20/22 6:04 PM, 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
>

Also "is this even the way we should be going about covenants?" Given there are still various 
proposals for covenants floating around and we're still in the very early stages of the 
reconciliation of them and 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 is insulting, myopic, short-sighted. Worse, it 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.

Matt

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding]

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

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

How should we think about changes to Bitcoin and maintaining its culture 
of security and careful design?  My post suggested a generalized way we 
could evaluate proposed consensus changes for real-world demand, 
allowing us to settle what I see as the most contended part of the CTV 
proposal.  That feels to me like legitimate engineering and social 
consensus building.  What would be your preferred alternatives?

(For the record, my preferred alternative for years has been to add the 
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what 
covenant-y things people build with them, and then consider proposals to 
optimize the onchain usage of those covenant-y things.  Alas, this seems 
to fall afoul of the concerns held by some people about recursive 
covenants.)

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

If the only choices are to support activation of BIP119 CTV at this time 
or to reject it, I would currently side with rejection.  But I would 
prefer over both of those options to find a third way that doesn't 
compromise safety or long-term maintainability and which gives us the 
data about CTV (or other covenant-related constructions) to see whether 
the concerns described above in 1a and 1b are actually non-issues.

I see one of those third ways as the testing on the CTV signet described 
in a contemporaneous thread on this list.[1]  Other third ways would be 
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be 
temporarily used on Bitcoin as proposed in this thread.  Is there 
interest in working on those alternatives, or is the only path forward 
an argument over attempting activation of CTV?

Thanks,

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo]

On 4/21/22 11:06 AM, David A. Harding wrote:
> 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.

No, its unrelated to whether CTV or any other system gets usage. If we were just concerned with 
whether CTV would get usage over or under some other alternative proposal then I could see an 
argument for your proposal (though the nontrivial cost of any fork to Bitcoin would make me still 
strongly disagree with such a way forward in principle).

Rather, I'm instead concerned with us designing something that is going to be the most flexible and 
useful and hopefully private covenents design we can, because that doesn't just get users to use the 
change to Bitcoin we paid some nontrivial change-cost to incorporate into the Bitcoin's consensus 
rules, but gets the most bang-for-our-buck. 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 don't add things to Bitcoin just to find out whether we can. full stop.

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 and (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".

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

That all seems fine, except that doing a fork on Bitcoin has very nontrivial cost, both in terms of 
ecosystem disruption and possibility that anything goes wrong, not to mention code maintenance 
(which we cannot remove the validation code for something ever, really - you still want to be able 
to validate the historical chain). Plus, really, I'd love to see "technical community consensus" 
somewhere in there - at least its been something that has very roughly appeared for most previous 
soft forks, at least among those who have time/willingness to work on the specific design being 
proposed.

[other comments snipped because my responses would mostly have been rehashing the first response above].

Matt

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding]

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo]

On 4/21/22 3:28 PM, David A. Harding 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.

To be clear - I was not suggesting that CTV fell flat here. I think there *is* demand for Bitcoin 
covenant designs, CTV included. I do *not* think there is demand for CTV *over* other covenant 
designs, that's okay, though, it doesn't need that, we just have to be confident its the right 
direction.

I believe you got the impression I was arguing CTV did not meet by criteria list (a)-(d), but in 
fact I only think it falls flat horribly on (c).

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

I tend to agree.

>> (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 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 don't mention the lack of recursion in CTV vs CAT+CSFS, which is a *huge* difference in 
the available design space for developers. This stuff is critical to get right and we're barely even 
talking about it, let alone at a position of deciding something?

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

Again, you're writing off the real and nontrivial risk of doing a fork to begin with. You're also 
writing off something organic that has happened without issue time and time again - 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" is something we've all collaboratively done time and time again. 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".

Matt

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding]

[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, 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".

I'm sorry if my OP was ambiguous about this, but my goal there was to 
describe a general framework for activating temporary consensus changes 
for the purpose of demonstrating demand for proposed features.  I gave 
CTV as an example for how the framework could be used, but we could use 
the same framework to activate APO and TLUV (or IIDs and EVICT)---and 
then we would see which of them people actually used.  If there was 
significant ongoing use of all three after 5 years, great!  We keep them 
all.  If some of them went largely unused, we let the extra validation 
rules expire and move on.

Alternatively, if we only enabled one covenant design (e.g. CTV), we 
would still gain data about how it was used and we could see if some of 
the alternative designs would've been more optimal for those 
demonstrated uses.

My goal here is obtaining data from which we can make informed 
decisions.  A transitory soft fork is an extreme way to acquire that 
data and I fully acknowledge it has several significant problems 
(including those I listed in my OP).  I'm hoping, though, that it's a 
better solution than another activation battle, prolonged yelling on 
this mailing list and elsewhere, or everyone just giving up and letting 
Bitcoin ossify prematurely.  Alternatively, I'm hoping one of the many 
people on this list who is smarter than I am will think of another way 
to obtain decisive data with less fuss.

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

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

I mentioned recursion, or the lack thereof, in various proposals like 
five times in this thread.  :-)

Thanks again for your replies,

-Dave

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo]

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Corey Haddad]

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

If none of the alternative proposals have been developed as much as CTV, it
seems reasonable to interpret that as a lack of interest in those
alternative proposals themselves.
That should not be interpreted as lack of interest in covenants. Perhaps if
CTV didn't exist, we would have seen more progress on the alternatives.
It's entirely reasonable to assume that people who are interested in
covenants have put their energy and attention primarily behind CTV, and
that is why it is the furthest along. It shouldn't be a requisite to
improving Bitcoin that we have multiple, competing proposals for a
similar use case that have all been debated, implemented and tested before
we will be okay with integrating one of them. That may be the ideal, but it
shouldn't be a requirement.

If we can find consensus of moving forward with one of the proposals, and
there are concrete commitments to develop the alternatives over the next
few months, I would suggest that would be something worth waiting for. In
the absence of such consensus and commitments, the ask here is that CTV be
set aside in favor of an unlikely hypothetical.

Corey

On Fri, Apr 22, 2022 at 2:40 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[James O'Beirne]

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

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[James O'Beirne]

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

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

Apologies for the double post, but I need to caveat this.

To be more accurate, I see "coin pools" as the most potentially
valuable use of covenants, since we need to address the scalability of
UTXO ownership as an existential issue at some point down the road - but
because a workable design has not yet been proposed (I don't think e.g.
CoinPools is scalable as-written... but that's for another
post), I am omitting that use in favor of vaults, which are well
understood and can be implemented workably in various ways.

I do not want to suggest that I don't want more general covenant
abilities - I do! But it's clear that both the designs and exact
usages of recursive covenants need *a lot* of work, probably years.

Throwing CTV to the wayside because it isn't a 100% solution to
every possible covenant use we can dream up feels a bit like
slamming the door on P2SH because Taproot might come along
a few years later.

On Fri, Apr 22, 2022 at 12:48 PM James O'Beirne <james.obeirne@gmail.com>
wrote:

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[James O'Beirne]

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

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

Each covenant proposal aside from CTV has seemed either abstruse and
handwavy to me (TLUV, OP_EVICT) or general to the point of
being hard to analyze for safety (CAT) or encourages
witness verbosity that seems wasteful (OP_TX[HASH]).

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.

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

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.

Why that is after years of discussion and the utility of
covenants being widely appreciated is indicative to me.

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

[bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor]

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

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.

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Billy Tetrud]

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

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

On Fri, Apr 22, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor]

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

On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud <billy.tetrud@gmail.com>
wrote:

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

As I noted, the original MES vault
https://fc16.ifca.ai/bitcoin/papers/MES16.pdf, commits to the destination
address during unvaulting.  Their proposal uses CheckOutputVerify that
checks if a given output has a given amount and a given scriptPubKey.  (The
MES vault then goes on to add a PATTERN parameter to OP_COV's scriptPubKey
parameter in order to make a recursive vault, but that is used to deter
cold-key theft, not hot-key theft).

Our paper https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
impelments the MES vault in Elements (alpha) using CAT and
CHECKSIGFROMSTACK.  While I wouldn't necessarily call it a covenant
proposal, rather it is an observation that these opcodes happen to be
adequate for the task.

With such a big security caveat, I really don't find CTV vaults a
compelling example of using CTV.  Sure, if CTV happens to exist, by all
means do whatever you like.  But if anything, the CTV vault scheme instead
illustrates BlueMatt's point that we aren't really finished with covenant
research design yet:

Q: What ways can we build a secured vault that commits to the destination
address?
Q: Are there elegant ways of building secure vaults by using CTV plus
something else.  Presumably CAT + CTV would be enough, though maybe some
people are concerned that CAT might enable recursive covenants (if people
aren't willing to have even CAT, I don't see how we will ever really have
programmable money).

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Matt Corallo]

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor]

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

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Billy Tetrud]

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

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Nadav Ivgi]

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

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If you unvault an output to your hot wallet, the thief could be lying in
wait, ready to steal those funds upon them landing.

One way to mitigate some of the risk is to split up your UTXOs so that your
hot wallet exposure is limited.

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

These are two orthogonal things though. You can have a CTV vault where the
hot key signer is a multisig to get the advantages of both. In this case
the addition of a CTV-based unvaulting procedure is an improvement compared
to not using it.

shesek

On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Russell O'Connor]

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

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.

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Billy Tetrud]

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

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Nadav Ivgi]

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

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

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

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)

[Billy Tetrud]

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

>  the point of a vault is the ability to keep your primary wallet keys in
*highly* deep cold storage

I think we're both right. You're also right that there are many possible
configurations including the one you mentioned. I can see good reasons to
use multisig even if both keys are quickly on hand. My only point was that
using a wallet vault that unvaults to a multisig isn't a best of both
worlds, but rather has different trade offs. Sounds like we agree.

On Thu, Apr 28, 2022 at 6:14 PM Nadav Ivgi <nadav@shesek.info> wrote:

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo]

On 4/22/22 9:28 AM, James O'Beirne wrote:
>  > 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.

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

I'd think its indicative of the lack of interest in serious covenants designs from many of the 
highly-qualified people who could be working on them. There are many reasons for that. If there's 
one positive thing from the current total mess, its that hopefully there will be a renewed interest 
in researching things and forming conclusions.


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

[citation needed]

Matt

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin]

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

I think I've discussed this type of concept previously somewhere but cannot
find a link to where.

Largely, I think the following:

1) This doesn't reduce burden of maintenance and risk of consensus split,
it raises it:
   A) as we now have a bunch of tricky code around reorgs and mempool
around the time of rule de-activation.
   B) we need to permanently maintain the rule to validate old blocks fully
2) Most of the value of a 'temporary soft fork' is more safely captured by
use of a CTV emulation server / servers, which has a more graceful
degradation property of the servers simply shutting down and not
authorizing new contracts, but funds not being vulnerable to theft. The
model here is trust, as opposed to a timeout.
   2A) The way I implemented the oracles in CTV was such that, if we wanted
to, we could actually soft-fork the rules for the oracle's keys such that
they would *have to* only sign CTV-valid transactions (e.g., the keys could
be made public). Pretty weird model, but cool that it would enable
after-the-fact trust model improvements. This could be generalized for any
opcode to be emulator -> emulator consensus guaranteed -> non signature
based opcode.

Although I will note that I like the spirit of this, and encourage thinking
more creatively about other ways to have temporary forks in Bitcoin like
this.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Anthony Towns]

On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev wrote:
> 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?  [...]

Buck O Perley suggested that "Many of the use cases that people
are excited to use CTV for ([5], [6]) are very long term in nature
and targeted for long term store of value in contrast to medium of
exchange."

But, if true, 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?

[5] https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py
[6] https://github.com/jamesob/simple-ctv-vault

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();
  }

That is to have sunsetting the feature be its own soft-fork with
pre-declared parameters that are included in the original activation
proposal. That way you don't have to have a second process debate about
how to go about (not) sunsetting the rules, just one on the merits of
whether sunsetting is worth doing or not.

Cheers,
aj

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding]

On 21.04.2022 14:28, Anthony Towns wrote:
> 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?

I fully acknowledge that a temporary test can't fully replicate a 
permanent condition.  That said, if people truly believe CTV vaults will 
significantly enhance their security, wouldn't it be worth using them 
for most of the deployment?  Users would receive both years of added 
security and the opportunity to convince other Bitcoiners to make CTV 
permanent by demonstrating real-world usage.

> 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();
>   }

Defining at the outset how we'll signal years later if we want to keep 
the rules seems intelligent to me.

Thanks!,

-Dave

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Antoine Riard]

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

Hi Dave,

I think the transitory idea is interesting, though I would say it would
take far more thinking to capture the implications.

> 1. It creates a big footgun.  Anyone who uses CTV without adequately
preparing for the reversion could easily lose their money.

I think that downside should be weighed far more. If we imagine CTV being
used in the context of a said off-chain contract, it's not guaranteed you
can downgrade to equivalent semantics around the reversion date, or not at
the same witness cost which is raising implications for your cached
fee-bumping reserves.

Further, this downgrade path might have to be re-signed by your off-chain
contract counterparties to migrate a balance distribution locked by CTV to
one relying on pre-signed transactions. This contract "consensus" is not
guaranteed and it could even be leveraged by some unfair counterparties,
who have small balances at stake.

If you can't gracefully downgrade to equivalent semantics or negotiate a
migration, it's more likely the safe behavior to adopt would be to close
the off-chain contract, ahead of the reversion date.
As it might be a critical operation, the toolchain vendors might adopt the
practice to coordinate the automatic closing with a flag day (e.g "close
your LN channel at block XXX") or in a relative distributed fashion (e.g
"close your LN channel at randomly picked up block between X and Y"). Such
relatively automatic closure, if realized in mass, would provoke mempools
congestion. An adversarial event which would cloak the security of all
existing off-chain contracts.

Therefore I'm not sure if a reversion date for a contracting primitive
softfork is the soundest off-chain contract engineering practice...

Further, I think there is one more downside not considered in your list :
negative incentives for the CTV ecosystem stakeholders. As a CTV-enabled
protocol developer, as you know time is counted to
prove the worthiness of the primitive, you have an interest to design a
protocol and develop/deploy a toolchain on a short-time basis, likely not
the soundest principle in system software engineering.
Such a development attitude is more likely to grieve the ecosystem with
safety-critical bugs/vulnerabilities, of which the exploitation might
eradicate the credibility of your CTV use-case, and with it the wider CTV
ecosystem.

So I think the data-collection method itself to advance the
consensus-building process isn't neutral on the outcome yielded. The
consensus-building stakeholders themselves aren't immune to the incentives
disruptions brought by an innovation in the process.

Antoine

Le mer. 20 avr. 2022 à 21:06, David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[ZmnSCPxj]

Good morning Dave, et al.,

I have not read through *all* the mail on this thread, but have read a fair amount of it.

I think the main argument *for* this particular idea is that "it allows the use of real-world non-toy funds to prove that this feature is something actual users demand".

An idea that has been percolating in my various computation systems is to use Smart Contracts Unchained to implement a variant of the Microcode idea I put forth some months ago.

Briefly, define a set of "more detailed" opcodes that would allow any general computation to be performed.
This is the micro-opcode instruction set.

Then, when a new opcode or behavior is proposed for Bitcoin SCRIPT, create a new mapping from Bitcoin SCRIPT opcodes (including the new opcodes / behavior) to the micro-opcodes.
This is a microcode.

Then use Smart Contracts Unchained.
This means that we commit to the microcode, plus the SCRIPT that uses the microcode, and instead of sending funds to a new version of the Bitcoin SCRIPT that uses the new opcode(s), send to a "(n-of-n of users) or (1-of-users and (k-of-n of federation))".

This is no worse security-wise than using a federated sidechain, without requiring a complete sidechain implementation, and allows the same code (the micro-opcode interpreter) to be reused across all ideas.
It may even be worthwhile to include the micro-opcode interpreter into Bitcoin Core, so that the mechanics of merging in a new opcode, that was prototyped via this mechanism, is easier.

The federation only needs to interpret the micro-opcode instruction set; it simply translates the (modified) Bitcoin SCRIPT opcodes to the corresponding micro-opcodes and runs that, possibly with reasonable limits on execution time.
Users are not required to trust a particular fixed set of k-of-n federation, but may choose any k-of-n they believe is trustworthy.

This idea does not require consensus at any point in time.
It allows "real" funds to be used, thus demonstrating real demand for the supposed innovation.
The problem is the effective erosion of security to depending on k-of-n of a federation.

Presumably, proponents of a new opcode or feature would run a micro-opcode interpreter faithfully, so that users have a positive experience with their new opcode, and would carefully monitor and vet the micro-opcode interpreters run by other supposed proponents, on the assumption that a sub-goal of such proponents would be to encourage use of the new opcode / feature.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)

[Buck O Perley]

[-- Attachment #1.1: Type: text/plain, Size: 10239 bytes --]

Just a couple of comments re-CTV vault security concerns.


1. One way to assuage the concern of the hot wallet vulnerability
is pre-program the spends such that the hot wallet can only
spend a certain amount from the hot wallet spend and the rest would
kind of be "recursive" in that it would be sent back to a
new instantiation of the CTV vault. I believe kanzure's vaults
does this w/ the non-covenant version using pre-signed transactions
(https://github.com/kanzure/python-vaults). While this doesn't
prevent the theft it caps off the total risk. I would argue that
this is strictly better than a multisig because you can also use
multisig as you normally would if you want but you have the option
if you think your hot key is secure to use that spending path.
You also get the nice benefit of learning about compromised
keys without having to risk all funds associated with that key.


2. As to how to improve UX for CTV with other proposals, I think
you get a lot of benefits when using with taproot because you can
use CTV in tapleaves to secure specific spend conditions, but can
always fall back to other off-ramps (e.g. a musig key path spend or
other script path conditions). Of course you can do this without
taproot but taproot makes this more space efficient. This idea has
been used to some effect in some recent exploration of how CTV can
help improve UX around DLCs. You could even do this to help with
the problems of not sending the right amount such that you have a
really really cold key or set of keys for example such that if you
have UTXOs that have values that can't be spent with the given CTV
commitment, then you just use that other branch.

- Buck

------- Original Message -------

> Date: Sun, 24 Apr 2022 18:03:52 -0500
> From: Billy Tetrud billy.tetrud@gmail.com
> 

> To: "Russell O'Connor" roconnor@blockstream.com, Bitcoin Protocol
> 

> Discussion bitcoin-dev@lists.linuxfoundation.org
> 

> Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> ("transitory") soft forks)
> Message-ID:
> CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com
> 

> Content-Type: text/plain; charset="utf-8"
> 

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)

[Billy Tetrud]

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

>  the hot wallet can only spend a certain amount from the hot wallet spend
and the rest would .. be sent back

That would definitely be the way to do it. The ability to steal from the
hot wallet in my opinion shouldn't really be a "concern" about CTV, but
rather an understood tradeoff of a CTV wallet vault. In fact, its hardly
even a trade off - a CTV vault can be created that is usable exactly as a
normal multisig wallet if the user wants to use it that way. The unvaulting
would simply add an additional (and optional) usability improvement over
normal multisig. The security considerations around choosing the
appropriate maximum amount to unvault at a time (with one key) is just
something that someone would need to decide based on basically their
comfort level. It sounds like you said something very similar in your point
2.

Would I like to have a wallet vault that doesn't have this security
consideration? Sure. But that isn't to say a wallet vault with that hitch
isn't a very useful advance to self-custody setups.

> You also get the nice benefit of learning about compromised keys without
having to risk all funds associated with that key.

This is an interesting tack-on attribute. A built in honey pot. If you only
allow 1% of your savings to be taken out at a time (with one key), is 1% of
your savings worth knowing that your wallet has been partially compromised?
Maybe it would be.



On Mon, Apr 25, 2022 at 11:51 AM Buck O Perley via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Just a couple of comments re-CTV vault security concerns.
>
>
> 1. One way to assuage the concern of the hot wallet vulnerability
> is pre-program the spends such that the hot wallet can only
> spend a certain amount from the hot wallet spend and the rest would
> kind of be "recursive" in that it would be sent back to a
> new instantiation of the CTV vault. I believe kanzure's vaults
> does this w/ the non-covenant version using pre-signed transactions
> (https://github.com/kanzure/python-vaults). While this doesn't
> prevent the theft it caps off the total risk. I would argue that
> this is strictly better than a multisig because you can also use
> multisig as you normally would if you want but you have the option
> if you think your hot key is secure to use that spending path.
> You also get the nice benefit of learning about compromised
> keys without having to risk all funds associated with that key.
>
>
> 2. As to how to improve UX for CTV with other proposals, I think
> you get a lot of benefits when using with taproot because you can
> use CTV in tapleaves to secure specific spend conditions, but can
> always fall back to other off-ramps (e.g. a musig key path spend or
> other script path conditions). Of course you can do this without
> taproot but taproot makes this more space efficient. This idea has
> been used to some effect in some recent exploration of how CTV can
> help improve UX around DLCs. You could even do this to help with
> the problems of not sending the right amount such that you have a
> really really cold key or set of keys for example such that if you
> have UTXOs that have values that can't be spent with the given CTV
> commitment, then you just use that other branch.
>
> - Buck
>
> ------- Original Message -------
>
> > Date: Sun, 24 Apr 2022 18:03:52 -0500
> > From: Billy Tetrud billy.tetrud@gmail.com
> >
>
> > To: "Russell O'Connor" roconnor@blockstream.com, Bitcoin Protocol
> >
>
> > Discussion bitcoin-dev@lists.linuxfoundation.org
> >
>
> > Subject: Re: [bitcoin-dev] Vaulting (Was: Automatically reverting
> > ("transitory") soft forks)
> > Message-ID:
> > CAGpPWDaeKYABkK+StFXoxgWEhVGzqY02KPGOFjOtt9W8UPRr1A@mail.gmail.com
> >
>
> > Content-Type: text/plain; charset="utf-8"
> >
>
> > @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
>

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