1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Return-Path: <freedom@reardencode.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6F149C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Mar 2023 19:09:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4395B60E26
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Mar 2023 19:09:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4395B60E26
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=reardencode.com header.i=@reardencode.com
header.a=rsa-sha256 header.s=mail header.b=s5VmJVc7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ZY-OOFDB-ZvV
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Mar 2023 19:09:34 +0000 (UTC)
X-Greylist: delayed 00:05:27 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7E68060C08
Received: from mail.reardencode.com (mail.reardencode.com [206.125.169.165])
by smtp3.osuosl.org (Postfix) with ESMTPS id 7E68060C08
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Mar 2023 19:09:34 +0000 (UTC)
Date: Mon, 13 Mar 2023 12:03:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com;
s=mail; t=1678734244;
bh=nWpMTLZnl6AzsUSPYAv1LxDW0TyJuVYmwa0afoVPDfQ=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=s5VmJVc7Ak/gpVIK5v/cycY7EvuhXcHSKPgc/iZXrQVosx58AZlDkDskFxBgiP3Ma
t2psFFLHzZtyM8K0n8mwsKusH3pSHppSbJUdyklMfiRYx9VYNxEEoxCSLiAu39aYPD
oG0k6UyaAy82aCxzYNCKPafPXkfbueq/FQSUwoGQ=
From: Brandon Black <freedom@reardencode.com>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZA9zgqeNiCBfBGUz@console>
Mail-Followup-To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
<CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
<ZAAqIZZO1KK32Th9@erisian.com.au>
<CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
X-Operating-System: Linux 5.15.85 x86_64
X-Mailman-Approved-At: Mon, 13 Mar 2023 20:57:16 +0000
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2023 19:09:35 -0000
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
|
