From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.linuxfoundation.org (smtp2.linux-foundation.org [172.17.192.36]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A0A12C for ; Fri, 29 Sep 2017 01:51:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp2.linuxfoundation.org (Postfix) with ESMTPS id D30061DB0A for ; Fri, 29 Sep 2017 01:51:31 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T1oqSC042586; Fri, 29 Sep 2017 02:50:52 +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 v8T1oo5I054734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2017 02:50:51 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 554A3400FD; Fri, 29 Sep 2017 01:50:49 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 9098A205E4; Thu, 28 Sep 2017 21:50:48 -0400 (EDT) Date: Thu, 28 Sep 2017 21:50:48 -0400 From: Peter Todd To: Gregory Maxwell Message-ID: <20170929015048.GC11956@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="HG+GLK89HZ1zG0kk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 9fa90d56-a4b8-11e7-801f-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAsUC1AEAgsB AmEbW1ZeVV17XGI7 bghPaBtcak9QXgdq T0pMXVMcUg0MAENe A2ceVx11dAEIcX9y YwhrCCFSXBB/c1ss RhxcCGwHMGB9YGAe Bl1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXAShZ WAwWNhofUV4KBDcg RhcEVSkuGEAeDz4z KAEiJhYWEQ4YPkk/ PRM9XhoyEidXU1IF dwAA X-Authentic-SMTP: 61633532353630.1039: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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp2.linux-foundation.org Cc: Bitcoin Protocol Discussion 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 01:51:39 -0000 --HG+GLK89HZ1zG0kk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote: > On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev > wrote: > > Re-use of old addresses is a major problem, not only for privacy, but a= lso > > operationally: services like exchanges frequently have problems with us= ers > > sending funds to addresses whose private keys have been lost or stolen;= there >=20 > When Pieter and I were working on Bech32 we specifically designed for > error correcting codes that had good performance for longer lengths > than we technically needed specifically to incorporate things like > dates and explicit amounts. >=20 > (explicit amounts so that typos and bit flips in amounts displayed or > in memory couldn't result in sending the wrong amount) >=20 > But we also thought that also adding those features at the same time > would retard adoption-- both due to debating over the encodings and > because handling would result in different software requirements and > layering, so you couldn't just drop them in. Notably, even something as simple as adding a new type of confirmation wind= ow that might be needed is a big chance to UI logic. > Doubly unfortunately, people have even deployed BIP173 already (prior > to it even having much peer review or being adopted by its own > authors), so I think a rethink now wouldn't be timely (I mean as a > replacement to BIP173 rather than an additional format). :( Yeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - tha= t's a lot of code that would get touched by this proposal, so it's likely too l= ate in the process. > But I do support the idea. >=20 > 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. What do you mean by "an embedded amount"? > 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. I'm inclined to agree as well. Also, Bitcoin payments themselves are inhere= ntly imprecise, because blocks aren't found on a regular interval - Coinbase's "= 10 minute" payment expiry window is odd from that point of view. Having said that, you'd want a resolution more precise than what you'd expe= ct timeouts to be set at, to avoid UI "fencepost" oddity; if I want to set a 1= day timeout, users shouldn't see either 1 or 2 days depending on exactly which = way it happened to be rounded that particular time.. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --HG+GLK89HZ1zG0kk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZzab0AAoJECSBQD2l8JH760oIAJjxYsHo1bjJijWiJB4XE2lp HrKdBjMQWJH3voNjYtyKtVadCV+0m1PqJGxlHsunUEmVGtjz30jBQozNd0nhpMVd MMhkbx35gO5qqq7IWpts8K0luv7olxLFcNFqcEkZ3hl1ECrgkwxrUf8JteceabdU pjlqPWkTnde4jjeMbASZDVrWTnQLQlHZAKPSnoJduztCbOfa47mf+iR+ihAljXd6 sY7Io+k3KGrd8OiapBlCSTApxHHQD9vHssiLgD7ARRmkLmXlzpEjiCSChqpoQoso iSG9kqVmOz1l2u5+Cs89THwTajs1mgC/eqyV5h/Jc3Y3iITmSgxuHMteoJkME6M= =ZCTH -----END PGP SIGNATURE----- --HG+GLK89HZ1zG0kk--