From: Ben Carman <benthecarman@live•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>,
"dlc-dev@mailmanlists•org" <dlc-dev@mailmanlists•org>
Subject: [bitcoin-dev] Using OP_VAULT to improve DLCs
Date: Thu, 12 Jan 2023 12:32:06 +0000 [thread overview]
Message-ID: <SJ1P223MB0531F7DDDFEB49DCF8E92CE9A1FD9@SJ1P223MB0531.NAMP223.PROD.OUTLOOK.COM> (raw)
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3088 bytes --]
next reply other threads:[~2023-01-12 12:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 12:32 Ben Carman [this message]
2023-01-19 22:42 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ1P223MB0531F7DDDFEB49DCF8E92CE9A1FD9@SJ1P223MB0531.NAMP223.PROD.OUTLOOK.COM \
--to=benthecarman@live$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dlc-dev@mailmanlists$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox