summaryrefslogtreecommitdiff
path: root/3c/1634d66444088d558b87e88345115007df1457
blob: 67c7ba79b27008efb3e3714316b0ac3fe1ebb48f (plain)
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
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 D0D73891
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 23 Jun 2018 20:33:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20D115E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 23 Jun 2018 20:33:19 +0000 (UTC)
Date: Sat, 23 Jun 2018 16:33:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
	s=protonmail; t=1529785996;
	bh=YpRuZn+csVIsKyXehh+llGp29a+FUDUxwxZMSRdh5T4=;
	h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
	From;
	b=AETTAEzpv/l8DaeBwQFWotzj8QFAKQGMKL5U7Ln+5CeOqWtybBXhF4dOpPQF3UM36
	kfNjZDomTdir0Pqoncbg+sc6hczdcJEUwNxGtUBFh/pheloAUKV4LK+6BctGCheAjh
	rH1S7RbIPUErZ1YniProVUdMFS/2TS/awyIj9+Eg=
To: William Casarin <jb55@jb55.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Peter Gray <peter@coinkite.com>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <qqrkCNKaf2L_MWkEU5F2u3Jna2QdA-bGNPDE9aU64Im0SUlIo4mfexfp8CXQSj9vEp9XM25DHSJIp4HnKFyLsflAhreppaNJQy-g1hXtjNU=@achow101.com>
In-Reply-To: <87zhzlbfq5.fsf@jb55.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<CHCiA27GTRiVfkF1DoHdroJL1rQS77ocB42nWxIIhqi_fY3VbB3jsMQveRJOtsJiA4RaCAVe3VZmLZsXVYS3A5wVLNP2OgKQiHE0T27P2qc=@achow101.com>
	<21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com>
	<20180621195654.GC99379@coinkite.com>
	<CAPg+sBgdQqZ8sRSn=dd9EkavYJA6GBiCu6-v5k9ca-9WLPp72Q@mail.gmail.com>
	<ljk5Z_a3KK6DHfmPJxI8o9W2CkwszkUG34h0i1MTGU4ss8r3BTQ3GnTtDTfWF6J7ZqcSAmejzrr11muWqYN-_wnWw_0NFn5_lggNnjI0_Rc=@achow101.com>
	<87zhzlbfq5.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
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: Sat, 23 Jun 2018 20:33:20 -0000



On 06/23/2018 10:00 AM, William Casarin wrote:
> Since we're still considering the encoding, I wonder if it would be a
> good idea to have a human-readible part like lightning invoices[1]?
I don't think that is necessary.
> Then perhaps you could drop the magic code as well?
The magic is still necessary for the binary format in order to prevent
normal transaction deserializers from accidentally deserializing a psbt.
> Also we could do a base encoding that excludes + and / characters, such
> as base62 (gmp-style). It's easier to copy/paste (double clicking a
> string stops at / or + in base64 encodings).
While that would be ideal, I think it is better to use an encoding that
most wallets already support. Most wallets already have Base64 decoding
available so that they can decode signed messages which also use Base64
encoding. I think it is unnecessary to introduce another encoding.


On 06/23/2018 11:27 AM, Peter D. Gray wrote:
> Personally, I don't think you should spec an encoding. It should be binar=
y only and hex for developers and JSON interfaces. My thinking is that PSBT=
's are not user-visible things. They have a short lifetime and are nothing =
something that is "stored" or referenced much later. Hex is good enough and=
 has no downsides as an excoding except for density.
I think what will end up happening though is that, at least in the
beginning, PSBTs will primarily be strings that people end up copy and
pasting. Since a PSBT can get pretty large, the strings are rather
cumbersome to move around, especially as hex. At least with Base64 the
strings will be smaller.
> On the other hand, suggesting a filename extension (probably .PSBT?) and =
a mime-type to match, are helpful since wallets and such will want to regis=
ter with their operating systems to become handlers of those mimetypes. Rea=
lly that's a lot more important for interoperability at this point, than an=
 encoding.
Agreed. I will include those in the BIP.
> Looking forward to test vectors, and I might have more to say once my cod=
e can handle them (again).
>
> Feedback on the BIP as it stands now:=20
>
> - Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_=
SIG =3D=3D 0x02) for the numeric key values. This helps implementers as we =
don't all define our own symbols and/or use numeric constants in our code.
Okay.
> - Those tables are just not working. Might want to reformat as descriptiv=
e lists, point form, or generally anything else... sorry.
I will try my best to fix that. Mediawiki sucks...

Andrew