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 D5A4B1014 for ; Fri, 2 Aug 2019 09:17:30 +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 4DC1AE7 for ; Fri, 2 Aug 2019 09:17:30 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 570E22600524; Fri, 2 Aug 2019 09:17:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1564737448; bh=XLhBjcHV2BbpvMoBgpNZbgbspHGczzPwsG9ZggpNCaw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=kgaRSTxT3aojGxMO3UI7hTIB/YFJ8qPooBqMCtQbuMLz42Xe1Cd3EdtaTIH4UK0kD F89SqWRqsjpNrQtHMeUoUevFv75WVcLv0qsls1yDOvSsI3w4voSu7bCM8iIy2TOVyX Mgikz44+ZXEWVGhjcsB5aEQ6859vXaDr/FLa8Y0g= Date: Fri, 2 Aug 2019 14:18:36 +0500 From: Dmitry Petukhov To: Andrew Chow Message-ID: <20190802141836.15771ad6@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: Fri, 02 Aug 2019 11:32:47 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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: Fri, 02 Aug 2019 09:17:30 -0000 =D0=92 Thu, 01 Aug 2019 19:01:06 +0000 Andrew Chow wrote: > 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. I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I would like to note that for those who do not want to deal with additional complexity of handling a prefixed string, they can simply not use it at all. Since this is a private construction, and their private format specifies 'no prefix', they can just ignore everything that does not start with "{0xFC}|{0x00}", thus any further complexity regarding the prefix is also ignored. The only added complexity is one condition check: second_byte_of_the_key !=3D 0=20 My other argument for conflict-avoidance prefix as a first thing after 0xFC is that the set of future users of PSBT and private types is most likely much larger than the current set of those who already implemented proprietary types on their own, and thus the overall benefit for the whole industry will likely be bigger when 'i do not want conflict avoidance' decision have to be explicit, by setting the prefix to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. Regarding the 'squatted' types, it seems to me that this only matters in the discussed context if they squatted on 0xFC type in particular. In other cases, they will need to implement changes anyway, to be compatible with the BIP. Maybe they could consider that one additional condition check is a small burden, and maybe they can tolerate that, for the benefit of reducing possibility of interoperability problems between other future PSBT/private types implementors.