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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
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 AD628C94
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jul 2018 19:00:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-1857040132.protonmail.ch (mail-1857040132.protonmail.ch
[185.70.40.132])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 54B60E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jul 2018 19:00:01 +0000 (UTC)
Date: Fri, 06 Jul 2018 14:59:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
s=protonmail; t=1530903597;
bh=sokThW+qH7O0GSpN56m4KXcOugEF+IBluOAqjqZcp68=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=mIfQ7qpRmLffEZTM3a38oOPAeB+YpSGAzVPzUr/kySKxzT2ixX/EUm1ID95z5xCQ+
RVH2Gi5AWW91LAi9WZt/rWa7yChYwP9MPtBUI7FUIIA+cfVQ2bOJ7TR3AU/Xx123In
bREaIpmNwJWi4HhKnJVWO/AvemdIfyMRX686SzbU=
To: William Casarin <jb55@jb55.com>
From: Achow101 <achow101-lists@achow101.com>
Reply-To: Achow101 <achow101-lists@achow101.com>
Message-ID: <rLAEe3CQTgqUy2RbJ3hiSotoHbIRt3fKZ4sKYmVbVoh29MTvd0yLGy7bySq1KbMOpgxvixFpwU8evLc1XxK7itMEM_KyxLeYPxGQJE64LE8=@achow101.com>
In-Reply-To: <87in5ttrpb.fsf@jb55.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
<f8f5b1e3-692a-fc1e-2ad3-c4ad4464957f@satoshilabs.com>
<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
<J0KV-aP96fSVHPkPw85N2qdKV_F5vqXt5fIFwKDp9wBjRKJ6bZpUEtzbgHyxlWW9PCXMOEVZnyUnJ-kW281ZbblbCp2sbZI_UyTP46q-PiY=@achow101.com>
<87k1qk7oca.fsf@jb55.com> <87in5ttrpb.fsf@jb55.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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
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, 06 Jul 2018 19:00:02 -0000
Hi,
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On July 5, 2018 12:20 PM, William Casarin <jb55@jb55.com> wrote:
> =E2=80=8B=E2=80=8B
>=20
> I have another concern with the format. (my original bip comment for some=
context: [1])
>=20
> It looks like the one of the reasons I was confused is because you can
>=20
> only parse the format properly by first deserializing the transaction.
>=20
> Since there is no "length" field for the key-value map arrays, you must
>=20
> count the number of transaction input/outputs, and use that as the
>=20
> number of kv maps to parse.
I don't think this is really a problem.
Almost all roles have to deserialize the unsigned tx anyways before they ca=
n do anything.
The only role that doesn't is a simple combiner (a combiner that does sanit=
y checks would
still have to deserialize the unsigned tx), and even then it doesn't matter=
. It just shoves
key value pairs together and doesn't need to know whether the map is for an=
input or for
an output.
>=20
> This is pretty brittle, because now if a Combiner writes the wrong
>=20
> number of key-value maps that don't align with the number of inputs and
>=20
> outputs in the transaction, then the psbt will not be able to be
>=20
> deserialized properly, but is still a valid PSBT. It can't even detect
>=20
> these situations, because the input and output types share the same enum
>=20
> values.=20
If a combiner writes the wrong number of key-value maps, then it would simp=
ly be invalid
to the next person that receives the PSBT. It would not deserialize properl=
y because the
key value pairs would have incorrect values for their types. Not deserializ=
ing properly means
that the PSBT is simply invalid. The same numerical types might
be shared, but their meanings are different between the input and output ty=
pes.
I don't see anywhere that says the number of key value maps MUST
>=20
> match the number of inputs/outputs, perhaps it's implied?
I have added that to the BIP.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On July 5, 2018 10:23 AM, Jason Les <jasonles@gmail.com> wrote:
> Has there been any thought to standardizing file names used when creating=
.psbt files? Maybe something that gives some reliability of being collisio=
n resistant and descriptive. For example:
>=20
> [8 char trim of hash of unsigned tx]+[Role that created file (Ex: Signer)=
]+[4 char trim of hash of data unique to that role (Ex: partial sig)]
>=20
> It may be useful to especially the combiner to have some idea of what fil=
es they have.
>=20
> -Jason Les
I haven't considered this, but I'm not sure if it is really useful. I don't=
think it is really necessary
for any role to know who created the PSBT. If it did, this information woul=
d generally come
out-of-band anyways as someone has to give the PSBT to that person.
Andrew
|
