Date: Wed, 31 Jul 2019 19:16:36 +0000
To: Dmitry Petukhov <dp@simplexum.com>, bitcoin-dev@lists.linuxfoundation.org
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <766lR1Xtq2ymdINURSNHByDQmkb4hT0VqDx-N8_iq1tmcUMwc96WQtKlCX5Eiq0blk56fur7t2iMZGDmb40qk-pewwJILhDRrrbxnyVyxOE=@achow101.com>
In-Reply-To: <20190731211948.1e9e22f2@simplexum.com>
References: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com>
	<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
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
	Extensibility
Precedence: list

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