From: Brandon Black <freedom@reardencode•com>
To: Greg Sanders <gsanders87@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
Date: Mon, 13 Mar 2023 12:03:30 -0700 [thread overview]
Message-ID: <ZA9zgqeNiCBfBGUz@console> (raw)
In-Reply-To: <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
Hi Gents,
> > I don't think replacing the internal-public-key makes sense -- if it
> was immediately spendable via the keypath before there's no reason for
> it not to be immediately spendable now.
>
> Slavishly following the current proposal was the idea to make sure all
> functionality was captured; I agree with this change.
I think we do need to replace the internal key with a hardcoded NUMS
point to allow us to batch multiple vault inputs which might have
different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
the same time+template-restricted output.
I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.
My thoughts on batching:
Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.
Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.
Best,
--Brandon
next prev parent reply other threads:[~2023-03-13 19:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 21:09 James O'Beirne
2023-03-01 15:05 ` Greg Sanders
2023-03-02 4:46 ` Anthony Towns
2023-03-02 14:54 ` Greg Sanders
2023-03-02 19:51 ` Andrew Melnychuk Oseen
2023-03-06 15:25 ` James O'Beirne
2023-03-06 16:07 ` Greg Sanders
2023-03-07 12:45 ` Anthony Towns
2023-03-09 18:45 ` Greg Sanders
2023-03-10 1:08 ` Anthony Towns
2023-03-24 12:10 ` Anthony Towns
2023-03-29 7:10 ` Zac Greenwood
2023-03-29 19:57 ` alicexbt
2023-03-30 0:16 ` Steve Lee
2023-03-30 10:39 ` Zac Greenwood
2023-03-30 18:12 ` alicexbt
2023-03-13 19:03 ` Brandon Black [this message]
2023-03-14 14:40 ` Greg Sanders
2023-03-11 20:53 ` Luke Dashjr
2023-03-13 14:55 ` Greg Sanders
2023-03-13 14:56 ` Greg Sanders
2023-03-13 20:55 ` Luke Dashjr
2023-03-16 14:44 ` Greg Sanders
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=ZA9zgqeNiCBfBGUz@console \
--to=freedom@reardencode$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@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