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
|
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 D5A4B1014
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Aug 2019 09:17:30 +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 4DC1AE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Aug 2019 09:17:30 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 570E22600524;
Fri, 2 Aug 2019 09:17:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1564737448;
bh=XLhBjcHV2BbpvMoBgpNZbgbspHGczzPwsG9ZggpNCaw=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=kgaRSTxT3aojGxMO3UI7hTIB/YFJ8qPooBqMCtQbuMLz42Xe1Cd3EdtaTIH4UK0kD
F89SqWRqsjpNrQtHMeUoUevFv75WVcLv0qsls1yDOvSsI3w4voSu7bCM8iIy2TOVyX
Mgikz44+ZXEWVGhjcsB5aEQ6859vXaDr/FLa8Y0g=
Date: Fri, 2 Aug 2019 14:18:36 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <20190802141836.15771ad6@simplexum.com>
In-Reply-To: <YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@achow101.com>
References: <mailman.437.1564598007.27056.bitcoin-dev@lists.linuxfoundation.org>
<CACL8y1tOn_U2YjpzGuRebv=2=tvaEYwR2yMCK_4girJ4WtZ1Ug@mail.gmail.com>
<I3Yq3q73tNvEF-Ubis-0A_OPB84-NdRMLUMmMPnQMEazrWw3Q25yGNHVUt5nMOtdD3ISlJj3efNJaLwQjTsvQI1ToF7stRabWo1SYiZjg9U=@achow101.com>
<YgIGlecoK1dbkfdP7mhW_qtJfGfamClPl_0ALhGovnXTPfcQlQDqAiMgeUvSIUVfzblz8oh4zix90pxIj0j3ppvQxDOpCJztJ62vvXn1yO4=@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: Fri, 02 Aug 2019 11:32:47 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
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: Fri, 02 Aug 2019 09:17:30 -0000
=D0=92 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 !=3D 0=20
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.
|
