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
|
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 78F41BAF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 07:18:11 +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 9622B442
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 07:18:10 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id A0B2421A25;
Fri, 29 Sep 2017 03:18:09 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
by compute1.internal (MEProxy); Fri, 29 Sep 2017 03:18:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
cc: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=0iu/Q2GwYV3anPhGRyoLXYc8bVvi/Jyy0OpUJOVOf
q8=; b=Ehl8b6YYQB9a3KV0NvfHhspA6e9x6Q8I8P2HXATkusCyamKtPWtLBEzmy
6cuOoTo8mcql4sbLn400DY5Qn/FsrFHoKcUPJ3KdkELyV4d9yPrYBJ5gAXw4ZTS4
9Rrn2/4y4XEj3m22NILAiGRjGZ7a4h5nECXu4LkqkEwE/Me93iXBt85m3dZT4Hwz
j4shiKJ4oOg8pOymCVV26viGI+N3obmiPVoqkicix6kguU2j7paY75CP85DJ6OxF
Or3K+UE9fcgSg9mp+5AxhE0SSMvBk6WmPQWMB7EOPDl+RuFlZYEb/PpM/4zHXgE1
gHEUv+9nUs8yZVq4JHpOJuMlbTDWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc: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=0iu/Q2GwYV3anPhGRy
oLXYc8bVvi/Jyy0OpUJOVOfq8=; b=QnwoVDI/G2PDg4GXNxMS12qm/Hr2Gd76ip
SMNzhp+m25KXehpNH2Dm9FKeELU4DMypwP4yRM6rZew+Z6gt5X88u88gws+IzWev
7XItkLM0NiWA8rYvYq3W+ey4M+yynfK/c8hUeFGF9wiWUV438LjRJxEsq7lSOCg1
OC5jTaay2HD1WC/+cCySk/ZyXkPjU6gQvlt8MN9IUToRMDR6mrthY4iE7t5fHOV+
QduVVWyNJtRdCrBGUs4UBMuHYwvnkpg8C6otGBx1BG1sT9QcfRGeGQM/RT8WMfXy
+AQWxQdZTfxZXHavatM2+3D2SPv9usWmosxh+BLg0usitLZuUphg==
X-ME-Sender: <xms:sfPNWZvBoQ45-8J1N7DJVogXC5Rz7cejFwJL8hdIxm3N5HdtZdz2-Q>
X-Sasl-enc: IygXh9lhxNGSG4aQP5Ozm4HVOrC4v7KGHQzJUssSNm7h 1506669489
Received: from [192.168.0.108] (unknown [78.96.80.234])
by mail.messagingengine.com (Postfix) with ESMTPA id AE4257E3BA;
Fri, 29 Sep 2017 03:18:08 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <3CCFB7B0-10FC-4860-86C0-29472B76B129@sprovoost.nl>
Content-Type: multipart/signed;
boundary="Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Fri, 29 Sep 2017 10:18:06 +0300
In-Reply-To: <20170929021846.GB12303@savin.petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <20170927160654.GA12492@savin.petertodd.org>
<oqihpf$5gc$1@blaine.gmane.org>
<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
<20170929021846.GB12303@savin.petertodd.org>
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: Fri, 29 Sep 2017 11:56:10 +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: Fri, 29 Sep 2017 07:18:11 -0000
--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Op 29 sep. 2017, om 05:18 heeft Peter Todd <pete@petertodd.org> het =
volgende geschreven:
>=20
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via =
bitcoin-dev wrote:
>> Peter Todd wrote:
>> 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.
>>=20
>> 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
>=20
> This has been discussed many times before; there are *severe* =
downsides to
> making it possible for transactions to become invalid after the fact.
I've heard of that general principe, but I'm having trouble finding a =
good resource that describes it more precisely.
Is it a peer to peer or mempool issue? E.g a transaction might be =
accepted into the mempool and relayed at one point in time and suddenly =
become invalid before they're committed to a block? Or that a node =
receives a transaction, thinks it's invalid because the address already =
expired, but then receives an older block later which contains that =
transaction?
Once in a block, I don't see how it would become invalid later. But as a =
miner tries to find a block and updates the timestamp, they would have =
toss the transaction out at some point.
Another objection I can think of, is that the soft fork introducing this =
change would have to use a transaction type that's non-standard at the =
moment. This would make it difficult for a non-upgraded node to =
broadcast such a transaction. The recipient would have to know if the =
sender has upgraded before communicating an address, which sounds =
impractical at best.
>>> 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
>>=20
>> 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.
>=20
> Note that "large range" is a requirement driven by the fact that =
expiry times
> will inevitably be specified absolutely, not relatively: when the =
range runs
> out you need to upgrade the standard. Better to use another character =
and use a
> range that won't run out any time soon.
>=20
> This wouldn't create a need for more checksum space.
You're right, relative time makes no sense. So it would take 5 =
characters to get roughly two minute resolution that lasts for 100 =
years.
Sjors
--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983
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/+b28wwEAkFAlnN864ACgkQV/+b28ww
EAlPDhAAtLjb6pVImRmktnBPsPp+TVlb8k7tN+6PS5eyv6H+l890ogQzONLGFQJm
2uYFlfsrKAvya6lUDQQQoW7TWBlDawYJc/Ui3hXhT7aE+UjynlOVkuky3Zy2u/Jg
DYdG5RIZOWRNERxkIeFW2rxjEZA6tBjMyuIFw9UNWVlFCWMs9ss6WOLR4Wg64mg3
REED2qvE2VS38zDBLb/2pgws463fOrNW/cfQ4Cd3cKPc0agLub7S/MgRzZUtn+n5
xfz/20tLEyaKhkFrU5BFQ8m32aCvHyscurn1OPx3t+Z1rQJ5GQAU4EucEoiXQ+F2
FAOw1S5omHK+6ZGWDtVMrALCrKmEBL8wlLKMRlGMKK3DdIx/YVcB2yA79zDdS0V7
3ezCX9lj/sJQ/sb+cY4GmO+3kztekzgX+gDncW9tFViMLstwbR6GIGSodDVbuWjK
mioLSnagwMSbElaDh3TKACoZPYlOuCM1BID4v2JaKjXLXk4tGUP7ahV9n4lshsMI
HVH4WdqmJZJ7uvqaOjaEz0lQSZqt2Q54gugrveUBnlRsqO+1RWYKgUshEfQr6EN5
ajZcyLxZ8oeiLw99e29zELxajX56/51Jzrt/valeffhxGiPmpUqgGi+HQHeLgv+X
/1IQj5G/y/HBrwNQdQ18E2GG2ut9HjjNlu5x4QavuHHgTqJk+6M=
=melJ
-----END PGP SIGNATURE-----
--Apple-Mail=_AC257C04-D50E-43E2-AECA-12FEBAD56983--
|
