* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)
@ 2022-04-25 16:03 Buck O Perley
2022-04-27 2:09 ` Billy Tetrud
0 siblings, 1 reply; 13+ messages in thread
From: Buck O Perley @ 2022-04-25 16:03 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks)
2022-04-25 16:03 [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks) Buck O Perley
@ 2022-04-27 2:09 ` Billy Tetrud
0 siblings, 0 replies; 13+ messages in thread
From: Billy Tetrud @ 2022-04-27 2:09 UTC (permalink / raw)
To: Buck O Perley, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
@ 2022-04-21 1:04 David A. Harding
2022-04-21 14:58 ` Matt Corallo
0 siblings, 1 reply; 13+ messages in thread
From: David A. Harding @ 2022-04-21 1:04 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
2022-04-21 1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV David A. Harding
@ 2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06 ` David A. Harding
0 siblings, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2022-04-21 14:58 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
2022-04-21 14:58 ` Matt Corallo
@ 2022-04-21 18:06 ` David A. Harding
2022-04-21 18:39 ` Matt Corallo
0 siblings, 1 reply; 13+ messages in thread
From: David A. Harding @ 2022-04-21 18:06 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
2022-04-21 18:06 ` David A. Harding
@ 2022-04-21 18:39 ` Matt Corallo
2022-04-22 16:28 ` James O'Beirne
0 siblings, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2022-04-21 18:39 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
2022-04-21 18:39 ` Matt Corallo
@ 2022-04-22 16:28 ` James O'Beirne
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
0 siblings, 1 reply; 13+ messages in thread
From: James O'Beirne @ 2022-04-22 16:28 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-22 16:28 ` James O'Beirne
@ 2022-04-22 17:25 ` Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
2022-04-23 18:24 ` Matt Corallo
0 siblings, 2 replies; 13+ messages in thread
From: Russell O'Connor @ 2022-04-22 17:25 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
@ 2022-04-23 4:56 ` Billy Tetrud
2022-04-23 14:02 ` Russell O'Connor
2022-04-23 18:24 ` Matt Corallo
1 sibling, 1 reply; 13+ messages in thread
From: Billy Tetrud @ 2022-04-23 4:56 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-23 4:56 ` Billy Tetrud
@ 2022-04-23 14:02 ` Russell O'Connor
0 siblings, 0 replies; 13+ messages in thread
From: Russell O'Connor @ 2022-04-23 14:02 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
@ 2022-04-23 18:24 ` Matt Corallo
2022-04-23 19:30 ` Russell O'Connor
1 sibling, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2022-04-23 18:24 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
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 :)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-23 18:24 ` Matt Corallo
@ 2022-04-23 19:30 ` Russell O'Connor
2022-04-24 23:03 ` Billy Tetrud
0 siblings, 1 reply; 13+ messages in thread
From: Russell O'Connor @ 2022-04-23 19:30 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-23 19:30 ` Russell O'Connor
@ 2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
0 siblings, 2 replies; 13+ messages in thread
From: Billy Tetrud @ 2022-04-24 23:03 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-24 23:03 ` Billy Tetrud
@ 2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
1 sibling, 0 replies; 13+ messages in thread
From: Nadav Ivgi @ 2022-04-25 17:27 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
@ 2022-04-25 22:27 ` Russell O'Connor
2022-04-27 1:52 ` Billy Tetrud
1 sibling, 1 reply; 13+ messages in thread
From: Russell O'Connor @ 2022-04-25 22:27 UTC (permalink / raw)
To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-25 22:27 ` Russell O'Connor
@ 2022-04-27 1:52 ` Billy Tetrud
2022-04-28 23:14 ` Nadav Ivgi
0 siblings, 1 reply; 13+ messages in thread
From: Billy Tetrud @ 2022-04-27 1:52 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-27 1:52 ` Billy Tetrud
@ 2022-04-28 23:14 ` Nadav Ivgi
2022-04-28 23:51 ` Billy Tetrud
0 siblings, 1 reply; 13+ messages in thread
From: Nadav Ivgi @ 2022-04-28 23:14 UTC (permalink / raw)
To: Billy Tetrud, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks)
2022-04-28 23:14 ` Nadav Ivgi
@ 2022-04-28 23:51 ` Billy Tetrud
0 siblings, 0 replies; 13+ messages in thread
From: Billy Tetrud @ 2022-04-28 23:51 UTC (permalink / raw)
To: Nadav Ivgi; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-04-28 23:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-25 16:03 [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") > soft forks) Buck O Perley
2022-04-27 2:09 ` Billy Tetrud
-- strict thread matches above, loose matches on Subject: below --
2022-04-21 1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV David A. Harding
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06 ` David A. Harding
2022-04-21 18:39 ` Matt Corallo
2022-04-22 16:28 ` James O'Beirne
2022-04-22 17:25 ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23 4:56 ` Billy Tetrud
2022-04-23 14:02 ` Russell O'Connor
2022-04-23 18:24 ` Matt Corallo
2022-04-23 19:30 ` Russell O'Connor
2022-04-24 23:03 ` Billy Tetrud
2022-04-25 17:27 ` Nadav Ivgi
2022-04-25 22:27 ` Russell O'Connor
2022-04-27 1:52 ` Billy Tetrud
2022-04-28 23:14 ` Nadav Ivgi
2022-04-28 23:51 ` Billy Tetrud
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox