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 8FBFA910 for ; Fri, 29 Sep 2017 02:18:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6E7FD3 for ; Fri, 29 Sep 2017 02:18:51 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T2Inn2051432; Fri, 29 Sep 2017 03:18:49 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T2Imde020066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2017 03:18:49 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 43712400FD; Fri, 29 Sep 2017 02:18:47 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 7A3BE205E4; Thu, 28 Sep 2017 22:18:46 -0400 (EDT) Date: Thu, 28 Sep 2017 22:18:46 -0400 From: Peter Todd To: Sjors Provoost , Bitcoin Protocol Discussion Message-ID: <20170929021846.GB12303@savin.petertodd.org> References: <20170927160654.GA12492@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 87907fa9-a4bc-11e7-a0cc-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAsUC1AEAgsB AmEbW1deUVV7XWo7 bghPaBtcak9QXgdq T0pMXVMcUg0MA2Vc UkseUBlycQMIf39z ZwhqWXlbWxIrfFss RhwHCGwHMGB9OWBM A11YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z GA41ejw8IwAXAShZ WAwWNhofUV4KBDcg RhcEVSkuGEAeDz4z KAEiJhYWEQ4YPkk/ PRM9XhoyEidXU1IF dwAA X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-0.7 required=5.0 tests=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 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: Fri, 29 Sep 2017 02:18:52 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wr= ote: > Peter Todd wrote: > Perhaps outside the scope of BIP173, but what about baking it into the pr= otocol? That way a transaction that's sent too late, simply won't get confi= rmed. This removes the need for refund logic or asking a customer to pay ju= st 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 This has been discussed many times before; there are *severe* downsides to making it possible for transactions to become invalid after the fact. > > 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 instanc= e a merchant doesn't care if the customer pays within 10:00:00 minutes or 1= 0: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 i= s not practical. Note that "large range" is a requirement driven by the fact that expiry tim= es will inevitably be specified absolutely, not relatively: when the range runs out you need to upgrade the standard. Better to use another character and u= se a range that won't run out any time soon. This wouldn't create a need for more checksum space. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZza2CAAoJECSBQD2l8JH75kUIALvQHss2EXm9I7sHNJC/viZ+ 1W8UlAyvuQLAg2ZJdK3bk0+7LT8uGDysqe6QeThexIyBMxjGjGl8zerdbxKiLwym OEQgWueU1/lVqMuKweUwW3NpuLZvlwtnttGW8lYVIs5wrCelADKHFgDKTQBdvenq W7sSsYlNB87IRoCqi5edGq+TT7xqx0U5AshK5Fg6KWVmfiVRUbGrVQVwW2gKMOI7 2v4td49JWlupyJ28d3GN/+ZzVz/PDN/WXqR3x/7Pg4URyLYYXmb9Vcp1V9mwLWGH 1HSIM/OFEiHOXhUDQWT8jNjuGWX9j/6yPESGQ8mi+olgy/u/UdSwDxaB4BMgWzs= =1bzB -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM--