summaryrefslogtreecommitdiff
path: root/ac/983bdfae2ce3dce589f1e172a7e81e8a6ca163
blob: 10848089ad2867578caa8ae3ec0eb1a65f02c1d8 (plain)
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
Return-Path: <rusty@ozlabs.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 51C12C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jan 2021 23:26:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 4E3A186DE6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jan 2021 23:26:45 +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 a3TNuHWf+438
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jan 2021 23:26:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1])
 by whitealder.osuosl.org (Postfix) with ESMTPS id DA3C286DA0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jan 2021 23:26:43 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
 id 4DB5995PCTz9sW0; Thu,  7 Jan 2021 10:26:37 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Andrew Chow <achow101-lists@achow101.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
 <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
Date: Thu, 07 Jan 2021 09:56:25 +1030
Message-ID: <87wnwpabq6.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: Wed, 06 Jan 2021 23:26:45 -0000

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=
=20
> other values ore prohibited. Must be omitted for PSBTv0, may be omitted=20
> in PSBTv2.
>
> PSBT_GLOBAL_UNDER_CONSTRUCTION is used to signal whether inputs and=20
> outputs can be added to the PSBT. This flag may be set to True when=20
> inputs and outputs are being updated, signed, and finalized. However=20
> care must be taken when there are existing signatures. If this field is=20
> omitted or set to False, no further inputs and outputs may be added to=20
> 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?

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.

Otherwise, if an explicit marker is required, I would omit the value and
simply use its existence to as a flag.  Having two "false" values is
simply asking for trouble.

Thanks!
Rusty.
PS.  Perhaps we should change the name to PBT (Partial Bitcoin
     Transaction) now, since it's more than just signing...