summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Chow <achow101-lists@achow101.com>2020-12-22 20:12:22 +0000
committerbitcoindev <bitcoindev@gnusha.org>2020-12-22 20:12:41 +0000
commit7b6a14e8e587ae55ffae07e9a946791ad7febaef (patch)
treec23a2d36eb091921100becd83193a0a4e101bee1
parent57445580087176195472f1841ce5288926d0ea07 (diff)
downloadpi-bitcoindev-7b6a14e8e587ae55ffae07e9a946791ad7febaef.tar.gz
pi-bitcoindev-7b6a14e8e587ae55ffae07e9a946791ad7febaef.zip
Re: [bitcoin-dev] New PSBT version proposal
-rw-r--r--e7/8386ba24a59d3291011b624be5b3ff5e6b7815267
1 files changed, 267 insertions, 0 deletions
diff --git a/e7/8386ba24a59d3291011b624be5b3ff5e6b7815 b/e7/8386ba24a59d3291011b624be5b3ff5e6b7815
new file mode 100644
index 000000000..6694e90b0
--- /dev/null
+++ b/e7/8386ba24a59d3291011b624be5b3ff5e6b7815
@@ -0,0 +1,267 @@
+Return-Path: <achow101-lists@achow101.com>
+Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id C26E6C0893
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Dec 2020 20:12:41 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by silver.osuosl.org (Postfix) with ESMTP id A60EA203EB
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Dec 2020 20:12:41 +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 gDSPH9myUnts
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Dec 2020 20:12:38 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
+ [185.70.41.103])
+ by silver.osuosl.org (Postfix) with ESMTPS id 7BD7F20341
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Dec 2020 20:12:38 +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-41103.protonmail.ch (Postfix) with ESMTPS id 7DFAA2000956
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 22 Dec 2020 20:12:36 +0000 (UTC)
+Authentication-Results: mail-41103.protonmail.ch;
+ dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com
+ header.b="L+LeDQBw"
+Date: Tue, 22 Dec 2020 20:12:22 +0000
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
+ s=protonmail2; t=1608667945;
+ bh=1P0c5LBL6WrbzB8k7H8uoXnc2KogKdcOKKcJWtpuVq8=;
+ h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
+ b=L+LeDQBwlYg0c7uYLjD0HZzPtWWXnEgkC9cevKDVr6rqDn/a+xGJUeqPHX8AVX3ib
+ GTmjrW/LRMw7kuE9y2CD3E24Y6Wd0r4lcEQTOccrhrhhtjNL7rZ6evD++M6/FMCRkX
+ ewvKlYz9V6B+L6HGsfAYB9d8iNxOef5ZD+nIB3Idp/qvQRqa1nQbKXjL8Z26HnuRyc
+ B7oPO/KRW5PKp7yoOK5asiMLH9Us+kchM+aRAkQZMAzvN/M2fI2h4LLSnbjWcx3caU
+ j2d2LThvKDrPd8/e+cZOv6ytR6zcdoU5vxa4eiSCHvdgNCNnloR7lPInDP4UxTjR/+
+ Y6PukwA1bkeTg==
+To: 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: <5a4697cb-b9cb-b925-e78f-d5b53f025704@achow101.com>
+In-Reply-To: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
+References: <1dd8c285-e3f4-4f03-d608-103a5026146d@achow101.com>
+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: Tue, 22 Dec 2020 20:12:41 -0000
+
+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=20
+proposal was being referred to as PSBT version 2, so it'll be easier and=20
+clearer to set the version number to 2.
+
+For lock times, instead of a single=C2=A0 PSBT_IN_REQUIRED_LOCKTIME field,=
+=20
+there will be 2 of them, one for a time based lock time, and the other=20
+for height based. These will be:
+* PSBT_IN_REQUIRED_TIME_LOCKTIME =3D 0x10
+ =C2=A0 * Key: empty
+ =C2=A0 * Value: 32 bit unsigned little endian integer greater than or equa=
+l=20
+to 500000000 representing the minimum Unix timestamp that this input=20
+requires to be set as the transaction's lock time. Must be omitted in=20
+PSBTv0, and may be omitted in PSBTv2
+* PSBT_IN_REQUIRED_HEIGHT_LOCKTIME =3D 0x11
+ =C2=A0 * Key: empty
+ =C2=A0 * Value: 32 bit unsigned little endian integer less than 500000000=
+=20
+representing the minimum block height that this input requires to be set=20
+as the transaction's lock time. Must be omitted in PSBTv0, and may be=20
+omitted in PSBTv2.
+
+Having two lock time fields is necessary due to the behavior where all=20
+inputs must use the same type of lock time (height or time). Thus if an=20
+input requires a particular type of lock time, it must set the requisite=20
+field. Any new inputs being added must be able to accommodate all=20
+existing inputs' lock time type. This means they either must not have a=20
+lock time specified (i.e. no OP_CLTV involved), or have branches that=20
+allow the acceptance of either type. If an input has a lock time type=20
+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=20
+option if no input lock time fields are present. If there are input lock=20
+times, all lock time calculations must ignore it.
+
+Any role which does lock time calculation will first check if there are=20
+input lock time fields. If there are not, it must then check for a=20
+PSBT_GLOBAL_PREFERRED_LOCKTIME. If this field exists, its value is the=20
+transaction's lock time. If it does not, the lock time is 0. If there=20
+are input lock time fields, it must choose the type which does not=20
+invalidate any inputs. The lock time is then determined to be the=20
+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 =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.
+
+Several rules must be followed to ensure that adding additional inputs=20
+and outputs will not invalidate existing signatures. First, an input or=20
+output adder must check for any existing signatures in all of the other=20
+inputs. If there are none, the input or output may be added in any=20
+position. If there are one or more signatures, each signature's sighash=20
+type must be examined. Inputs may only be added if all existing=20
+signatures use SIGHASH_ANYONECANPAY. Outputs may only be added if all=20
+existing signatures use SIGHASH_NONE. If an input has a signature using=20
+SIGHASH_SINGLE, the same number of inputs and outputs must be added=20
+before that input and it's corresponding output. For all other sighash=20
+types (i.e. SIGHASH_ALL and any future sighash types), no inputs or=20
+outputs may be added to the PSBT. Specific exceptions can be made in the=20
+future for additional sighash types.
+
+Furthermore, these newly added inputs must follow additional lock time=20
+rules. Because all signatures, regardless of sighash type, sign the=20
+transaction lock time, newly added inputs when there are existing=20
+signatures must have the same type of lock time used in the transaction,=20
+and must be less than or equal to the transaction lock time. It must not=20
+cause the transaction lock time to change, otherwise the signatures will=20
+be invalidated.
+
+
+Lastly, to uniquely identify transactions for combiners, a txid can be=20
+computed from the information present in the PSBT. Internally, combiners=20
+can create an unsigned transaction given the transaction version, the=20
+input prevouts, the outputs, and the computed locktime. This can then be=20
+used to calculate a txid and thus used as a way to identify PSBTs.=20
+Combiners will need to do this for all version 2 PSBTs in order to avoid=20
+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 =3D 0x02
+> =C2=A0 * Key: empty
+> =C2=A0 * Value: 32-bit little endian unsigned integer for the transacti=
+on
+> version number. Must be provided in PSBT v1 and omitted in v0.
+> * PSBT_GLOBAL_PREFERRED_LOCKTIME =3D 0x03
+> =C2=A0 * Key: empty
+> =C2=A0 * 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 =3D 0x04
+> =C2=A0 * Key: empty
+> =C2=A0 * 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 =3D 0x05
+> =C2=A0 * Key: empty
+> =C2=A0 * Value: Compact size unsigned integer. Number of outputs in thi=
+s
+> PSBT. Must be provided in PSBT v1 and omitted in v0.
+>
+> Input:
+> * PSBT_IN_PREVIOUS_TXID =3D 0x0e
+> =C2=A0 * Key: empty
+> =C2=A0 * Value: 32 byte txid of the previous transaction whose output a=
+t
+> PSBT_IN_OUTPUT_INDEX is being spent. Must be provided in PSBT v1 and
+> omitted in v0.
+> * PSBT_IN_OUTPUT_INDEX =3D 0x0f
+> =C2=A0 * Key: empty
+> =C2=A0 * Value: 32 bit little endian integer for the index of the outpu=
+t
+> being spent. Must be provided in PSBT v1 and omitted in v0.
+> * PSBT_IN_SEQUENCE =3D 0x0f
+> =C2=A0 * Key: empty
+> =C2=A0 * 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 =3D 0x10
+> =C2=A0 * Key: empty
+> =C2=A0 * 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 =3D 0x03
+> =C2=A0 * Key: empty
+> =C2=A0 * 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 =3D 0x04
+> =C2=A0 * Key: empty
+> =C2=A0 * 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
+
+
+