From: Andrew Chow <achow101-lists@achow101•com>
To: Dmitry Petukhov <dp@simplexum•com>,
bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Date: Wed, 31 Jul 2019 19:16:36 +0000 [thread overview]
Message-ID: <766lR1Xtq2ymdINURSNHByDQmkb4hT0VqDx-N8_iq1tmcUMwc96WQtKlCX5Eiq0blk56fur7t2iMZGDmb40qk-pewwJILhDRrrbxnyVyxOE=@achow101.com> (raw)
In-Reply-To: <20190731211948.1e9e22f2@simplexum.com>
Hi,
On 7/31/19 12:19 PM, Dmitry Petukhov wrote:
>
> 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)
>
I don't think that should something that is required for people to do,
but perhaps it can be something that is strongly recommended and
suggested in the BIP itself.
>
> 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.
>
On 7/31/19 10:32 AM, jan matejek via bitcoin-dev wrote:>
>
> why not use Bitcoin compact uint, which most PSBT consumers already
> implement?
>
There are a few issues with using a compact size uint. The main issue is
that it doesn't translate well to the proprietary use types. If we used
CSUint for the type, then all of type values for proprietary use need to
be reserved instead of allowing them to be infinitely expanded from the
initial set of proprietary use types.
There is also the fact that CSUints are malleable as the same value can
be represented in many different ways, just with different amounts of
leading zeroes. But I suppose that isn't really that big of an issue.
I am not opposed to using a CSUint, I just felt that it made things a
bit harder and was unnecessary.
Andrew
next prev parent reply other threads:[~2019-07-31 19:16 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
2019-07-31 19:16 ` Andrew Chow [this message]
[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='766lR1Xtq2ymdINURSNHByDQmkb4hT0VqDx-N8_iq1tmcUMwc96WQtKlCX5Eiq0blk56fur7t2iMZGDmb40qk-pewwJILhDRrrbxnyVyxOE=@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