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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <pete@petertodd.org>
Received: from smtp2.linuxfoundation.org (smtp2.linux-foundation.org
[172.17.192.36])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A0A12C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 01:51:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk
[62.13.149.55])
by smtp2.linuxfoundation.org (Postfix) with ESMTPS id D30061DB0A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 01:51:31 +0000 (UTC)
Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T1oqSC042586;
Fri, 29 Sep 2017 02:50:52 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T1oo5I054734
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 29 Sep 2017 02:50:51 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 554A3400FD;
Fri, 29 Sep 2017 01:50:49 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 9098A205E4; Thu, 28 Sep 2017 21:50:48 -0400 (EDT)
Date: Thu, 28 Sep 2017 21:50:48 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20170929015048.GC11956@savin.petertodd.org>
References: <20170927160654.GA12492@savin.petertodd.org>
<CAAS2fgRpMXdqKXeYSOtVBQQ9fmu=nQ9anEO6Wrc_5rms1Y2B2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRpMXdqKXeYSOtVBQQ9fmu=nQ9anEO6Wrc_5rms1Y2B2w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 9fa90d56-a4b8-11e7-801f-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUC1AEAgsB AmEbW1ZeVV17XGI7 bghPaBtcak9QXgdq
T0pMXVMcUg0MAENe A2ceVx11dAEIcX9y YwhrCCFSXBB/c1ss
RhxcCGwHMGB9YGAe Bl1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z
GA41ejw8IwAXAShZ WAwWNhofUV4KBDcg RhcEVSkuGEAeDz4z
KAEiJhYWEQ4YPkk/ PRM9XhoyEidXU1IF dwAA
X-Authentic-SMTP: 61633532353630.1039:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp2.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Address expiration times should be added to
BIP-173
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, 29 Sep 2017 01:51:39 -0000
--HG+GLK89HZ1zG0kk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Re-use of old addresses is a major problem, not only for privacy, but a=
lso
> > operationally: services like exchanges frequently have problems with us=
ers
> > sending funds to addresses whose private keys have been lost or stolen;=
there
>=20
> When Pieter and I were working on Bech32 we specifically designed for
> error correcting codes that had good performance for longer lengths
> than we technically needed specifically to incorporate things like
> dates and explicit amounts.
>=20
> (explicit amounts so that typos and bit flips in amounts displayed or
> in memory couldn't result in sending the wrong amount)
>=20
> But we also thought that also adding those features at the same time
> would retard adoption-- both due to debating over the encodings and
> because handling would result in different software requirements and
> layering, so you couldn't just drop them in.
Notably, even something as simple as adding a new type of confirmation wind=
ow
that might be needed is a big chance to UI logic.
> Doubly unfortunately, people have even deployed BIP173 already (prior
> to it even having much peer review or being adopted by its own
> authors), so I think a rethink now wouldn't be timely (I mean as a
> replacement to BIP173 rather than an additional format). :(
Yeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - tha=
t's
a lot of code that would get touched by this proposal, so it's likely too l=
ate
in the process.
> But I do support the idea.
>=20
> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits. Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.
What do you mean by "an embedded amount"?
> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice. I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.
I'm inclined to agree as well. Also, Bitcoin payments themselves are inhere=
ntly
imprecise, because blocks aren't found on a regular interval - Coinbase's "=
10
minute" payment expiry window is odd from that point of view.
Having said that, you'd want a resolution more precise than what you'd expe=
ct
timeouts to be set at, to avoid UI "fencepost" oddity; if I want to set a 1=
day
timeout, users shouldn't see either 1 or 2 days depending on exactly which =
way
it happened to be rounded that particular time..
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--HG+GLK89HZ1zG0kk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZzab0AAoJECSBQD2l8JH760oIAJjxYsHo1bjJijWiJB4XE2lp
HrKdBjMQWJH3voNjYtyKtVadCV+0m1PqJGxlHsunUEmVGtjz30jBQozNd0nhpMVd
MMhkbx35gO5qqq7IWpts8K0luv7olxLFcNFqcEkZ3hl1ECrgkwxrUf8JteceabdU
pjlqPWkTnde4jjeMbASZDVrWTnQLQlHZAKPSnoJduztCbOfa47mf+iR+ihAljXd6
sY7Io+k3KGrd8OiapBlCSTApxHHQD9vHssiLgD7ARRmkLmXlzpEjiCSChqpoQoso
iSG9kqVmOz1l2u5+Cs89THwTajs1mgC/eqyV5h/Jc3Y3iITmSgxuHMteoJkME6M=
=ZCTH
-----END PGP SIGNATURE-----
--HG+GLK89HZ1zG0kk--
|
