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 861293D56 for ; Wed, 31 Jul 2019 16:18:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1B64832 for ; Wed, 31 Jul 2019 16:18:20 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 41C20260052E; Wed, 31 Jul 2019 16:18:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1564589899; bh=t0zShvbzKiaVIMuPyRkHwJYUVUXY7iIcsp1H9TtTZEo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DFE/j3jnhHbjrTUn37TxARAeQUx3/83ougbeDMWD9tZ3tLXlmtwIC9rR8xD2R3W7R ofMCtgOYN5FlJaJFHud9+w1FOIApmbC6WWd6o2rDrgDUKCxZWxLkHgFrdMw/kRqXJy WQZkjjurZf8xH6hcZDijk+SjrbXkgr/Wqnjf9RYk= Date: Wed, 31 Jul 2019 21:19:48 +0500 From: Dmitry Petukhov To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20190731211948.1e9e22f2@simplexum.com> In-Reply-To: References: Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU 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 18:19:26 +0000 Subject: Re: [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 16:18:21 -0000 =D0=92 Wed, 31 Jul 2019 01:13:46 +0000 Andrew Chow via bitcoin-dev wrote: > 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. I think private formats should have at least a basic format: they should start with a prefix. This way different prviate formats can be distinguished by this prefix, and there will be no risk of unintentional confusion. Private types can start with the size of the prefix, and then organization can choose any prefix they like, or no prefix, if the size is of the prefix is 0 (means they are fine with possible conflicts with other empty-prefix private types) > 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. >=20 > 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. Why not just say that the types should be encoded as 'compact size unsigned integer' ? This format for variable length integer encoding is already used in the BIP for other fields, and thus will not add any additional complexity to the parsing.