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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
Return-Path: <achow101-lists@achow101.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3BAC4C013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 17:08:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 2A2BF85C4C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 17:08:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 09JZJpeHh+xC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 17:08:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
[185.70.41.104])
by whitealder.osuosl.org (Postfix) with ESMTPS id C409385EA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 17:08:10 +0000 (UTC)
Received: from mail-03.mail-europe.com (mail-03.mail-europe.com
[91.134.188.129])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits))
(No client certificate requested)
by mail-41104.protonmail.ch (Postfix) with ESMTPS id 0DAE92011106
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 17:08:07 +0000 (UTC)
Authentication-Results: mail-41104.protonmail.ch;
dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com
header.b="P6jT8THc"
Date: Thu, 14 Jan 2021 17:07:44 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail2; t=1610644072;
bh=d5gMcggYuPKeW5woEYUB1rhReffQGQx/Lti9QAmvESc=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=P6jT8THcBEhzCgoOiv9zJDs50wep0R6/Wu2ggHMF9sZCXoGqNeXpZrUimFIBeIRxO
CcDRwfrBclqDMhxNJno8hCYsNV37GBuzksy+t6YfU8Hsq+8nz2DbPf8sA3tZSiwLih
/ztd5NGwZx/66WDiEfYtibcmhzq0/6AJ2bGoP59H0z0GlBfOpXOUVxVOcjsZp7wfQp
klNXTSe67zJW5raBsM9DRoQorh7PUzhPiVrFwOAvSm9R2Xi6WIqn2qYBGAxIiDNO2N
529EM2zmbm+FQRRM8p9lSRHKBd0QagzeqqGH4SMoit2WRoggvnG8J4Qh9DNzZPABcX
GYY5bMaCqOBlA==
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <40f91a9a-6905-ad94-2824-16b43a0fa1fa@achow101.com>
In-Reply-To: <87a6tk9s7t.fsf@rustcorp.com.au>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
<5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
<87wnwpabq6.fsf@rustcorp.com.au>
<f20b7586-26b5-2250-322c-3004563f561e@achow101.com>
<87a6tk9s7t.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] New PSBT version proposal
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: Thu, 14 Jan 2021 17:08:13 -0000
On 1/7/21 7:40 PM, Rusty Russell wrote:
> Andrew Chow <achow101-lists@achow101.com> writes:
>> Hi Rusty,
>>
>> On 1/6/21 6:26 PM, Rusty Russell wrote:
>>> Hi Andrew et al,
>>>
>>> Very excited to see this progress; thanks for doing all the
>>> work! Sorry for the delayed feedback, I didn't get to this before the
>>> break.
>>>
>>>> Additionally, I would like to add a new global field:
>>>> * PSBT_GLOBAL_UNDER_CONSTRUCTION =3D 0x05
>>>> =C2=A0 * Key: empty
>>>> =C2=A0 * Value: A single byte as a boolean. 0 for False, 1 for True=
. All
>>>> other values ore prohibited. Must be omitted for PSBTv0, may be omitte=
d
>>>> in PSBTv2.
>>>>
>>>> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and
>>>> outputs can be added to the PSBT. This flag may be set to True when
>>>> inputs and outputs are being updated, signed, and finalized. However
>>>> care must be taken when there are existing signatures. If this field i=
s
>>>> omitted or set to False, no further inputs and outputs may be added to
>>>> the PSBT.
>>> I wonder if this can be flagged simply by omitting the (AFAICT
>>> redundant) PSBT_GLOBAL_INPUT_COUNT and PSBT_GLOBAL_OUTPUT_COUNT? What
>>> are the purposes of those fields?
>> The purpose of those fields is to know how many input and output maps
>> there are. Without PSBT_GLOBAL_UNSIGNED_TX, there is no way to determine
>> whether a map is an input map or an output map. So the counts are there
>> to allow that.
> Ah, yeah, you need at least the number of input maps :(
>
> It's generally preferable to have sections be self-describing;
> internally if you have a function which takes all the input maps you
> should be able to trivially tell if you're handed the output maps by
> mistake. Similarly, it would have been nice to have an input map be a
> distinctly marked type from global or output maps.
>
> Nonetheless, that's a bigger change. You could just require a double-00
> terminator between the global, input and output sections though.
Changing that is a bigger change and I'd rather keep this as minimal as=20
possible. Having only new fields is simpler.
>>> For our uses, there would be no signatures at this stage; it's simply a
>>> subdivision of the Creator role. This role would be terminated by
>>> removing the under-construction marker. For this, it could be clear
>>> that such an under-construction PSBT SHOULD NOT be signed.
>> There are some protocols where signed inputs are added to transactions.
> Sure, but you can't solve every problem. We've now created the
> possibility that a PSBT is "under construction" but can't be modified,
> *and* a very invasive requirement to determine that.
>
> I disagree with Andrew's goal here:
>
>> 1. PSBT provides no way to modify the set of inputs or outputs after =
the
>> Creator role is done.
> It's simpler if, "the under-construction PSBT can be used within the
> Creator role, which can now have sub-roles".
>
> If you really want to allow this (and I think we need to explore
> concrete examples to justify this complexity!), better to add data to
> PSBT_GLOBAL_UNDER_CONSTRUCTION:
> 1. a flag to indicate whether inputs are modifiable.
> 2. a flag to indicate whether outputs are modifiable.
> 3. a bitmap of what inputs are SIGHASH_SINGLE.
>
> If you add a signature which is not SIGHASH_NONE, you clear the "outputs
> modifiable" flag. If you add a signature which is not
> SIGHASH_ANYONECANPAY, you clear the "inputs modifiable" flag. If you
> clear both flags, you remove the PSBT_GLOBAL_UNDER_CONSTRUCTION
> altogether. You similarly set the bitmap depending on whether all sigs
> are SIGHASH_SINGLE.
I think we do need to support adding signed inputs and adding inputs to=20
signed transactions. Someone had asked for this feature before.=20
Additionally Nicolas Dorier informed me that his NTumbleBit project does=20
those things.
In that case, I will include your suggestions for=20
PSBT_GLOBAL_UNDER_CONSTRUCTION in the BIP.
Andrew Chow
>
> Cheers,
> Rusty.
|
