From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8186AA74 for ; 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 ; 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 ; 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: 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 ; Thu, 28 Sep 2017 08:43:08 -0400 (EDT) From: Sjors Provoost 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> To: Bitcoin Protocol Discussion In-Reply-To: Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--