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 D546B410D for ; Wed, 31 Jul 2019 19:16:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC5B2A8 for ; Wed, 31 Jul 2019 19:16:41 +0000 (UTC) Date: Wed, 31 Jul 2019 19:16:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com; s=protonmail; t=1564600599; bh=kW3SVlk3VMp5vQUD8wEdUB/4t4QMlEwpB8zeP59ItmY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=hE15W06QG43/aOVA2TQ45N+Zd1NeKrOccUWjMHbXLbHhFsG7Fsn7JazX9kELTMjEW 6Dcx59HLUDE56iEePbgxC9oFqUEyGxCAQfRO8iXErNt7kFU4ZBJjRtSSEhPDWUnNFy PJolFKb7DYw2rqbWwPzSLzAsBVfJsBr0KH8M6zL8= To: Dmitry Petukhov , bitcoin-dev@lists.linuxfoundation.org From: Andrew Chow Reply-To: Andrew Chow Message-ID: <766lR1Xtq2ymdINURSNHByDQmkb4hT0VqDx-N8_iq1tmcUMwc96WQtKlCX5Eiq0blk56fur7t2iMZGDmb40qk-pewwJILhDRrrbxnyVyxOE=@achow101.com> In-Reply-To: <20190731211948.1e9e22f2@simplexum.com> References: <20190731211948.1e9e22f2@simplexum.com> 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: Thu, 01 Aug 2019 02:12:34 +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 19:16:42 -0000 Hi, On 7/31/19 12:19 PM, Dmitry Petukhov wrote: >=20 > 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. >=20 > 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) >=20 I don't think that should something that is required for people to do, but perhaps it can be something that is strongly recommended and suggested in the BIP itself. >=20 > 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. >=20 On 7/31/19 10:32 AM, jan matejek via bitcoin-dev wrote:> > > why not use Bitcoin compact uint, which most PSBT consumers already > implement? > There are a few issues with using a compact size uint. The main issue is that it doesn't translate well to the proprietary use types. If we used CSUint for the type, then all of type values for proprietary use need to be reserved instead of allowing them to be infinitely expanded from the initial set of proprietary use types. There is also the fact that CSUints are malleable as the same value can be represented in many different ways, just with different amounts of leading zeroes. But I suppose that isn't really that big of an issue. I am not opposed to using a CSUint, I just felt that it made things a bit harder and was unnecessary. Andrew