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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EC0D6927
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 17:48:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149115.authsmtp.co.uk (outmail149115.authsmtp.co.uk
[62.13.149.115])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5227B47F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 17:48:55 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8RHmskM005722
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 18:48:54 +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 v8RHmqxd026244
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 18:48:53 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 3CD07401C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 17:48:52 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id F215D23E43; Wed, 27 Sep 2017 12:06:54 -0400 (EDT)
Date: Wed, 27 Sep 2017 12:06:54 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170927160654.GA12492@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 20cce234-a3ac-11e7-a0cc-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfZVUtCkV1
UkhIRUJTHA9sCRYE BVAbUAd3aQROfWBx Z0Z9XHVEXQo8fSQF
Hw8cQW0EY2VkbC4c V0dbOQFUI1AffBxB dwF8BSAQYGRSYWcx
RwQ4emhpZGgGd3pe S1hcfUQ7TUoREyUn Dx0SBTQ1FFEEQCN7
Mx0jJ0VUB0YWL0E+ eVEsEVsUPxIeQhFZ V2tsOGoAeAJp
X-Authentic-SMTP: 61633532353630.1038: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=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [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: Wed, 27 Sep 2017 17:48:58 -0000
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Re-use of old addresses is a major problem, not only for privacy, but also
operationally: services like exchanges frequently have problems with users
sending funds to addresses whose private keys have been lost or stolen; the=
re
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposit=
s.
This also makes it difficult operationally to rotate private keys. I person=
ally
have even lost funds in the past due to people sending me BTC to addresses =
that
I gave them long ago for different reasons, rather than asking me for fresh
one.
To help combat this problem, I suggest that we add a UI-level expiration ti=
me
to the new BIP173 address format. Wallets would be expected to consider
addresses as invalid as a destination for funds after the expiration time is
reached.
Unfortunately, this proposal inevitably will raise a lot of UI and terminol=
ogy
questions. Notably, the entire notion of addresses is flawed from a user po=
int
of view: their experience with them should be more like "payment codes", wi=
th a
code being valid for payment for a short period of time; wallets should not=
be
displaying addresses as actually associated with specific funds. I suspect
we'll see users thinking that an expired address risks the funds themselves;
some thought needs to be put into terminology.
Being just an expiration time, seconds-level resolution is unnecessary, and
may give the wrong impression. I'd suggest either:
1) Hour resolution - 2^24 hours =3D 1914 years
2) Month resolution - 2^16 months =3D 5458 years
Both options have the advantage of working well at the UI level regardless =
of
timezone: the former is sufficiently short that UI's can simply display an
"exact" time (though note different leap second interpretations), while the
latter is long enough that rounding off to the nearest day in the local
timezone is fine.
Supporting hour-level (or just seconds) precision has the advantage of maki=
ng
it easy for services like exchanges to use addresses with relatively short
validity periods, to reduce the risks of losses after a hack. Also, using at
least hour-level ensures we don't have any year 2038 problems.
Thoughts?
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZy8ybAAoJECSBQD2l8JH7y9kIAIp4JjzOvx6rWSGgQ69GGPtD
mrPY53XnOICzhqNQ3t0i8v7vp2QN3sLCIUX2auomcoQhup0KxJWH+rPuQ6HIRNdr
mpgo9QC79RYqWmuucCseIdUVRXkfOeX4MwGcgODnNkvMl4fTYJMj8eiqONJrpOBz
NV6XBPnhrQSbs0E6Mkzk1phjyt0TckeH3XEdlvi6wPOOGKLRxFAdQG0T6QBLRlpg
7yRdqRoacybUMiyFnGJE5WJBiiiNO7W84WrB/DQFJfvYRGNHUsMIHR/E5F9fkrdn
NKh3d06lKnIMfDav6HxRvIT7rG/keb7ci2L0HfEMiytSheocFb+oVdT8v8QMRrQ=
=vqyK
-----END PGP SIGNATURE-----
--FCuugMFkClbJLl1L--
|
