Re: [bitcoin-dev] OP_VAULT: a new vault proposal

2023-01-18 Thread James O'Beirne via bitcoin-dev
> 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.

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

2023-01-18 Thread James O'Beirne via bitcoin-dev
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

Re: [bitcoin-dev] Pseudocode for robust tail emission

2023-01-18 Thread Peter Todd via bitcoin-dev
On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote: > On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev > wrote: > > > >> This way: > >> > >> 1. system cannot be played > >> 2. only in case of destructive halving: system waits for the recovery of > >> network security > > > >

Re: [bitcoin-dev] OP_VAULT: a new vault proposal

2023-01-18 Thread Billy Tetrud via bitcoin-dev
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