From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2CF723559 for ; Wed, 31 Jul 2019 01:13:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBE6C2C6 for ; Wed, 31 Jul 2019 01:13:55 +0000 (UTC) Date: Wed, 31 Jul 2019 01:13:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1564535633; bh=B+8sQp6PevQkOkeF5TTS5rBfOPDCPmjF4ppXZkKoOy4=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=ksFIVyLvyCaf7Pj999jndgfHbyCf0glTybqx/vbdA2XHtEfCyyXq9F/+PC7nLICP6 iY7l1cL2OdGY8BlT17GiJ90cJ/Ir3RiyNbkxd9bxB61HwPk2TavVHd4xs1S6bihsYA 52Y5vv8bmXit7m5AfrH1HTpv6q9m/7uioz0VcRQo= To: Bitcoin Protocol Discussion From: Andrew Chow Reply-To: Andrew Chow Message-ID: Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 31 Jul 2019 13:17:09 +0000 Subject: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 01:13:57 -0000 Hi All, I would like to propose some types that allow for BIP 174 PSBT to be extended more in the future. Firstly, I would like to propose that some types be reserved for proprietary use. These proprietary use types are, in general, for private use by individuals and organizations who want to use PSBT in their processes. These are usefule when there are additional data that they need attached to a PSBT but such data are not useful (or available) for the general public. These types will be guaranteed to not be used by the public specification and there is no expectation that any publicly available software be able to understand any specific meanings of these types. These types should be used for internal processes only. The types I would like to reserve for proprietary use are the 15 types from 0xF0 to 0xFE inclusive. These 15 type values will be the same for global, per-input, and per-output types. If 15 types are not enough, additional types can be obtained using the multi-byte type method described later. Next, I would like to propose a global version type and field. The version type is 0xEF with only the type as the key, and the value is a 32-bit unsigned little endian integer representing the version number. A PSBT without a version number is to be considered version 0. If a parser sees a version number that it does not understand, it should exit immediately as the PSBT will contain types that are not safe to ignore. This version number is a safeguard in the event that a backwards incompatible change is introduce to PSBT. While PSBT is designed and intended to be forwards compatible by allowing parsers to ignore types that they do not understand, it is possible that at ype is added in the future which breaks this assumption and it would be unsafe for a type to be ignored. Updaters and combiners that need to add a version number to a PSBT should use the highest version number required. For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1. If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified. It is not expected that the version number will ever be used. We try to make PSBT fields safe to ignore. The version number is only being included here as a safeguard in the event that breaking compatibilty is required. Lastly, I would like to propose the canonical method for mult-byte types. We designate a specific type to indicate that the type is multiple bytes. When such types are observed, parsers should move onto the next byte and interpret that as the type, keeping in mind the number of bytes that were read in for the type. I propose that we use 0xFF as this designated type. When a parser sees an 0xFF value as the type, it reads the next byte as being part of the type. So two byte types will be of the form 0xFFXX. This method allows us to do a prefix match in order to quickly identify the type being used. For types with more bytes, simply use another 0xFF byte. So three byte types would be of the form 0xFFFFXX, four byte, 0xFFFFFFXX, and so on. When multi-byte types are specified in the BIP, they should be specified in this full length form, i.e. two byte types as 0xFFXX. The same mechanism can be used for the proprietary use types, just with a different value as the designated multi-byte indicator. For example, one could use 0xFE as the designated type as that is in the proprietary types range. Of course any type within the proprietary type range could be used as the indicator, it is up to the users to determine this themselves. While other methods of indicating multiple bytes and lengths may be more space efficient and allow us to have more types represented in a smaller space, I am choosing this method because of its simplicity. This is easy to understand and implement. Furthermore, I do not expect that we will use so many types. I don't think that we will need to have more than one byte types for a very long time. Please let me know your thoughts on these extensions. I will open a PR to the bips repo to add these to BIP 174 if there are no objections. Andrew Chow