From: Andrew Chow <achow101-lists@achow101•com>
To: bitcoin-dev@lists•linuxfoundation.org,
Dmitry Petukhov <dp@simplexum•com>
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Date: Thu, 01 Aug 2019 19:01:06 +0000 [thread overview]
Message-ID: <YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@achow101.com> (raw)
In-Reply-To: <I3Yq3q73tNvEF-Ubis-0A_OPB84-NdRMLUMmMPnQMEazrWw3Q25yGNHVUt5nMOtdD3ISlJj3efNJaLwQjTsvQI1ToF7stRabWo1SYiZjg9U=@achow101.com>
I spoke to some people OOB and they said that they didn't really like
the idea of having a prefix string (partially because they've already
implemented some proprietary types by simply squatting on unused types).
Matching the prefix string adds additional complexity to the parser
code. The main concern is that people won't want to actually follow the
spec for proprietary types and instead just use some unused type value.
So I think instead we should do:
{0xFC}|{private_type}
and the prefix string can be optional (and strongly recommended) after that.
Since public parsers won't really be enforcing the rules for proprietary
types, I don't think it really makes sense to specify and enforce how
they should be. After all, the key is really just an opaque data blob.
In the same vein, it would probably be useful to allow multiple types
for proprietary use as originally proposed to make implementation of
these easier. If more type are needed, then the private type
construction can be used.
Andrew
On 8/1/19 1:57 PM, Andrew Chow wrote:
>
> 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
>
next prev parent reply other threads:[~2019-08-01 19:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2019-08-02 9:18 ` Dmitry Petukhov
2019-08-04 0:15 ` Jonathan Underwood
2019-07-31 1:13 Andrew Chow
2019-07-31 14:32 ` jan matejek
2019-07-31 16:19 ` Dmitry Petukhov
2019-07-31 19:16 ` Andrew Chow
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='YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@achow101.com' \
--to=achow101-lists@achow101$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dp@simplexum$(echo .)com \
/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