[bitcoin-dev] CTV vaults in the wild

[bitcoin-dev] CTV vaults in the wild

[James O'Beirne]

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

A few months ago, AJ wrote[0]

> I'm not really convinced CTV is ready to start trying to deploy
> on mainnet even in the next six months; I'd much rather see some real
> third-party experimentation *somewhere* public first

In the spirit of real third-party experimentation *somewhere* in public,
I've created this implementation and write-up of a simple vault design
using CTV.

   https://github.com/jamesob/simple-ctv-vault

I think it has a number of appealing characteristics for custody
operations at any size.

Regards,
James


[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019920.html

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

Re: [bitcoin-dev] CTV vaults in the wild

[Antoine Riard]

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

Hi James,

Interesting to see a sketch of a CTV-based vault design !

I think the main concern I have with any hashchain-based vault design is
the immutability of the flow paths once the funds are locked to the root
vault UTXO. By immutability, I mean there is no way to modify the
unvault_tx/tocold_tx transactions and therefore recover from transaction
fields
corruption (e.g a unvault_tx output amount superior to the root vault UTXO
amount) or key endpoints compromise (e.g the cold storage key being
stolen).

Especially corruption, in the early phase of vault toolchain deployment, I
believe it's reasonable to expect bugs to slip in affecting the output
amount or relative-timelock setting correctness (wrong user config,
miscomputation from automated vault management, ...) and thus definitively
freezing the funds. Given the amounts at stake for which vaults are
designed, errors are likely to be far more costly than the ones we see in
the deployment of payment channels.

It might be more conservative to leverage a presigned transaction data
design where every decision point is a multisig. I think this design gets
you the benefit to correct or adapt if all the multisig participants agree
on. It should also achieve the same than a key-deletion design, as long as
all
the vault's stakeholders are participating in the multisig, they can assert
that flow paths are matching their spending policy.

Of course, relying on presigned transactions comes with higher assumptions
on the hardware hosting the flow keys. Though as hashchain-based vault
design imply "secure" key endpoints (e.g <cold_pubkey>), as a vault user
you're still encumbered with the issues of key management, it doesn't
relieve you to find trusted hardware. If you want to avoid multiplying
devices to trust, I believe flow keys can be stored on the same keys
guarding the UTXOs, before sending to vault custody.

I think the remaining presence of trusted hardware in the vault design
might lead one to ask what's the security advantage of vaults compared to
classic multisig setup. IMO, it's introducing the idea of privileges in the
coins custody : you set up the flow paths once for all at setup with the
highest level of privilege and then anytime you do a partial unvault you
don't need the same level of privilege. Partial unvault authorizations can
come with a reduced set of verifications, at lower operational costs. That
said, I think this security advantage is only relevant in the context of
recursive design, where the partial unvault sends back the remaining funds
to vault UTXO (not the design proposed here).

Few other thoughts on vault design, more minor points.

"If Alice is watching the mempool/chain, she will see that the unvault
transaction has been unexpectedly broadcast,"

I think you might need to introduce an intermediary, out-of-chain protocol
step where the unvault broadcast is formally authorized by the vault
stakeholders. Otherwise it's hard to qualify "unexpected", as hot key
compromise might not be efficiently detected.

"With <hash> OP_CTV, we can ensure that the vault operation is enforced by
consensus itself, and the vault transaction data can be generated
deterministically without additional storage needs."

Don't you also need the endpoint scriptPubkeys (<cold_pubkey>,
<hot_pubkey>), the amounts and CSV value ? Though I think you can grind
amounts and CSV value in case of loss...But I'm not sure if you remove the
critical data persistence requirement, just reduce the surface.

"Because we want to be able to respond immediately, and not have to dig out
our cold private keys, we use an additional OP_CTV to encumber the "swept"
coins for spending by only the cold wallet key."

I think a robust vault deployment would imply the presence of a set of
watchtowers, redundant entities able to broadcast the cold transaction in
reaction to unexpected unvault. One feature which could be interesting is
"tower accountability", i.e knowing which tower initiated the broadcast,
especially if it's a faultive one. One way is to watermark the cold
transaction (e.g tweak nLocktime to past value). Though I believe with CTV
you would need as much different hashes than towers included in your
unvault output (can be wrapped in a Taproot tree ofc). With presigned
transactions, tagged versions of the cold transaction are stored off-chain.

"In this implementation, we make use of anchor outputs in order to allow
mummified unvault transactions to have their feerate adjusted dynamically."

I'm not sure if the usage of anchor output is safe for any vault deployment
where the funds stakeholders do not trust each other or where the
watchtowers are not trusted. If a distrusted party can spend the anchor
output it's easy to block the RBF with a pinning.

Can we think about other criterias on which to sort vault designs ?

(I would say space efficiency is of secondary concern as we can expect
vault users as a class of on-chain space demand to be in the higher ranks
of blockspace "buying power". Though it's always nice if the chain is used
reasonably...)

Antoine

Le dim. 6 mars 2022 à 12:35, James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> A few months ago, AJ wrote[0]
>
> > I'm not really convinced CTV is ready to start trying to deploy
> > on mainnet even in the next six months; I'd much rather see some real
> > third-party experimentation *somewhere* public first
>
> In the spirit of real third-party experimentation *somewhere* in public,
> I've created this implementation and write-up of a simple vault design
> using CTV.
>
>    https://github.com/jamesob/simple-ctv-vault
>
> I think it has a number of appealing characteristics for custody
> operations at any size.
>
> Regards,
> James
>
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019920.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV vaults in the wild

[ZmnSCPxj]

Good morning Antoine,

> Hi James,
>
> Interesting to see a sketch of a CTV-based vault design !
>
> I think the main concern I have with any hashchain-based vault design is the immutability of the flow paths once the funds are locked to the root vault UTXO. By immutability, I mean there is no way to modify the unvault_tx/tocold_tx transactions and therefore recover from transaction fields
> corruption (e.g a unvault_tx output amount superior to the root vault UTXO amount) or key endpoints compromise (e.g the cold storage key being stolen).
>
> Especially corruption, in the early phase of vault toolchain deployment, I believe it's reasonable to expect bugs to slip in affecting the output amount or relative-timelock setting correctness (wrong user config, miscomputation from automated vault management, ...) and thus definitively freezing the funds. Given the amounts at stake for which vaults are designed, errors are likely to be far more costly than the ones we see in the deployment of payment channels.
>
> It might be more conservative to leverage a presigned transaction data design where every decision point is a multisig. I think this design gets you the benefit to correct or adapt if all the multisig participants agree on. It should also achieve the same than a key-deletion design, as long as all
> the vault's stakeholders are participating in the multisig, they can assert that flow paths are matching their spending policy.

Have not looked at the actual vault design, but I observe that Taproot allows for a master key (which can be an n-of-n, or a k-of-n with setup (either expensive or trusted, but I repeat myself)) to back out of any contract.

This master key could be an "even colder" key that you bury in the desert to be guarded over by generations of Fremen riding giant sandworms until the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto, arrives.

> Of course, relying on presigned transactions comes with higher assumptions on the hardware hosting the flow keys. Though as hashchain-based vault design imply "secure" key endpoints (e.g <cold_pubkey>), as a vault user you're still encumbered with the issues of key management, it doesn't relieve you to find trusted hardware. If you want to avoid multiplying devices to trust, I believe flow keys can be stored on the same keys guarding the UTXOs, before sending to vault custody.
>
> I think the remaining presence of trusted hardware in the vault design might lead one to ask what's the security advantage of vaults compared to classic multisig setup. IMO, it's introducing the idea of privileges in the coins custody : you set up the flow paths once for all at setup with the highest level of privilege and then anytime you do a partial unvault you don't need the same level of privilege. Partial unvault authorizations can come with a reduced set of verifications, at lower operational costs. That said, I think this security advantage is only relevant in the context of recursive design, where the partial unvault sends back the remaining funds to vault UTXO (not the design proposed here).
>
> Few other thoughts on vault design, more minor points.
>
> "If Alice is watching the mempool/chain, she will see that the unvault transaction has been unexpectedly broadcast,"
>
> I think you might need to introduce an intermediary, out-of-chain protocol step where the unvault broadcast is formally authorized by the vault stakeholders. Otherwise it's hard to qualify "unexpected", as hot key compromise might not be efficiently detected.

Thought: It would be nice if Alice could use Lightning watchtowers as well, that would help increase the anonymity set of both LN watchtower users and vault users.

> "With <hash> OP_CTV, we can ensure that the vault operation is enforced by consensus itself, and the vault transaction data can be generated deterministically without additional storage needs."
>
> Don't you also need the endpoint scriptPubkeys (<cold_pubkey>, <hot_pubkey>), the amounts and CSV value ? Though I think you can grind amounts and CSV value in case of loss...But I'm not sure if you remove the critical data persistence requirement, just reduce the surface.
>
> "Because we want to be able to respond immediately, and not have to dig out our cold private keys, we use an additional OP_CTV to encumber the "swept" coins for spending by only the cold wallet key."
>
> I think a robust vault deployment would imply the presence of a set of watchtowers, redundant entities able to broadcast the cold transaction in reaction to unexpected unvault. One feature which could be interesting is "tower accountability", i.e knowing which tower initiated the broadcast, especially if it's a faultive one. One way is to watermark the cold transaction (e.g tweak nLocktime to past value). Though I believe with CTV you would need as much different hashes than towers included in your unvault output (can be wrapped in a Taproot tree ofc). With presigned transactions, tagged versions of the cold transaction are stored off-chain.

With Taproot trees the versions of the cold transaction are also stored off-chain, and each tower gets its own transaction revealing only one of the tapleaf branches.
It does have the disadvantage that you have O(log N) x 32 Merkle tree path references, whereas a presigned Taproot transaction just needs a single 64-byte signature for possibly millions of towers.

> "In this implementation, we make use of anchor outputs in order to allow mummified unvault transactions to have their feerate adjusted dynamically."
>
> I'm not sure if the usage of anchor output is safe for any vault deployment where the funds stakeholders do not trust each other or where the watchtowers are not trusted. If a distrusted party can spend the anchor output it's easy to block the RBF with a pinning.

I agree.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] CTV vaults in the wild

[Antoine Riard]

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

Hi Zeeman,

> Have not looked at the actual vault design, but I observe that Taproot
allows for a master key (which can be an n-of-n, or a k-of-n with setup
(either expensive or trusted, but I repeat myself)) to back out of any
contract.
>
> This master key could be an "even colder" key that you bury in the desert
to be guarded over by generations of Fremen riding giant sandworms until
the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto,
arrives.

Yes I agree you can always bless your hashchain-based off-chain contract
with an upgrade path thanks to Taproot. Though now this master key become
the point-of-failure to compromise, compared to hashchain.

I think you can even go fancier than a human desert to hide a master key
with "vaults" geostationary satellites [0] !

[0] https://github.com/oleganza/bitcoin-papers/blob/master/SatelliteVault.md

> Thought: It would be nice if Alice could use Lightning watchtowers as
well, that would help increase the anonymity set of both LN watchtower
users and vault users.

Well, I'm not sure if it's really binding toward the watchtowers.
A LN channel is likely to have a high-frequency of updates (in both
LN-penalty/Eltoo design I think)
A vault is likely to have low-frequency of updates (e.g an once a day
spending)

I think that point is addressable by generating noise traffic from the
vault entity to adopt a classic LN channel pattern. However, as a vault
"high-stake" user, you might not be eager to leak your watchtower IP
address or even Tor onion service to "low-stake" LN channel swarms of
users. So it might end up on different tower deployments because off-chain
contracts' level of safety requirements are not the same, I don't know..

> With Taproot trees the versions of the cold transaction are also stored
off-chain, and each tower gets its own transaction revealing only one of
the tapleaf branches.
> It does have the disadvantage that you have O(log N) x 32 Merkle tree
path references, whereas a presigned Taproot transaction just needs a
single 64-byte signature for possibly millions of towers.

I agree here though note vaults users might be interested to pay the fee
witness premium just to get the tower accountability feature.

Antoine

Le lun. 7 mars 2022 à 19:57, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> Good morning Antoine,
>
> > Hi James,
> >
> > Interesting to see a sketch of a CTV-based vault design !
> >
> > I think the main concern I have with any hashchain-based vault design is
> the immutability of the flow paths once the funds are locked to the root
> vault UTXO. By immutability, I mean there is no way to modify the
> unvault_tx/tocold_tx transactions and therefore recover from transaction
> fields
> > corruption (e.g a unvault_tx output amount superior to the root vault
> UTXO amount) or key endpoints compromise (e.g the cold storage key being
> stolen).
> >
> > Especially corruption, in the early phase of vault toolchain deployment,
> I believe it's reasonable to expect bugs to slip in affecting the output
> amount or relative-timelock setting correctness (wrong user config,
> miscomputation from automated vault management, ...) and thus definitively
> freezing the funds. Given the amounts at stake for which vaults are
> designed, errors are likely to be far more costly than the ones we see in
> the deployment of payment channels.
> >
> > It might be more conservative to leverage a presigned transaction data
> design where every decision point is a multisig. I think this design gets
> you the benefit to correct or adapt if all the multisig participants agree
> on. It should also achieve the same than a key-deletion design, as long as
> all
> > the vault's stakeholders are participating in the multisig, they can
> assert that flow paths are matching their spending policy.
>
> Have not looked at the actual vault design, but I observe that Taproot
> allows for a master key (which can be an n-of-n, or a k-of-n with setup
> (either expensive or trusted, but I repeat myself)) to back out of any
> contract.
>
> This master key could be an "even colder" key that you bury in the desert
> to be guarded over by generations of Fremen riding giant sandworms until
> the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto,
> arrives.
>
> > Of course, relying on presigned transactions comes with higher
> assumptions on the hardware hosting the flow keys. Though as
> hashchain-based vault design imply "secure" key endpoints (e.g
> <cold_pubkey>), as a vault user you're still encumbered with the issues of
> key management, it doesn't relieve you to find trusted hardware. If you
> want to avoid multiplying devices to trust, I believe flow keys can be
> stored on the same keys guarding the UTXOs, before sending to vault custody.
> >
> > I think the remaining presence of trusted hardware in the vault design
> might lead one to ask what's the security advantage of vaults compared to
> classic multisig setup. IMO, it's introducing the idea of privileges in the
> coins custody : you set up the flow paths once for all at setup with the
> highest level of privilege and then anytime you do a partial unvault you
> don't need the same level of privilege. Partial unvault authorizations can
> come with a reduced set of verifications, at lower operational costs. That
> said, I think this security advantage is only relevant in the context of
> recursive design, where the partial unvault sends back the remaining funds
> to vault UTXO (not the design proposed here).
> >
> > Few other thoughts on vault design, more minor points.
> >
> > "If Alice is watching the mempool/chain, she will see that the unvault
> transaction has been unexpectedly broadcast,"
> >
> > I think you might need to introduce an intermediary, out-of-chain
> protocol step where the unvault broadcast is formally authorized by the
> vault stakeholders. Otherwise it's hard to qualify "unexpected", as hot key
> compromise might not be efficiently detected.
>
> Thought: It would be nice if Alice could use Lightning watchtowers as
> well, that would help increase the anonymity set of both LN watchtower
> users and vault users.
>
> > "With <hash> OP_CTV, we can ensure that the vault operation is enforced
> by consensus itself, and the vault transaction data can be generated
> deterministically without additional storage needs."
> >
> > Don't you also need the endpoint scriptPubkeys (<cold_pubkey>,
> <hot_pubkey>), the amounts and CSV value ? Though I think you can grind
> amounts and CSV value in case of loss...But I'm not sure if you remove the
> critical data persistence requirement, just reduce the surface.
> >
> > "Because we want to be able to respond immediately, and not have to dig
> out our cold private keys, we use an additional OP_CTV to encumber the
> "swept" coins for spending by only the cold wallet key."
> >
> > I think a robust vault deployment would imply the presence of a set of
> watchtowers, redundant entities able to broadcast the cold transaction in
> reaction to unexpected unvault. One feature which could be interesting is
> "tower accountability", i.e knowing which tower initiated the broadcast,
> especially if it's a faultive one. One way is to watermark the cold
> transaction (e.g tweak nLocktime to past value). Though I believe with CTV
> you would need as much different hashes than towers included in your
> unvault output (can be wrapped in a Taproot tree ofc). With presigned
> transactions, tagged versions of the cold transaction are stored off-chain.
>
> With Taproot trees the versions of the cold transaction are also stored
> off-chain, and each tower gets its own transaction revealing only one of
> the tapleaf branches.
> It does have the disadvantage that you have O(log N) x 32 Merkle tree path
> references, whereas a presigned Taproot transaction just needs a single
> 64-byte signature for possibly millions of towers.
>
> > "In this implementation, we make use of anchor outputs in order to allow
> mummified unvault transactions to have their feerate adjusted dynamically."
> >
> > I'm not sure if the usage of anchor output is safe for any vault
> deployment where the funds stakeholders do not trust each other or where
> the watchtowers are not trusted. If a distrusted party can spend the anchor
> output it's easy to block the RBF with a pinning.
>
> I agree.
>
> Regards,
> ZmnSCPxj
>
>

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

Re: [bitcoin-dev] CTV vaults in the wild

[James O'Beirne]

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

Hey Antoine,

Thanks for taking a look at the repo.

> I believe it's reasonable to expect bugs to slip in affecting the
> output amount or relative-timelock setting correctness

I don't really see the vaults case as any different from other
sufficiently involved uses of bitcoin script - I don't remember anyone
raising these concerns for lightning scripts or DLCs or tapscript use,
any of which could be catastrophic if wallet implementations are not
tested properly.

By comparison, decreasing amount per vault step and one CSV use
seems pretty simple. It's certainly easy to test (as the repo shows),
and really the only parameter the user has is how many blocks to delay
to the `tohot_tx` and perhaps fee-rate. Not too hard to test
comprehensively as far as I can tell.


> I think the main concern I have with any hashchain-based vault design
> is the immutability of the flow paths once the funds are locked to the
> root vault UTXO.

Isn't this kind of inherent to the idea of covenants? You're
precommitting to a spend path. You can put in as many "escape-hatch"
conditions as you want (e.g. Jeremy makes the good point I should
include an immediate-to-cold step that is sibling to the unvaulting),
but fundamentally if you're doing covenants, you're precommitting to a
flow of funds. Otherwise what's the point?


> I think the remaining presence of trusted hardware in the vault design
> might lead one to ask what's the security advantage of vaults compared
> to classic multisig setup.

Who's saying to trust hardware? Your cold key in the vault structure
could have been generated by performing SHA rounds with the
pebbles in your neighbor's zen garden.

Keeping an actively used multi-sig setup secure certainly isn't free or
easy. Multi-sig ceremonies (which of course can be used in this scheme)
can be cumbersome to coordinate.

If there's a known scheme that doesn't require covenants, but has
similar usage and security characteristics, I'd love
to know it! But being able to lock coins up for an arbitrary amount of
time and then have advance notice of an attempted spend only seems
possible with some kind of covenant technique.

> That said, I think this security advantage is only relevant in the
> context of recursive design, where the partial unvault sends back the
> remaining funds to vault UTXO (not the design proposed here).

I'm not really sure why this would be. Yeah, it would be cool to be able
to partially unvault arbitrary amounts or something, but that seems like
another order of complexity. Personally, I'd be happy to "tranche up"
funds I'd like to store into a collection of single-hop vaults vs.
the techniques available to us today.


> I think you might need to introduce an intermediary, out-of-chain
> protocol step where the unvault broadcast is formally authorized by
> the vault stakeholders. Otherwise it's hard to qualify "unexpected",
> as hot key compromise might not be efficiently detected.

Sure; if you're using vaults I think it's safe to assume you're a fairly
sophisticated user of bitcoin, so running a process that monitors the
chain and responds immediately with keyless to-cold broadcasts
doesn't seem totally out of the question, especially with conservative
block delays.

Pretty straightforward to send such a process (whether it's a program or
a collection of humans) an authenticated signal that says "hey, expect a
withdrawal." This kind of alert allows for cross-referencing the
activity and seems a lot better than nothing!

> Don't you also need the endpoint scriptPubkeys (<cold_pubkey>,
> <hot_pubkey>), the amounts and CSV value ? Though I think you can
> grind amounts and CSV value in case of loss...But I'm not sure if you
> remove the critical data persistence requirement, just reduce the
> surface.

With any use of bitcoin you're going to have critical data that needs to
be maintained (your privkeys at a minimum), so the game is always
reducing surface area. If the presigned-txn vault design
appealed to you as a user, this seems like a strict improvement.

> I'm not sure if the usage of anchor output is safe for any vault
> deployment where the funds stakeholders do not trust each other or
> where the watchtowers are not trusted.

I'm not sure who's proposing that counterparties who don't trust each
other make a vault together. I'm thinking of individual users and
custodians, each of which functions as a single trusted entity.

Perhaps your point here is that if I'm a custodian operating a vault and
someone unexpectedly hacks the fee keys that encumber all of my anchor
outputs, they can possibly pin my attempted response to the unvault
transaction - and that's true. But that doesn't seem like a fault unique
to this scheme, and points to the need for better fee-bumping needs a la
SIGHASH_GROUP or transaction sponsors.[0]

> I would say space efficiency is of secondary concern

If every major custodian ends up implementing some type of vault scheme
(not out of the question), this might be a lot of space! However I'm all
for facilitating the flow of bitcoin from major custodians to miners...
but it seems like we could do that more cleanly with a block size
reduction ;). (JUST KIDDING!)

---

I think your idea about having watchtowers serve double-duty for
lightning channels and vault schemes like this is a very good one!


James


[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html

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

Re: [bitcoin-dev] CTV vaults in the wild

[Antoine Riard]

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

Hi James,

> I don't really see the vaults case as any different from other
> sufficiently involved uses of bitcoin script - I don't remember anyone
> raising these concerns for lightning scripts or DLCs or tapscript use,
> any of which could be catastrophic if wallet implementations are not
> tested properly.

I think on the lightning side there were enough concerns w.r.t bugs
affecting the toolchains in their infancy phases to motivate developers to
bound max channel value to 2^24 for a while [0]

[0] https://github.com/lightning/bolts/pull/590

> By comparison, decreasing amount per vault step and one CSV use
> seems pretty simple. It's certainly easy to test (as the repo shows),
> and really the only parameter the user has is how many blocks to delay
> to the `tohot_tx` and perhaps fee-rate. Not too hard to test
> comprehensively as far as I can tell.

As of today you won't be able to test against bitcoin core that a CSV'ed
transaction is valid for propagation across the network because your
mempool is going to reject it as non-final [1]

[1] https://github.com/bitcoin/bitcoin/pull/21413

Verifying that your whole set of off-chain covenanted transactions is
propagating well at different feerate levels, and there is no surface
offered to a malicious vault co-owner to pin them can turn quickly as a
real challenge, I believe.

> I think the main concern I have with any hashchain-based vault design
> is the immutability of the flow paths once the funds are locked to the
> root vault UTXO.

> Isn't this kind of inherent to the idea of covenants? You're
> precommitting to a spend path. You can put in as many "escape-hatch"
> conditions as you want (e.g. Jeremy makes the good point I should
> include an immediate-to-cold step that is sibling to the unvaulting),
> but fundamentally if you're doing covenants, you're precommitting to a
> flow of funds. Otherwise what's the point?

Yeah, I agree here that's the idea of covenants to commit to a flow of
funds. However, I think leveraging hashchain covenants in terms of  vault
design comes at the price to make transaction generation errors or key
endpoint compromises hardly irrevocable.

I would say you can achieve the same end goal of precommiting to a flow of
funds with "pre-signed" transactions (and actually that's what we do for
lightning) though while still keeping the upgrade emergency option open. Of
course, you re-introduce more assumptions on the devices where the upgrade
keys are laying.

I believe both designs are viable, it's more a matter of explaining
security and reliability trade-offs to the vaults users. They might be even
complimentary as answering different classes of self-custody needs. I'm
just worried as protocol devs, we have a good understanding of those
trade-offs to convey them well to the vaults users and have them make a
well-informed decision.

> Who's saying to trust hardware? Your cold key in the vault structure
> could have been generated by performing SHA rounds with the
> pebbles in your neighbor's zen garden.
>
> Keeping an actively used multi-sig setup secure certainly isn't free or
> easy. Multi-sig ceremonies (which of course can be used in this scheme)
> can be cumbersome to coordinate.
>
> If there's a known scheme that doesn't require covenants, but has
> similar usage and security characteristics, I'd love
> to know it! But being able to lock coins up for an arbitrary amount of
> time and then have advance notice of an attempted spend only seems
> possible with some kind of covenant technique.

Well, if by covenants you include pre-signed transactions vaults designs,
no sadly I don't know schemes offering the same usage and security
characteristics...

> That said, I think this security advantage is only relevant in the
> context of recursive design, where the partial unvault sends back the
> remaining funds to vault UTXO (not the design proposed here).

> I'm not really sure why this would be. Yeah, it would be cool to be able
> to partially unvault arbitrary amounts or something, but that seems like
> another order of complexity. Personally, I'd be happy to "tranche up"
> funds I'd like to store into a collection of single-hop vaults vs.
> the techniques available to us today.

Hmmm if you would like to be able to partially unvault arbitrary amounts,
while still precommitting to the flow of funds, you might need a sighash
flag extension like SIGHASH_ANYAMOUNT ? (my 2 sats, I don't have a design)

Yes, "tranche up" funds where the remainder is sent back to a vault UTXO
sounds to me belonging to the recursive class of design, and yeah I agree
that might be one of the most interesting features of vaults.

> Pretty straightforward to send such a process (whether it's a program or
> a collection of humans) an authenticated signal that says "hey, expect a
> withdrawal." This kind of alert allows for cross-referencing the
> activity and seems a lot better than nothing!

Yep, a nice improvement. And now you enter into a new wormhole of providing
your process with keys to authenticate the signals and how those
non-necessarily bitcoin locking-UTXO keys can be compromised or even how
the alert mechanism can be abused. We know, security is a never over game :D

> With any use of bitcoin you're going to have critical data that needs to
> be maintained (your privkeys at a minimum), so the game is always
> reducing surface area. If the presigned-txn vault design
> appealed to you as a user, this seems like a strict improvement.

I agree here, the critical data surface sounds to be better with
hashchain-based vaults designs.

> I'm not sure who's proposing that counterparties who don't trust each
> other make a vault together. I'm thinking of individual users and
> custodians, each of which functions as a single trusted entity.

If you have a set of custodians, even if they belong to the same
administrative entity, one of them might be compromised or bribed and leak
the anchor output key to an attacker, therefore preventing the remaining
custodians from using the `tocold_tx` ability as expected.

I'm not sure if thinking of the custodians as a single trusted entity is a
hard enough assumption for high-stake vaults designs..

> Perhaps your point here is that if I'm a custodian operating a vault and
> someone unexpectedly hacks the fee keys that encumber all of my anchor
> outputs, they can possibly pin my attempted response to the unvault
> transaction - and that's true. But that doesn't seem like a fault unique
> to this scheme, and points to the need for better fee-bumping needs a la
> SIGHASH_GROUP or transaction sponsors.[0]

Yes agree here.

> I would say space efficiency is of secondary concern

> If every major custodian ends up implementing some type of vault scheme
> (not out of the question), this might be a lot of space! However I'm all
> for facilitating the flow of bitcoin from major custodians to miners...
> but it seems like we could do that more cleanly with a block size
> reduction ;). (JUST KIDDING!)

Haha, designing _inefficient_ off-chain contracts for high buying power
users to have them pay better the miners in a post-block subsidy world.
Sounds smart, well done :)

Antoine

Le mar. 8 mars 2022 à 14:46, James O'Beirne <james.obeirne@gmail.com> a
écrit :

> Hey Antoine,
>
> Thanks for taking a look at the repo.
>
> > I believe it's reasonable to expect bugs to slip in affecting the
> > output amount or relative-timelock setting correctness
>
> I don't really see the vaults case as any different from other
> sufficiently involved uses of bitcoin script - I don't remember anyone
> raising these concerns for lightning scripts or DLCs or tapscript use,
> any of which could be catastrophic if wallet implementations are not
> tested properly.
>
> By comparison, decreasing amount per vault step and one CSV use
> seems pretty simple. It's certainly easy to test (as the repo shows),
> and really the only parameter the user has is how many blocks to delay
> to the `tohot_tx` and perhaps fee-rate. Not too hard to test
> comprehensively as far as I can tell.
>
>
> > I think the main concern I have with any hashchain-based vault design
> > is the immutability of the flow paths once the funds are locked to the
> > root vault UTXO.
>
> Isn't this kind of inherent to the idea of covenants? You're
> precommitting to a spend path. You can put in as many "escape-hatch"
> conditions as you want (e.g. Jeremy makes the good point I should
> include an immediate-to-cold step that is sibling to the unvaulting),
> but fundamentally if you're doing covenants, you're precommitting to a
> flow of funds. Otherwise what's the point?
>
>
> > I think the remaining presence of trusted hardware in the vault design
> > might lead one to ask what's the security advantage of vaults compared
> > to classic multisig setup.
>
> Who's saying to trust hardware? Your cold key in the vault structure
> could have been generated by performing SHA rounds with the
> pebbles in your neighbor's zen garden.
>
> Keeping an actively used multi-sig setup secure certainly isn't free or
> easy. Multi-sig ceremonies (which of course can be used in this scheme)
> can be cumbersome to coordinate.
>
> If there's a known scheme that doesn't require covenants, but has
> similar usage and security characteristics, I'd love
> to know it! But being able to lock coins up for an arbitrary amount of
> time and then have advance notice of an attempted spend only seems
> possible with some kind of covenant technique.
>
> > That said, I think this security advantage is only relevant in the
> > context of recursive design, where the partial unvault sends back the
> > remaining funds to vault UTXO (not the design proposed here).
>
> I'm not really sure why this would be. Yeah, it would be cool to be able
> to partially unvault arbitrary amounts or something, but that seems like
> another order of complexity. Personally, I'd be happy to "tranche up"
> funds I'd like to store into a collection of single-hop vaults vs.
> the techniques available to us today.
>
>
> > I think you might need to introduce an intermediary, out-of-chain
> > protocol step where the unvault broadcast is formally authorized by
> > the vault stakeholders. Otherwise it's hard to qualify "unexpected",
> > as hot key compromise might not be efficiently detected.
>
> Sure; if you're using vaults I think it's safe to assume you're a fairly
> sophisticated user of bitcoin, so running a process that monitors the
> chain and responds immediately with keyless to-cold broadcasts
> doesn't seem totally out of the question, especially with conservative
> block delays.
>
> Pretty straightforward to send such a process (whether it's a program or
> a collection of humans) an authenticated signal that says "hey, expect a
> withdrawal." This kind of alert allows for cross-referencing the
> activity and seems a lot better than nothing!
>
> > Don't you also need the endpoint scriptPubkeys (<cold_pubkey>,
> > <hot_pubkey>), the amounts and CSV value ? Though I think you can
> > grind amounts and CSV value in case of loss...But I'm not sure if you
> > remove the critical data persistence requirement, just reduce the
> > surface.
>
> With any use of bitcoin you're going to have critical data that needs to
> be maintained (your privkeys at a minimum), so the game is always
> reducing surface area. If the presigned-txn vault design
> appealed to you as a user, this seems like a strict improvement.
>
> > I'm not sure if the usage of anchor output is safe for any vault
> > deployment where the funds stakeholders do not trust each other or
> > where the watchtowers are not trusted.
>
> I'm not sure who's proposing that counterparties who don't trust each
> other make a vault together. I'm thinking of individual users and
> custodians, each of which functions as a single trusted entity.
>
> Perhaps your point here is that if I'm a custodian operating a vault and
> someone unexpectedly hacks the fee keys that encumber all of my anchor
> outputs, they can possibly pin my attempted response to the unvault
> transaction - and that's true. But that doesn't seem like a fault unique
> to this scheme, and points to the need for better fee-bumping needs a la
> SIGHASH_GROUP or transaction sponsors.[0]
>
> > I would say space efficiency is of secondary concern
>
> If every major custodian ends up implementing some type of vault scheme
> (not out of the question), this might be a lot of space! However I'm all
> for facilitating the flow of bitcoin from major custodians to miners...
> but it seems like we could do that more cleanly with a block size
> reduction ;). (JUST KIDDING!)
>
> ---
>
> I think your idea about having watchtowers serve double-duty for
> lightning channels and vault schemes like this is a very good one!
>
>
> James
>
>
> [0]:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>

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