path: root/21/e02aab8bf3e2f36a15608033b668737dd525f3

Return-Path: <fiatjaf@alhur.es>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 90384C0893
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Dec 2020 03:45:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 8666A2270C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Dec 2020 03:45:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VFCYQgljDTxn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Dec 2020 03:45:30 +0000 (UTC)
X-Greylist: delayed 00:15:04 by SQLgrey-1.7.6
Received: from sender4-op-o16.zoho.com (sender4-op-o16.zoho.com
 [136.143.188.16])
 by silver.osuosl.org (Postfix) with ESMTPS id B8548203CE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Dec 2020 03:45:30 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1608694223; cv=none; 
 d=zohomail.com; s=zohoarc; 
 b=ISzjwmjcfV4/lQHFX/M+cP6s+9Q8gc+7epawJUgu4ykQbSZGQLuGrvhwFS7h8WxrnYZQA4cnKhDSRUUmeY0KTStCn9gIae9NXyeCquneripEKCZSlx22h51XtxBi9kwI+n7WtzWaPPEBX3zZkW9/fVfbHCvRpuQuUx8NImj60A0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
 s=zohoarc; t=1608694223;
 h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To;
 bh=FIjQNRUL+ugHJUf2fr4FD7WgBBAQca86KEj/kkJ+r/A=; 
 b=iPozNl1gUtx47mPGcAXazgtrGIm1Pb3FnNA+8jxR/rIFME61YWXIYnRcPEJTgEgub8YEMc1iXMGahZXhZd+cIG9M6bDfpFBBIxP/zs6fbTvXayTeWeic9t6vsogrqhnltY/1yyLc2YPuwHqDaXbY1p8e/ywCRHUmX3937RIfP4k=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass  header.i=alhur.es;
 spf=pass  smtp.mailfrom=fiatjaf@alhur.es;
 dmarc=pass header.from=<fiatjaf@alhur.es> header.from=<fiatjaf@alhur.es>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1608694223; 
 s=k1; d=alhur.es; i=fiatjaf@alhur.es;
 h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding;
 bh=FIjQNRUL+ugHJUf2fr4FD7WgBBAQca86KEj/kkJ+r/A=;
 b=n/z7KEBvHUPpDlAmUMROm/gQIVPbAJJH506EC0YlpXQW8bpRTzH/c8jZxOMjy0jm
 XrWqAPcIoQMupcjSdEdgZC4qAQumq/3tx9tdERUY6u7c+RjzLzb1H/MCab0H9NLuLk0
 6l/3AXNqk5CB4bB8RXjxlPdwadJr7gGEgvX+/NbQ=
Received: from mail.zoho.com by mx.zohomail.com
 with SMTP id 1608694220552752.0222613952285;
 Tue, 22 Dec 2020 19:30:20 -0800 (PST)
Date: Wed, 23 Dec 2020 00:30:20 -0300
From: fiatjaf <fiatjaf@alhur.es>
To: "Andrew Chow" <achow101-lists@achow101.com>,
 "Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <1768da5c6f0.f63a34dc413157.2741477427673569054@alhur.es>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-Mailman-Approved-At: Wed, 23 Dec 2020 04:17:16 +0000
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, 23 Dec 2020 03:45:33 -0000

Hi Andrew.

I'm just a lurker here and I have not much experience with PSBTs, but still let me pose this very obvious question and concern: isn't this change going to create a compatibility nightmare, with some software supporting version 1, others supporting version 2, and the ones that care enough about UX and are still maintained being forced to support both versions -- and for no very important reason except some improvements in the way data is structured?

Ultimately I don't think it should matter if some data is structured in not-the-best-possible way, as long as it is clear enough for the computer and for the libraries already written to deal with it. Backwards-compatibility and general interoperability is worth much more than anything else in these cases.

Also let me leave this article here, which I find very important (even if for some reason it ends up not being relevant to this specific case): http://scripting.com/2017/05/09/rulesForStandardsmakers.html

 ---- On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote ----
 > Hi All,
 > 
 > I have some updates on this after speaking with some people off-list.
 > 
 > Firstly, the version number will be set to 2. In most discussions, this 
 > proposal was being referred to as PSBT version 2, so it'll be easier and 
 > clearer to set the version number to 2.
 > 
 > For lock times, instead of a single  PSBT_IN_REQUIRED_LOCKTIME field, 
 > there will be 2 of them, one for a time based lock time, and the other 
 > for height based. These will be:
 > * PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x10
 >    * Key: empty
 >    * Value: 32 bit unsigned little endian integer greater than or equal 
 > to 500000000 representing the minimum Unix timestamp that this input 
 > requires to be set as the transaction's lock time. Must be omitted in 
 > PSBTv0, and may be omitted in PSBTv2
 > * PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x11
 >    * Key: empty
 >    * Value: 32 bit unsigned little endian integer less than 500000000 
 > representing the minimum block height that this input requires to be set 
 > as the transaction's lock time. Must be omitted in PSBTv0, and may be 
 > omitted in PSBTv2.
 > 
 > Having two lock time fields is necessary due to the behavior where all 
 > inputs must use the same type of lock time (height or time). Thus if an 
 > input requires a particular type of lock time, it must set the requisite 
 > field. Any new inputs being added must be able to accommodate all 
 > existing inputs' lock time type. This means they either must not have a 
 > lock time specified (i.e. no OP_CLTV involved), or have branches that 
 > allow the acceptance of either type. If an input has a lock time type 
 > that is incompatible with the rest of the transaction, it must not be added.
 > 
 > PSBT_GLOBAL_PREFERRED_LOCKTIME is changed to purely be the fallback 
 > option if no input lock time fields are present. If there are input lock 
 > times, all lock time calculations must ignore it.
 > 
 > Any role which does lock time calculation will first check if there are 
 > input lock time fields. If there are not, it must then check for a 
 > PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the 
 > transaction's lock time. If it does not, the lock time is 0. If there 
 > are input lock time fields, it must choose the type which does not 
 > invalidate any inputs. The lock time is then determined to be the 
 > maximum value of all of the lock time fields for the chosen type.
 > 
 > 
 > Additionally, I would like to add a new global field:
 > * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
 >    * Key: empty
 >    * 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 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.
 > 
 > Several rules must be followed to ensure that adding additional inputs 
 > and outputs will not invalidate existing signatures. First, an input or 
 > output adder must check for any existing signatures in all of the other 
 > inputs. If there are none, the input or output may be added in any 
 > position. If there are one or more signatures, each signature's sighash 
 > type must be examined. Inputs may only be added if all existing 
 > signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all 
 > existing signatures use SIGHASH_NONE. If an input has a signature using 
 > SIGHASH_SINGLE, the same number of inputs and outputs must be added 
 > before that input and it's corresponding output. For all other sighash 
 > types (i.e. SIGHASH_ALL and any future sighash types), no inputs or 
 > outputs may be added to the PSBT. Specific exceptions can be made in the 
 > future for additional sighash types.
 > 
 > Furthermore, these newly added inputs must follow additional lock time 
 > rules. Because all signatures, regardless of sighash type, sign the 
 > transaction lock time, newly added inputs when there are existing 
 > signatures must have the same type of lock time used in the transaction, 
 > and must be less than or equal to the transaction lock time. It must not 
 > cause the transaction lock time to change, otherwise the signatures will 
 > be invalidated.
 > 
 > 
 > Lastly, to uniquely identify transactions for combiners, a txid can be 
 > computed from the information present in the PSBT. Internally, combiners 
 > can create an unsigned transaction given the transaction version, the 
 > input prevouts, the outputs, and the computed locktime. This can then be 
 > used to calculate a txid and thus used as a way to identify PSBTs. 
 > Combiners will need to do this for all version 2 PSBTs in order to avoid 
 > combining distinct transactions.
 > 
 > 
 > Andrew Chow
 > 
 > On 12/9/20 5:25 PM, Andrew Chow wrote:
 > > Hi All,
 > >
 > > I would like to propose a new PSBT version that addresses a few
 > > deficiencies in the current PSBT v0. As this will be backwards
 > > incompatible, a new PSBT version will be used, v1.
 > >
 > > The primary change is to truly have all input and output data for each
 > > in their respective maps. Instead of having to parse an unsigned
 > > transaction and lookup some data from there, and other data from the
 > > correct map, all of the data for an input will be contained in its map.
 > > Doing so also disallows PSBT_GLOBAL_UNSIGNED_TX in this new version.
 > > Thus I propose that the following fields be added:
 > >
 > > Global:
 > > * PSBT_GLOBAL_TX_VERSION = 0x02
 > >     * Key: empty
 > >     * Value: 32-bit little endian unsigned integer for the transaction
 > > version number. Must be provided in PSBT v1 and omitted in v0.
 > > * PSBT_GLOBAL_PREFERRED_LOCKTIME = 0x03
 > >     * Key: empty
 > >     * Value: 32 bit little endian unsigned integer for the preferred
 > > transaction lock time. Must be omitted in PSBT v0. May be provided in
 > > PSBT v1, assumed to be 0 if not provided.
 > > * PSBT_GLOBAL_INPUT_COUNT = 0x04
 > >     * Key: empty
 > >     * Value: Compact size unsigned integer. Number of inputs in this
 > > PSBT. Must be provided in PSBT v1 and omitted in v0.
 > > * PSBT_GLOBAL_OUTPUT_COUNT = 0x05
 > >     * Key: empty
 > >     * Value: Compact size unsigned integer. Number of outputs in this
 > > PSBT. Must be provided in PSBT v1 and omitted in v0.
 > >
 > > Input:
 > > * PSBT_IN_PREVIOUS_TXID = 0x0e
 > >     * Key: empty
 > >     * Value: 32 byte txid of the previous transaction whose output at
 > > PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
 > > omitted in v0.
 > > * PSBT_IN_OUTPUT_INDEX = 0x0f
 > >     * Key: empty
 > >     * Value: 32 bit little endian integer for the index of the output
 > > being spent. Must be provided in PSBT v1 and omitted in v0.
 > > * PSBT_IN_SEQUENCE = 0x0f
 > >     * Key: empty
 > >     * Value: 32 bit unsigned little endian integer for the sequence
 > > number. Must be omitted in PSBT v0. May be provided in PSBT v1 assumed
 > > to be max sequence (0xffffffff) if not provided.
 > > * PSBT_IN_REQUIRED_LOCKTIME = 0x10
 > >     * Key: empty
 > >     * Value: 32 bit unsigned little endian integer for the lock time that
 > > this input requires. Must be omitted in PSBT v0. May be provided in PSBT
 > > v1, assumed to be 0 if not provided.
 > >
 > > Output:
 > > * PSBT_OUT_VALUE = 0x03
 > >     * Key: empty
 > >     * Value: 64-bit unsigned little endian integer for the output's
 > > amount in satoshis. Must be provided in PSBT v1 and omitted in v0.
 > > * PSBT_OUT_OUTPUT_SCRIPT = 0x04
 > >     * Key: empty
 > >     * Value: The script for this output. Otherwise known as the
 > > scriptPubKey. Must be provided in PSBT v1 and omitted in v0.
 > >
 > > This change allows for PSBT to be used in the construction of
 > > transactions. With these new fields, inputs and outputs can be added as
 > > needed. One caveat is that there is no longer a unique transaction
 > > identifier so more care must be taken when combining PSBTs.
 > > Additionally, adding new inputs and outputs must be done such that
 > > signatures are not invalidated. This may be harder to specify.
 > >
 > > An important thing to note in this proposal are the fields
 > > PSBT_GLOBAL_PREFERRED_LOCKTIME and PSBT_IN_REQUIRED_LOCKTIME. A Bitcoin
 > > transaction only has a single locktime yet a PSBT may have multiple
 > > locktimes. To choose the locktime for the transaction, finalizers must
 > > choose the maximum of all of the *_LOCKTIME fields.
 > > PSBT_IN_REQUIRED_LOCKTIME is added because some inputs, such as those
 > > involving OP_CHECKLOCKTIMEVERIFY, require a specific minimum locktime to
 > > be set. This field allows finalizers to choose a locktime that is high
 > > enough for all inputs without needing to understand the scripts
 > > involved. The PSBT_GLOBAL_PREFERRED_LOCKTIME is the locktime to use if
 > > no inputs require a particular locktime.
 > >
 > > As these changes disallow the PSBT_GLOBAL_UNSIGNED_TX field, PSBT v1
 > > needs the version number bump to enforce backwards incompatibility.
 > > However once the inputs and outputs of a PSBT are decided, a PSBT could
 > > be "downgraded" back to v0 by creating the unsigned transaction from the
 > > above fields, and then dropping these new fields.
 > >
 > > If the list finds that these changes are reasonable, I will write a PR
 > > to modify BIP 174 to incorporate them.
 > >
 > > Thanks,
 > > Andrew Chow
 > 
 > 
 > _______________________________________________
 > bitcoin-dev mailing list
 > bitcoin-dev@lists.linuxfoundation.org
 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 >