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
94
95
96
97
98
99
100
|
Return-Path: <achow101-lists@achow101.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D546B410D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 19:16:42 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC5B2A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 19:16:41 +0000 (UTC)
Date: Wed, 31 Jul 2019 19:16:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail; t=1564600599;
bh=kW3SVlk3VMp5vQUD8wEdUB/4t4QMlEwpB8zeP59ItmY=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=hE15W06QG43/aOVA2TQ45N+Zd1NeKrOccUWjMHbXLbHhFsG7Fsn7JazX9kELTMjEW
6Dcx59HLUDE56iEePbgxC9oFqUEyGxCAQfRO8iXErNt7kFU4ZBJjRtSSEhPDWUnNFy
PJolFKb7DYw2rqbWwPzSLzAsBVfJsBr0KH8M6zL8=
To: Dmitry Petukhov <dp@simplexum.com>, bitcoin-dev@lists.linuxfoundation.org
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <766lR1Xtq2ymdINURSNHByDQmkb4hT0VqDx-N8_iq1tmcUMwc96WQtKlCX5Eiq0blk56fur7t2iMZGDmb40qk-pewwJILhDRrrbxnyVyxOE=@achow101.com>
In-Reply-To: <20190731211948.1e9e22f2@simplexum.com>
References: <e04pefskqT_1_6sh3jTF7BwRcTHi7zmc3AZOLDlbGrF2HuE969zw0jN4WvIKUFICNAvcvmdu4t7TErX9syE8bn9Q5OB7o-Va7oZ0nnpNqbg=@achow101.com>
<20190731211948.1e9e22f2@simplexum.com>
Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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: Thu, 01 Aug 2019 02:12:34 +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 19:16:42 -0000
Hi,
On 7/31/19 12:19 PM, Dmitry Petukhov wrote:
>=20
> 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.
>=20
> 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)
>=20
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.
>=20
> 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.
>=20
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
|
