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
|
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 64F12B35
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 14:41:47 +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 BD0FB472
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2017 14:41:46 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id A36CB20A92;
Thu, 28 Sep 2017 10:41:45 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
by compute1.internal (MEProxy); Thu, 28 Sep 2017 10:41:45 -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=T8WsiVkilurV9HhnDHRHJLA2ChDAxAkQU8bNhnE6B
BI=; b=CsZwZTCA4XnTJ8MdUMTpLI3VUii88iSwLwluR52PvLZGlCh3epn0UcBPO
+Xnx0BG/NhJHQltQb9Z4I4McDnGS8qIHld1MEdZg+ARWgNIKijPzLi2eSrzBunWo
Ru2dVLS6FtuhS+WGHbDnbcQbkGkqwD/z6kAWCpoP2PNZb9BSpiZ2Na/yU/QwWuOp
3dXP9Avp0u1u6UjWJgWUDj291AotOiLutki/bP83/nXleKMsk8ymhU+663k6KcZI
ZPA91lK6T+TmXqRVh3IiYznrXRnQhhhNJDpl5ISDwQv7rE8DG6feZOztBJnoOKQg
LyG4IWWtAUyTHCoz15QgvbZMN8iWA==
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=T8WsiVkilurV9HhnDH
RHJLA2ChDAxAkQU8bNhnE6BBI=; b=WkiF9Yvn/ipcjnVXFCYB60bnr6Ty6qvSJs
ZLjzF+pTDP1tWK0fsliYKANSucl/kOSvTNh89UI453Af8A1plOq4BOBEKTV0M9eq
x2dnwX39w0tRdxNFot6Hs9+AmzCkmsmPrS/WQZnLfFUYdHvbB0e+yPvLs7ND6XBu
SdL5NvwKm8KIovaj+8dY2FsYm7vONZFI7Ak8kMJkqgPvw9WNnvt1TlY6kfaRFHQx
v9Enl1+YyOa769WYUTB8itriYanKHKbc5X//pYA8qLcTEFWwOlBvM25wmQhItt/y
5BGzSzMtYeauRcx47NQv9HLFshJp8X5xQNI6J03tTUOq2H/IK3aQ==
X-ME-Sender: <xms:KQrNWZI9dekWSEktqJ08ydFxOvthr-wEd1kqoSzdTn3NXMHRy9XcKg>
X-Sasl-enc: OD0rF08EZRJMQvOPkHt3cGGsJOq+s4TsPx/f0mKGRvDa 1506609705
Received: from [192.168.0.108] (unknown [78.96.80.234])
by mail.messagingengine.com (Postfix) with ESMTPA id D14BB7E3BA;
Thu, 28 Sep 2017 10:41:44 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
boundary="Apple-Mail=_FD38172E-AFA4-4F52-B218-F71CC044F8A3";
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 17:41:42 +0300
References: <20170927160654.GA12492@savin.petertodd.org>
<oqihpf$5gc$1@blaine.gmane.org>
<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
<oqj02k$fj9$1@blaine.gmane.org>
To: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <oqj02k$fj9$1@blaine.gmane.org>
Message-Id: <14496C9C-E291-4415-B07E-859853579D20@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB 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 14:44:28 +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 14:41:47 -0000
--Apple-Mail=_FD38172E-AFA4-4F52-B218-F71CC044F8A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Op 28 sep. 2017, om 17:13 heeft Andreas Schildbach via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote:
>=20
>>> This feels redundant to me; the payment protocol already has an
>>> expiration time.
>>=20
>> 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.
>=20
> The payment request message is just as one-way as an address is. It is
> already being emailed and printed on an invoice, in fact it often acts
> as the invoice.
True and the more complicated fields, like a digital signature, are =
optional. Are you suggesting BIP-70 payment requests should be rendered =
with bech32? How long would those be if it's just the address and =
expiration date?
>=20
> Even more problematic, if you were to include an expiry date in a
> BIP-173 address and put that into a payment request, wallets wouldn't =
be
> allowed to parse that expiry date from the script without violating =
the
> BIP70 spec.
Do tools that generate BIP-70 payment requests generate addresses =
themselves or are those input manually by a user? In the former case, I =
assume it could avoid setting the optional expiration date?
Is it not allowed to scan the date even if it then sets the expires =
field to the same (redundant) value?
Sjors
--Apple-Mail=_FD38172E-AFA4-4F52-B218-F71CC044F8A3
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/+b28wwEAkFAlnNCiYACgkQV/+b28ww
EAnVdw/+LFE9VgxFdS5zTgnObAKMisdIsfggmaTzDAP0fjfEU6cBs64gR/SNn2HB
AZKBCbiTWqXsm5Pb9YbwPh9UHPdhqHrp1ydUAQ9W6OC+Dq93iVoqQ6MElDGdTONR
4ME3PdOsxZhfqe+qGEydYCkonuDymhZOE4Jc4E6UuM7yft++zK7UIcN3m6sVYhzU
VjxL4L/1KutoGEHLeBeQuJ7Rbe82wfLySJhdCrwJmYm4KxFxPc8hdH5M4P1CJVp7
+aBTtFAYlVITjKNnHQccQiEvk7pgcUmVS/AguAlhPKV/F4iBh5KLw2jVFW4a66Ep
RoIVV0RehMnMGJGEogzRrK3ijXchiNnP5LncGXx3B5b2VrwZeLDN+u4NWvq1iqik
oN5N3jflyAiRxbm7m1t7/Fcq+jfreBVW3+y+0o79o4H+npy45OBsV+LiqKibnjMx
Ve1Zv2SwxH20zMOM8IZ0ymAWmS4NeQImHut20mgmHf/oeV5n+fy09y2JXCbCvcCJ
PPiIPDg9UOhRhTPrwrpg84uHapukrfaRcZPjgN+XPtQgRdPmJyfonLT92HJN3eYS
9l/gc8/8AwJWoPisCI7kSAWUtomfq9WXoK4sR2f9QTTAkiyp4OpfMs0ZsxCOP08m
kTMY+WLDmtjkj9T9UuxW2Fgtrjr82bWiJB8n7oMQIKMSAXsy3tk=
=BXFq
-----END PGP SIGNATURE-----
--Apple-Mail=_FD38172E-AFA4-4F52-B218-F71CC044F8A3--
|
