From: Dmitry Petukhov <dp@simplexum•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Date: Wed, 31 Jul 2019 21:19:48 +0500 [thread overview]
Message-ID: <20190731211948.1e9e22f2@simplexum.com> (raw)
In-Reply-To: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com>
В Wed, 31 Jul 2019 01:13:46 +0000
Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
wrote:
> Firstly, I would like to propose that some types be reserved for
> proprietary use. These proprietary use types are, in general, for
> private use by individuals and organizations who want to use PSBT in
> their processes. These are usefule when there are additional data that
> they need attached to a PSBT but such data are not useful (or
> available) for the general public.
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.
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)
> Lastly, I would like to propose the canonical method for mult-byte
> types. We designate a specific type to indicate that the type is
> multiple bytes. When such types are observed, parsers should move onto
> the next byte and interpret that as the type, keeping in mind the
> number of bytes that were read in for the type.
>
> I propose that we use 0xFF as this designated type. When a parser sees
> an 0xFF value as the type, it reads the next byte as being part of the
> type. So two byte types will be of the form 0xFFXX. This method allows
> us to do a prefix match in order to quickly identify the type being
> used. For types with more bytes, simply use another 0xFF byte. So
> three byte types would be of the form 0xFFFFXX, four byte,
> 0xFFFFFFXX, and so on. When multi-byte types are specified in the
> BIP, they should be specified in this full length form, i.e. two byte
> types as 0xFFXX.
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.
next prev parent reply other threads:[~2019-07-31 16:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 1:13 Andrew Chow
2019-07-31 14:32 ` jan matejek
2019-07-31 16:19 ` Dmitry Petukhov [this message]
2019-07-31 19:16 ` Andrew Chow
[not found] <mailman.437.1564598007.27056.bitcoin-dev@lists.linuxfoundation.org>
2019-08-01 13:50 ` Stepan Snigirev
2019-08-01 17:57 ` Andrew Chow
2019-08-01 19:01 ` Andrew Chow
2019-08-02 9:18 ` Dmitry Petukhov
2019-08-04 0:15 ` Jonathan Underwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190731211948.1e9e22f2@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox