From: Andrew Chow <achow101-lists@achow101•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Date: Wed, 31 Jul 2019 01:13:46 +0000 [thread overview]
Message-ID: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com> (raw)
Hi All,
I would like to propose some types that allow for BIP 174 PSBT to be
extended more in the future.
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.
These types will be guaranteed to not be used by the public
specification and there is no expectation that any publicly available
software be able to understand any specific meanings of these types.
These types should be used for internal processes only.
The types I would like to reserve for proprietary use are the 15 types
from 0xF0 to 0xFE inclusive. These 15 type values will be the same for
global, per-input, and per-output types. If 15 types are not enough,
additional types can be obtained using the multi-byte type method
described later.
Next, I would like to propose a global version type and field. The
version type is 0xEF with only the type as the key, and the value is a
32-bit unsigned little endian integer representing the version number. A
PSBT without a version number is to be considered version 0. If a parser
sees a version number that it does not understand, it should exit
immediately as the PSBT will contain types that are not safe to ignore.
This version number is a safeguard in the event that a backwards
incompatible change is introduce to PSBT. While PSBT is designed and
intended to be forwards compatible by allowing parsers to ignore types
that they do not understand, it is possible that at ype is added in the
future which breaks this assumption and it would be unsafe for a type to
be ignored.
Updaters and combiners that need to add a version number to a PSBT
should use the highest version number required. For example, if a
combiner sees two PSBTs for the same transaction, one with version 0,
and the other with version 1, then it should combine them and produce a
PSBT with version 1. If an updater is updating a PSBT and needs to add a
field that is only available in version 1, then it should set the PSBT
version number to 1 unless a version higher than that is already specified.
It is not expected that the version number will ever be used. We try to
make PSBT fields safe to ignore. The version number is only being
included here as a safeguard in the event that breaking compatibilty is
required.
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.
The same mechanism can be used for the proprietary use types, just with
a different value as the designated multi-byte indicator. For example,
one could use 0xFE as the designated type as that is in the proprietary
types range. Of course any type within the proprietary type range could
be used as the indicator, it is up to the users to determine this
themselves.
While other methods of indicating multiple bytes and lengths may be more
space efficient and allow us to have more types represented in a smaller
space, I am choosing this method because of its simplicity. This is easy
to understand and implement. Furthermore, I do not expect that we will
use so many types. I don't think that we will need to have more than one
byte types for a very long time.
Please let me know your thoughts on these extensions. I will open a PR
to the bips repo to add these to BIP 174 if there are no objections.
Andrew Chow
next reply other threads:[~2019-07-31 1:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 1:13 Andrew Chow [this message]
2019-07-31 14:32 ` jan matejek
2019-07-31 16:19 ` Dmitry Petukhov
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='e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com' \
--to=achow101-lists@achow101$(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