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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CF4707856
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 18:17:27 +0000 (UTC)
X-Greylist: delayed 00:09:24 by SQLgrey-1.7.6
Received: from mail.wpsoftware.net (wpsoftware.net [96.53.77.134])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 86AD2318
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 18:17:26 +0000 (UTC)
Received: from boulet (boulot.lan [192.168.0.193])
by mail.wpsoftware.net (Postfix) with ESMTPSA id BDDCD400F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Mar 2019 18:08:01 +0000 (UTC)
Date: Wed, 6 Mar 2019 18:08:00 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20190306180800.GC10453@boulet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 07 Mar 2019 10:14:22 +0000
Subject: [bitcoin-dev] BIP174 / PSBT extensions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Mar 2019 18:17:27 -0000
Hi all,
I'd like to start initial discussion about an extension to BIP174 [1] to add
some fields that I've found myself wanting when using PSBT in practice. For
now I'll just list the things that I'd like to see, and if we can come up
with a stable list then I'll try to write up a more formal draft.
Basically I'd just like to add some more fixed data fields.
1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contai=
ns
just a txid of the unsigned transaction, for bandwidth savings in case
signers have already seen the tx or can construct it themselves.
This field would be fixed 32 bytes.
(This would actually be a breaking change since the current PSBT rules r=
equire
PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for =
that
reason alone.)
2. Add a version field to the global table.
3. Add fields to the per-input tables for
(a) confirmed depth of the referenced txout; this is useful for finalize=
rs
trying to create optimized witnesses, for e.g. cases when CSV timeou=
ts
expire and some signatures become unnecessary.
This field must be a varint.
(b) a map from SHA2 hashes to their 32-byte preimages; this field must be
fixed 32 bytes. This, plus the CSV thing, would allow writing finali=
zers
that work with all of Miniscript [2].
(c) a map from public keys to 32-byte "tweaks" that are used in the pay-=
to-contract
construction. Selfishly I'd like this to be a variable-length bytest=
ring
with the semantics that (a) the first 33 bytes represent an untweaked
pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G=
and
added to the untweaked pubkey, result in the target key. This matche=
s the
algorithm in [3] which is deployed in Blockstream's Liquid, but I'd =
be
happy with a more efficient scheme which e.g. used SHA256 rather than
HMAC-SHA256.
(d) maps from public keys to partial nonce commitments, partial nonces, =
and
partial signatures, for MuSig [4] support.
(e) a map from signatures (or signature nonces?) to sign-to-contract twe=
aks.
Same semantics as (c) above.
The last two suggestions are probably premature and need further develop=
ment
and standardization of the related protocols. But I'm throwing them in t=
o see
if other people have strong feelings about this.
4. Add fields to the per-output tables for pay-to-contract, like in (c) abo=
ve.
5. Add a field (or rather, family of fields) to every table which is "propr=
ietary
use" and guaranteed not to be defined by any future PSBT extension. Spec=
ifically
every field with key-type 0xFF could be considered "proprietary".
5a. The special field in the global table whose key is only 0xFF should be a
"proprietary version field" with unspecified semantics but an understan=
ding
that specific users might stick a GUID or something in there as a way to
recognize their own PSBTs.
[1] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding
[2] http://bitcoin.sipa.be/miniscript/miniscript.html
[3] https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/va=
lidation.cpp
[4] https://eprint.iacr.org/2018/068
--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"There are some mornings when the sky looks like a road
There are some dragons who were built to have and hold
And some machines are dropped from great heights lovingly
And some great bellies ache with many bumblebees
And they sting so terribly"
--Joanna Newsom
|
