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
165
166
167
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AD38BACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 19:03:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com
[209.85.192.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8154B433
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 19:03:47 +0000 (UTC)
Received: by mail-pf0-f175.google.com with SMTP id b70so7707826pfl.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 27 Sep 2017 12:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:mime-version:date:subject:message-id
:references:in-reply-to:to;
bh=b8nXb0ykvu4Y3ceU2OL1wzsS0CLdc68tIEmu9s9rjfs=;
b=hDgwj18y2PaPIAi0IB5OxcG5TS3weSbya3QYZSymmpRedl/vl1OxzeP6YkUPEYb0W8
RjAqXRpp4gIw3aVT+SpLao0D0P7X/u0OSe+xLWOb4N23AzOlA1k0fU2BDwmRkRW+hvul
v3gkKCPEWXAt/gPrRqmOcIEEAxWnzRGoWbJYS5IGegL4Tek4KErEh6NORPT6bdVet2DQ
Pen61l9P5ybtHKBOvbnhvWqJh5Z21bj3miit+V5ZEI6RmCQmXizpJg/q6WYIx6YefK7N
gGbI3GPlfpxeyL66p+PGG2KPXKdekS2RqLce9QxsSRZ672/qnMN9X1KhoxhIeJKCEeUk
SUKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version:date
:subject:message-id:references:in-reply-to:to;
bh=b8nXb0ykvu4Y3ceU2OL1wzsS0CLdc68tIEmu9s9rjfs=;
b=MpDbyDNi16eglSt+5v0Zw51Pvj0yRDnSxt9210r3Z4NTnltcC0Q4KuKWTGw+kOV8ZM
3wmKdYtK901MxrouQlGytAPXrhqxmvFA2+3gpgoPLSKEfZ+AxrYB+OAD0pa6yJTo5VUA
dvUksndcE6s7rxmRrEQZPyBbURq+fKIDX2smfhLqF0+3HLa3n+6xUHH7QLPh6ZmrYY3c
2O6B2ltDewKKMeE1K5/jFUthQvZlF+HD13Gy0R1KCh0E4iNHzgG/A96omSn0WJuo73F/
EiNxCyhqzrZSaSXGbLKETXphO6+Eccz5U3Sm4mIriTMYixo7ePrTYSWRselAgp/ojeyR
88jA==
X-Gm-Message-State: AHPjjUhvinP5bNSGGi0wO7GjndwLbEQx9ouMMfdHsMFyDnqtzJvqsnL+
o28M5f9HfnBZr8KD7+hjD/53XnWlQZM=
X-Google-Smtp-Source: AOwi7QDadd1n158rXYlZFT7PA5koCJW7id+5mXlyili4H/yhF1DHmEEs2tgoq9oh4eV8qbLdvdwVFw==
X-Received: by 10.101.66.70 with SMTP id d6mr2081478pgq.169.1506539026912;
Wed, 27 Sep 2017 12:03:46 -0700 (PDT)
Received: from ?IPv6:2607:fb90:a455:e202:6514:24be:ff69:ae73?
([2607:fb90:a455:e202:6514:24be:ff69:ae73])
by smtp.gmail.com with ESMTPSA id
d80sm21787507pfj.170.2017.09.27.12.03.44
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 27 Sep 2017 12:03:46 -0700 (PDT)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 27 Sep 2017 12:03:44 -0700
Message-Id: <31968FFC-11BC-4331-B602-70B1F74AEEFC@friedenbach.org>
References: <20170927160654.GA12492@savin.petertodd.org>
In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (15A372)
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 27 Sep 2017 19:06:08 +0000
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: Wed, 27 Sep 2017 19:03:49 -0000
While there is a lot that I would like to comment on, for the moment I will j=
ust mention that you should consider using the 17 bit relative time format u=
sed in CSV as an offset from the birthdate of the address, a field all addre=
sses should also have.
This would also mean that addresses cannot last more than a year without use=
r override, which might actually be a plus, but you could also extend the fi=
eld by a few bits too if that was deemed not acceptable. An address should n=
ot be considered valid longer than anticipated lifetime of the underlying cr=
yptosystem in any case, so every address should have an expiry.
> On Sep 27, 2017, at 9:06 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
> 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; th=
ere
> are multiple examples of exchanges getting hacked, with users continuing t=
o
> lose funds well after the actual hack has occured due to continuing deposi=
ts.
> This also makes it difficult operationally to rotate private keys. I perso=
nally
> 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 fres=
h
> one.
>=20
> To help combat this problem, I suggest that we add a UI-level expiration t=
ime
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time i=
s
> reached.
>=20
> Unfortunately, this proposal inevitably will raise a lot of UI and termino=
logy
> questions. Notably, the entire notion of addresses is flawed from a user p=
oint
> of view: their experience with them should be more like "payment codes", w=
ith a
> code being valid for payment for a short period of time; wallets should no=
t be
> displaying addresses as actually associated with specific funds. I suspect=
> we'll see users thinking that an expired address risks the funds themselve=
s;
> some thought needs to be put into terminology.
>=20
> Being just an expiration time, seconds-level resolution is unnecessary, an=
d
> may give the wrong impression. I'd suggest either:
>=20
> 1) Hour resolution - 2^24 hours =3D 1914 years
> 2) Month resolution - 2^16 months =3D 5458 years
>=20
> 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 th=
e
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>=20
> Supporting hour-level (or just seconds) precision has the advantage of mak=
ing
> 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 a=
t
> least hour-level ensures we don't have any year 2038 problems.
>=20
> Thoughts?
>=20
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
