From: Dmitry Petukhov <dp@simplexum•com>
To: Andrew Chow <achow101-lists@achow101•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Date: Fri, 2 Aug 2019 14:18:36 +0500 [thread overview]
Message-ID: <20190802141836.15771ad6@simplexum.com> (raw)
In-Reply-To: <YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@achow101.com>
В Thu, 01 Aug 2019 19:01:06 +0000
Andrew Chow <achow101-lists@achow101•com> wrote:
> 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.
I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
would like to note that for those who do not want to deal with
additional complexity of handling a prefixed string, they can simply
not use it at all. Since this is a private construction, and their
private format specifies 'no prefix', they can just ignore everything
that does not start with "{0xFC}|{0x00}", thus any further complexity
regarding the prefix is also ignored. The only added complexity is one
condition check: second_byte_of_the_key != 0
My other argument for conflict-avoidance prefix as a first thing after
0xFC is that the set of future users of PSBT and private types is
most likely much larger than the current set of those who already
implemented proprietary types on their own, and thus the overall benefit
for the whole industry will likely be bigger when 'i do not want
conflict avoidance' decision have to be explicit, by setting the prefix
to 0x00, and the set of possible conflicting types are limited only to
those entities that made this explicit decision.
Regarding the 'squatted' types, it seems to me that this only matters
in the discussed context if they squatted on 0xFC type in particular.
In other cases, they will need to implement changes anyway, to be
compatible with the BIP. Maybe they could consider that one additional
condition check is a small burden, and maybe they can tolerate that,
for the benefit of reducing possibility of interoperability problems
between other future PSBT/private types implementors.
next prev parent reply other threads:[~2019-08-02 9:17 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
2019-08-02 9:18 ` Dmitry Petukhov [this message]
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=20190802141836.15771ad6@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=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