Ben Carman [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-12 🗒️ Summary of this message: A proposal ...
📅 Original date posted:2023-01-12
🗒️ Summary of this message: A proposal suggests using OP_UNVAULT with a burn address and a delay period of 0 as a not-so-simple covenant, similar to CTV, to create output restrictions. This could save computational costs but use more blockchain space.
📝 Original message:Hi list,
After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet.
Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output.
When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN `<random value>`)
and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being
set to whatever output restrictions you want to create.
Given this we can recreate a lot of what CTV promises, one of my favorites being
[Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)
(I recommend reading that first)
A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like:
`<hash-of-burn-spk> 0 <CET-hash_i> OP_UNVAULT <CET_i> CHECKSIG`
In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
hash is `CET-hash`) which distributes the funds according to the contract.
## Comparison
Compared to the original CTV proposal, this should get all the same computational savings. However, it would use more blockchain space.
The main downside I see is our final spending script will be slightly larger.
Instead of just having `<hash> OP_CTV` it will be replaced with `<hash> 0 <hash> OP_UNVAULT` (34 bytes extra, not including the witness discount).
However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block.
This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig.
I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick.
# Credits
- Lloyd Fournier for the original proposal
- James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230112/192b1f7f/attachment.html>;
🗒️ Summary of this message: A proposal suggests using OP_UNVAULT with a burn address and a delay period of 0 as a not-so-simple covenant, similar to CTV, to create output restrictions. This could save computational costs but use more blockchain space.
📝 Original message:Hi list,
After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet.
Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output.
When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN `<random value>`)
and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being
set to whatever output restrictions you want to create.
Given this we can recreate a lot of what CTV promises, one of my favorites being
[Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html)
(I recommend reading that first)
A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like:
`<hash-of-burn-spk> 0 <CET-hash_i> OP_UNVAULT <CET_i> CHECKSIG`
In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash`
hash is `CET-hash`) which distributes the funds according to the contract.
## Comparison
Compared to the original CTV proposal, this should get all the same computational savings. However, it would use more blockchain space.
The main downside I see is our final spending script will be slightly larger.
Instead of just having `<hash> OP_CTV` it will be replaced with `<hash> 0 <hash> OP_UNVAULT` (34 bytes extra, not including the witness discount).
However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block.
This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig.
I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick.
# Credits
- Lloyd Fournier for the original proposal
- James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT
Best,
benthecarman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230112/192b1f7f/attachment.html>;