Date: Thu, 01 Aug 2019 17:57:26 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <I3Yq3q73tNvEF-Ubis-0A_OPB84-NdRMLUMmMPnQMEazrWw3Q25yGNHVUt5nMOtdD3ISlJj3efNJaLwQjTsvQI1ToF7stRabWo1SYiZjg9U=@achow101.com>
In-Reply-To: <CACL8y1tOn_U2YjpzGuRebv=2=tvaEYwR2yMCK_4girJ4WtZ1Ug@mail.gmail.com>
References: <mailman.437.1564598007.27056.bitcoin-dev@lists.linuxfoundation.org>
	<CACL8y1tOn_U2YjpzGuRebv=2=tvaEYwR2yMCK_4girJ4WtZ1Ug@mail.gmail.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

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.

For the proprietary types, I will use Dimitry's and Andrew Poelstra's
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.=
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.

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.

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.


Andrew Chow