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 B511D320D for ; Thu, 1 Aug 2019 19:01:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 39C225F4 for ; Thu, 1 Aug 2019 19:01:13 +0000 (UTC) Date: Thu, 01 Aug 2019 19:01:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1564686070; bh=Jd1cX6U8XSCCljLNrE8F1Ty42E/AWCBagIN9JgnsMjY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=rgJ8F19RRIXef0xyt5+U+dgnfhHikmO/p0ow6mL/SJ/PcwhXYyxTbZ9nHjd3ZU2dw pwk0Jovf05CFI31YtEdrSbWpKm7EXREDbBPxt6+PCZ9IVaymEs1nV2IfKIjIeI/LnM IMJXnJOTI6DOF6F04pYXIVvlrQVr1uvqvs2eD56w= To: bitcoin-dev@lists.linuxfoundation.org, Dmitry Petukhov From: Andrew Chow Reply-To: Andrew Chow Message-ID: In-Reply-To: References: 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: Fri, 02 Aug 2019 03:47:31 +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: Thu, 01 Aug 2019 19:01:13 -0000 I spoke to some people OOB and they said that they didn't really like the idea of having a prefix string (partially because they've already implemented some proprietary types by simply squatting on unused types). Matching the prefix string adds additional complexity to the parser code. The main concern is that people won't want to actually follow the spec for proprietary types and instead just use some unused type value. So I think instead we should do: {0xFC}|{private_type} and the prefix string can be optional (and strongly recommended) after that= . Since public parsers won't really be enforcing the rules for proprietary types, I don't think it really makes sense to specify and enforce how they should be. After all, the key is really just an opaque data blob. In the same vein, it would probably be useful to allow multiple types for proprietary use as originally proposed to make implementation of these easier. If more type are needed, then the private type construction can be used. Andrew On 8/1/19 1:57 PM, Andrew Chow wrote: >=20 > It seems like the consensus is that we should use Compact Size Unsigned > Integers for the field types, so we will do that. The types will be > minimally encoded CSUints. >=20 > For the proprietary types, I will use Dimitry's and Andrew Poelstra's > (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/01671= 3.html) > suggestion. There will be one proprietary type, 0xFC. This will be > followed by a variable length string that is a vendor specific prefix > that serves as a unique identifier to help with preventing usage of > proprietary types outside of private contexts. This will then be > followed by the actual type for the data, as defined by the user of the > proprietary type. >=20 > The prefix will just be a string, prefixed with a compact size unsigned > integer. If no prefix is wanted, then a single 0x00 byte can be used. >=20 > For public software, there is no need to handle these proprietary types > at all so they do not need to check the string or the data type. It is > not necessary to enforce the above rules about proprietary types except > that they use the proprietary type value. >=20 >=20 > Andrew Chow >=20