Andrew, thanks for taking the time.
> It seems like this proposal will encourage address reuse for vaults,
> at least in some parts. It seems like it would not be difficult to
> ensure that each vault address was unique through the use of key
> derivation.
I think it's worth stepping back and not
>> It would usually be prudent to store this recovery address with every key
to the vault, ...
> Worth noting now that in OP_VAULT the recovery path can be optionally
gated by an arbitrary scriptPubKey.
Gating by a scriptPubKey solves the problem I was talking about there.
However, thinking about
> I don't see in the write up how a node verifies that the destination
> of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT
> script.
It's probably quicker for you to just read through the
implementation that I reference in the last section of the paper.
https://github.com/bitcoin
I've implemented three changes based on suggestions from Greg Sanders
and AJ Towns.
I've segmented the changes into commits that should be
reasonable to follow, even though I'll probably rearrange the commit
structure later on.
1. Greg's suggestion: OP_UNVAULT outputs can now live behind
scriptha
I like the proposal of a targeted wallet vault opcode. It keeps things
constrained, limiting objections to those of the form "but if we had X it
would do all this and more so why add this complexity when it will be
obsoleted in the future?"
> An idealized vault
> no existing vault design meets thi
On Mon, Jan 16, 2023 at 11:47:09PM +, Andrew Chow via bitcoin-dev wrote:
> It seems like this proposal will encourage address reuse for vaults,
(That is listed as an explicit goal: "A single vault scriptPubKey should
be able to "receive" multiple deposits")
> However the current construction
Hi James,
This seems like a promising proposal, but I noticed have a few issues
regarding batching and privacy.
It seems like this proposal will encourage address reuse for vaults, at
least in some parts. It seems like it would not be difficult to ensure
that each vault address was unique through
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
Thanks for the thoughtful reply AJ.
> 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
Forwarding in some conceptual feedback from the pull request.
>From ariard:
> I've few open questions, like if the recovery path should be committed
with a signature rather than protected by a simple scriptpubkey preimage.
That's something I've wondered about too. I have to ruminate on AJ's good
Greg explained his suggestion to me off-list, and I think it's a good one.
To summarize, consider the normal "output flow" of an expected vault use:
(i) output to be vaulted
=> (ii) OP_VAULT output
=> (iii) OP_UNVAULT "trigger" output
=> (iv) final output
In my existing draft implemen
On Mon, Jan 09, 2023 at 11:07:54AM -0500, James O'Beirne via bitcoin-dev wrote:
> But I also found proposed "general" covenant schemes to be
> unsuitable for this use. The bloated scriptPubKeys,
I don't think that makes sense? With a general scheme, you'd only be
bloating the witness data (perhaps
Hey Greg,
I think what you're trying to get at here is that the OP_UNVAULT
scriptPubKey *must* be a bare script so that the OP_VAULT spend logic can
verify that we're spending an OP_VAULT output into a compatible OP_UNVAULT
output, and that's true. The OP_UNVAULT scriptPubKey also must contain the
Hi James and co,
Currently there is no way to make this compatible with scripthashes of any
kind, since the script interpreter has no insight into the OP_UNVAULT
outputs' "execution script", and one of the arguments of OP_UNVAULT is
freeform, resulting in an unpredictable output scriptpubkey.
I t
Hey James,
Really cool proposal. I’ve been thinking a lot lately about script paths for
inheritance. In a lot of the “have a relative time lock that allows a different
key to spend coins, or allows a smaller threshold of a multisig to spend”
schemes, you have the problem of needing to “refresh”
For the last few years, I've been interested in vaults as a way to
substantially derisk custodying Bitcoin, both at personal and commercial
scales. Instead of abating with familiarity, as enthusiasm sometimes
does, my conviction that vaults are an almost necessary part of bitcoin's
viability has on
16 matches
Mail list logo
