1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
Return-Path: <dp@simplexum.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 861293D56
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 16:18:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1B64832
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 16:18:20 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 41C20260052E;
Wed, 31 Jul 2019 16:18:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1564589899;
bh=t0zShvbzKiaVIMuPyRkHwJYUVUXY7iIcsp1H9TtTZEo=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=DFE/j3jnhHbjrTUn37TxARAeQUx3/83ougbeDMWD9tZ3tLXlmtwIC9rR8xD2R3W7R
ofMCtgOYN5FlJaJFHud9+w1FOIApmbC6WWd6o2rDrgDUKCxZWxLkHgFrdMw/kRqXJy
WQZkjjurZf8xH6hcZDijk+SjrbXkgr/Wqnjf9RYk=
Date: Wed, 31 Jul 2019 21:19:48 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20190731211948.1e9e22f2@simplexum.com>
In-Reply-To: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com>
References: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 31 Jul 2019 18:19:26 +0000
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
Extensibility
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 16:18:21 -0000
=D0=92 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.
>=20
> 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.
|
