Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-06 📝 Original message:Hi James, Interesting to ...
📅 Original date posted:2022-03-06
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220306/167be24f/attachment-0001.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220306/167be24f/attachment-0001.html>;