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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8186AA74
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 12:43:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B38851AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 12:43:09 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id DA25320CD8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 08:43:08 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
by compute1.internal (MEProxy); Thu, 28 Sep 2017 08:43:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
content-type:date:from:in-reply-to:message-id:mime-version
:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc
:x-sasl-enc; s=fm1; bh=lSBzL+ThpVQ8Y1BTacq7QJRlNp2LTcj6NfdH0YIgj
Hg=; b=Me27u7JN4AjmqyWSuBL8WXShvB01kOBUPr0XtBPwPcoXUOAUnWPjLspjC
TdjufBWwdThur5umeY7g7IWrufDbV9okKAwxeBY2D+CreThsCihWcNoPc7G4koAW
rkxhYjmn12pqCdMLDxLA4OuS0VONLv3J1Kl1+T0agwcgVX9hBOf/fQxWnJ9v6FZv
3ia3Kle4YHBK8zKKc8LWL/Wo5rHtJfJavZxT2Tny2xe0VzFMyv3OnYzP/DwNfTol
jUB7616jQEbR9uZE6WFpxO19vlW3Y3ww6NMiXE+nvGXeG3hxfbfGqV/J+HHzwKZl
ScH0Tn/elzqLWcQ3+Gnd5iK6JBkvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to:x-me-sender
:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=lSBzL+ThpVQ8Y1BTac
q7QJRlNp2LTcj6NfdH0YIgjHg=; b=po5wF6j1S87HBJQamHKniYp0PhdXB2W+Ys
HnHIS5ZMr766CxF0AdPEP1SDaLU7x4XcREGHQ4C979z108WPspR+PYM4866+uxPt
nF+DwznAefR6rbq5n0go4nkshRWRy6WVzHAYCih48dn977FmXUbQ0K2eFmVWJx53
Q7VHmcrzJU1NvLve+dd72XLIeK6UmgZduMU6kNATcs3w3KchQV9x5bzHN6kUp7Zq
VF4bUPdAuP0ggEB2hReefNyLomF/Kh2XFQKjsh36QPXKaDLTX4xseqSr4+sIoY39
DutLuVqIKt7OSvscBfUXv05LrJey7RakPbMqIA6bODbGqm9lZ34A==
X-ME-Sender: <xms:XO7MWWETxG_3mDpDYeeZgm13Y6--hvtceIf67LAje5QP7pveqCxnpQ>
X-Sasl-enc: vH7pgsP9qKzpE944u4KbDu10nMJIW1Fbm8N4zyLjB9FB 1506602588
Received: from [192.168.100.47] (unknown [86.123.50.235])
by mail.messagingengine.com (Postfix) with ESMTPA id 362797FAA0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 08:43:08 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
boundary="Apple-Mail=_35D64A4E-4B59-46D5-80C9-85760FB0258B";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Thu, 28 Sep 2017 15:43:05 +0300
References: <20170927160654.GA12492@savin.petertodd.org>
<oqihpf$5gc$1@blaine.gmane.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <oqihpf$5gc$1@blaine.gmane.org>
Message-Id: <B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,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
X-Mailman-Approved-At: Thu, 28 Sep 2017 12:51:39 +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: Thu, 28 Sep 2017 12:43:10 -0000
--Apple-Mail=_35D64A4E-4B59-46D5-80C9-85760FB0258B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Peter Todd 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;
[...]
>=20
> To help combat this problem, I suggest that we add a UI-level =
expiration time
> 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.
[...]
Perhaps outside the scope of BIP173, but what about baking it into the =
protocol? That way a transaction that's sent too late, simply won't get =
confirmed. This removes the need for refund logic or asking a customer =
to pay just a few extra cents. You could also disallow a second payment.
Two downsides I can think of:
* privacy, as differences in expiration policy would be visible on chain
* miners might be able to game it in their interaction with brokers
> Being just an expiration time, seconds-level resolution is =
unnecessary, and
> 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
So that's 4.8 characters for hours, or 3.2 for years, plus checksum =
space? The shorter the better. Perhaps one or two bits can be used to =
specify an exponent; a large range seems more useful than high =
precision. For instance a merchant doesn't care if the customer pays =
within 10:00:00 minutes or 10:00:01 minutes and you wouldn't care if =
your address is valid 50 years or 50 years and 3 minutes. This point may =
be mute if minute level resolution is not practical.
> 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.
>=20
> Supporting hour-level (or just seconds) precision has the advantage of =
making
> 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.
Greg Maxwell wrote:
> 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.
Is this because 5 bits are one bech32 character (2^5=3D32) or there is =
another reason? And does that include the space needed for the checksum?
Hopefully one day addresses can be abstracted away, because they really =
aren't what people intuitively think they are, but I don't see that =
happen on short notice. Until then they shouldn't exhibit "surprising" =
behavior.
Embedding amounts in an address could confuse people when they reuse it. =
Wallets would e.g. have to ignore the amount value if they previously =
sent money, but without changing the address string displayed in the UI.
> 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.
Many merchant services and exchanges use 10-15 minute expiration though. =
At the wallet level, all sender and recipient need to agree on is their =
relative time. Fallback behavior for a signer with no access to time =
could be to ignore the deadline.
Andreas Schildbach wrote:
>=20
> This feels redundant to me; the payment protocol already has an
> expiration time.
The BIP-70 payment protocol has significant overhead and most =
importantly requires back and forth. Emailing a bitcoin address or =
printing it on an invoice is much easier, so I would expect people to =
keep doing that.
Sjors
--Apple-Mail=_35D64A4E-4B59-46D5-80C9-85760FB0258B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlnM7lkACgkQV/+b28ww
EAka7w/+L5X/4rRhdca8cqd+5UT9bA46NGGu/wVPLkI5m19WrhIL7BCt4x6x5HZ3
cAsOhOvy5UV0ySVwWk5Cb2aeEhcnRwc72RS76lN5jvQCox4uiRrROUnOvUcdJpBB
Yb/QVfo7nc++pqt/uAwTy67zNiFnImBIfuBrmnmVBX69tV99erVUmMOL7jGsNie/
N2+2DM/dNSpeJEfsVnaXl6FUcLrGDN0bCr/onbzwzwrCrZr7IG6vwGoRnqFJ+RSs
KKIYQLgp4fsgzXbKuGCcSOp5SlTeiuzpUyn/TSjejPg1HcG8F1gAZNJ7xaaJboxg
AygLFkGQxaj1FHR3YQCjNN2AbJrZsv9xtW/RQ2Nb3w4RC7KlFAmv+AhyzEk5DVJ/
/F2Tm4Aod23wh3Tj4HG0553OGZSVar8o7ukicAro6MFGN6XhYxcDZWaErGl+sIUE
ZgqGYF686X4ynptSYA8OQtnhhjkRCc/OpU5rMRBvHtblk0NoDwPh8G0WB88TZ3ta
gHw54rJXt9XZKfR/QkCgCERKOlCe1RBn0ZpVuoDFNPzzESQxVm7Kp7R+dQrSDrmz
DyCYAiFdxVGw3lh4BRMYkdVYXJNL6qOdnc8WFG2hhAMo6U0ACvAvT+6QrdstwRug
4TkLrjL+BAIil9w3h71KRhl8uY4/yFPXFJOP8AL0E7XnBtjmIK4=
=lZh2
-----END PGP SIGNATURE-----
--Apple-Mail=_35D64A4E-4B59-46D5-80C9-85760FB0258B--
|
