From: Anthony Towns <aj@erisian•com.au>
To: James O'Beirne <james.obeirne@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Date: Wed, 11 Jan 2023 16:52:28 +1000 [thread overview]
Message-ID: <Y75crCH6THK98oee@erisian.com.au> (raw)
In-Reply-To: <CAPfvXfJSJwJ=0wYev7RDBzvgoi5D3HS8sjKqMxM9wcuh3FHvGw@mail.gmail.com>
On Tue, Jan 10, 2023 at 03:22:54PM -0500, James O'Beirne wrote:
> > I don't think that makes sense? With a general scheme, you'd only be
> > bloating the witness data (perhaps including the witness script) not
> > the scriptPubKey?
> Sorry, sloppy language on my part. To be charitable, I'm talking about
> the "figurative sPK," which of course these days lives in the witness
> for script-path-ish spends. Maybe the witness discount means that
> "complicated" scripts aren't as big a deal, depending on the actual
> difference in raw script size.
Sure. I think there's three aspects that matter for the witness script:
1) it shouldn't be long/costly to do things that are common and easy:
if you can express "OP_VAULT" in ~70 bytes, you shouldn't have to
spend 1000 bytes to do so; if it can be cheap to validate, you
shouldn't have to pay 100x markup in fees to use it. With the
exception of things that build up from basics (like
CAT/CHECKSIGFROMSTACK approaches), I think this is mostly fine
though.
2) once someone figures out a design, it should be easy to reuse;
but I think that's not a big deal: you just write up a spec for
your script, and people use that in their different wallet software,
much like the specialised scripts for lightning HTLCs
3) primitives should be designed to be easy to safely build on and
scripts should be as easy as possible to analyse once written;
ie, we want things more like miniscript than "The story of Mel,
a Real Programmer"
With some caveats (like that using the cold wallet xpub to scan the
blockchain before you've frozen all your funds is dangerous), OP_VAULT
seems really good on all those fronts, of course.
> > I think it might be better to use a pay-to-contract construction for
> > the recovery path, rather than an empty witness.
> So I guess the one advantage that what you're proposing has over just
> using a recovery-path key signature is that it's all derivable from your
> cold privkey; you don't have to worry about accidentally losing the
> recovery-path key.
> Of course you're still vulnerable to spurious sweeps if the
> sha256(secret) value gets found out, which presumably you'd want in an
> accessible cache to avoid touching the cold secret every time you want
> to sweep.
Sure, "sha256(secret)" itself needs to be semi-secret -- it allows anyone
who knows it to freeze your funds, even if it doesn't allow anyone to
steal them. You could presumably do all the usual things to protect that
secret: split it up with secret sharing; put it in a hardware wallet;
keep it offline; etc.
> What do you think about the idea of making the recovery-path
> authorization behavior variable on a single byte flag preceding the 32
> byte data push, as I mentioned in another post?
] "if
] <recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's
] 33 bytes, use the first byte as a parameter for how to interpret it." To
] start with, an extra prefix byte of 0x00 could mean "require a witness
] satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the
] same way we do the unvault signing.
I don't think 33 bytes would be enough? There isn't really a way to
commit to the recovery destination within the script? So I think you'd
need "<32 byte recovery-path-hash><n byte scriptPubKey>"
Aside from that, my opinion's one/all of:
a) sounds fine
b) maybe you could just always have it include a scriptPubKey? for the
times when you just want "reveal the cold wallet preimage" just have
the scriptPubKey be the single byte "OP_TRUE"; for the times when you
it to be "reveal random preimage" you'd have it be the 22 byte "HASH160
<hash160(sha256(secret))> EQUAL"?
c) delegation to a script is a great idea, that's come up multiple times
(OP_EVAL, BIP117, graftroot) -- it's probably better to have it
available as a generic feature, than bolted on to particular features
> > I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace
> > "<h> OP_CTV" with "<000..0> 0 <h> OP_UNVAULT".
> Yup, that's an inefficient way of emulating CTV.
Sure; I think it's only interesting in establishing how powerful the
construct is in the abstract. It's not an exact match for CTV since it
hashes some things differently.
I don't really think it's necessarily that inefficient fwiw; "0 SHA256
0 <h> UNVAULT" is only 3 more bytes than "<h> CTV", could give you an
unspendable recovery path, provided UNVAULT wants either a BIP341 tagged
hash (which is what the implementation does, by the looks), or a HASH256
for the recovery path.
(Again, this assumes UNVAULT is available in script, and isn't just a
special scriptPubKey type)
> > I think there's maybe a cleverer way of batching / generalising
> > checking that input/output amounts match.
> > [...]
> > * set C = the sum of each output that has a vault tag with
> > #recovery=X
> This would also need to take into account that the <spend-delay>s are
> compatible, but your point is well taken.
Sure, I guess output/UNVAULT delay >= input/VAULT delay would be
sufficient for that.
I guess having all that stuff exposed in the scriptPubKey would be
slightly annoying for griefing -- you set your wallet delay to be 1008
blocks, and someone sends to your vault with a 1007 block delay, or a
6 block delay: does your wallet notice the tx? if it does, what do you
do with those funds?
Maybe that would be a(nother) good reason to hide the OP_VAULT side of
things in taproot (or p2wsh): then you just have a (shorter) taproot
sPK that encodes both things, and people normally don't even have enough
information to correctly tweak your sPK to have a different delay.
> I can see what you're saying about having more generic "group amounts by
> compatible vault params, and then compare to similarly grouped outputs,"
I mostly wrote that up because that's what I imagined your batching
doing before I'd finished reading...
A big disadvantage of that approach compared to yours is that you have
to analyse a potentially arbitrarily large transaction as a whole while
validating each input -- this input uses recovery key XXX which output's
match; this input uses recovery key YYY; oh, this one uses XXX again;
etc. With your approach, you only have to look at particular outputs.
An advantage of that extra complexity is that you could combine operations
from multiple different vaults into a single transaction, potentially
along with fees or a coinjoin or whatever else. Maybe that would be
interesting if this were something you could code in script via some
generic opcodes; but here it would be extra complexity in consensus code,
and it doesn't seem like a good match for OP_VAULT's design parameters.
Cheers,
aj
next prev parent reply other threads:[~2023-01-11 6:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 16:07 James O'Beirne
2023-01-09 19:02 ` rot13maxi
2023-01-09 19:31 ` Greg Sanders
2023-01-09 20:32 ` James O'Beirne
2023-01-10 13:35 ` James O'Beirne
2023-01-10 12:29 ` Anthony Towns
2023-01-10 20:22 ` James O'Beirne
2023-01-11 6:52 ` Anthony Towns [this message]
2023-01-10 14:17 ` James O'Beirne
2023-01-16 23:47 Andrew Chow
2023-01-17 7:46 ` Anthony Towns
2023-01-18 19:00 ` Billy Tetrud
2023-01-18 23:37 ` James O'Beirne
2023-01-19 22:49 ` Billy Tetrud
2023-01-18 22:45 ` James O'Beirne
2023-01-20 17:43 ` James O'Beirne
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=Y75crCH6THK98oee@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=james.obeirne@gmail$(echo .)com \
/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