From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA3F8C013A for ; Wed, 6 Jan 2021 23:48:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id AEC3386397 for ; Wed, 6 Jan 2021 23:48:49 +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 7NndsO-qw9b2 for ; Wed, 6 Jan 2021 23:48:47 +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 A6C43861B2 for ; Wed, 6 Jan 2021 23:48:47 +0000 (UTC) Received: from mail-02.mail-europe.com (mail-02.mail-europe.com [51.89.119.103]) (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 CA86320000A9 for ; Wed, 6 Jan 2021 23:48:44 +0000 (UTC) Authentication-Results: mail-41104.protonmail.ch; dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com header.b="DAsDJlHC" Date: Wed, 06 Jan 2021 23:48:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail2; t=1609976914; bh=wKLyL2n1UuuiXB/lt8UCW+jrOHoYMRsVoQB34bmUdxI=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=DAsDJlHC3TFyhlZJ7zDLfwXBhVx3CY81H92RnVQrfhyftkC9+7tl/4DATBOn8zFuk my8OoTjL6Z18ychQvW/ofmWn+2o+w1OouumjdZW3UPnTkxX8s0QDBKfwi0Wc9r7SYb hEkhguVc9OmWt8/CXuyiUSvHfwwfvQX3qmcavXssjQ7MIUJe/8Mo0XJGK2AZuORb5o cMeALsx0AQ5NyaP+b3SM1pH95aigTHwJqMCXIWAhzWS7XPxVPSAVv3P5u0wMkuGQjP RlQGbUnI51yepHkZtP1bVKnuWtJzh9g7e9+IMTyGGw/Ofr7s/wH+2MyYiPW5dTMh1p 9lGQQ3p3592lw== To: Rusty Russell , Bitcoin Protocol Discussion From: Andrew Chow Reply-To: Andrew Chow Message-ID: In-Reply-To: <87wnwpabq6.fsf@rustcorp.com.au> References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com> <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 23:48:49 -0000 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. A= ll >> other values ore prohibited. Must be omitted for PSBTv0, may be omitted >> 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 is >> 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=20 there are. Without PSBT_GLOBAL_UNSIGNED_TX, there is no way to determine=20 whether a map is an input map or an output map. So the counts are there=20 to allow that. > 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. > 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. Seems reasonable. Andrew > Thanks! > Rusty. > PS. Perhaps we should change the name to PBT (Partial Bitcoin > Transaction) now, since it's more than just signing...