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 AD38BACB for ; Wed, 27 Sep 2017 19:03:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8154B433 for ; Wed, 27 Sep 2017 19:03:47 +0000 (UTC) Received: by mail-pf0-f175.google.com with SMTP id b70so7707826pfl.8 for ; Wed, 27 Sep 2017 12:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=b8nXb0ykvu4Y3ceU2OL1wzsS0CLdc68tIEmu9s9rjfs=; b=hDgwj18y2PaPIAi0IB5OxcG5TS3weSbya3QYZSymmpRedl/vl1OxzeP6YkUPEYb0W8 RjAqXRpp4gIw3aVT+SpLao0D0P7X/u0OSe+xLWOb4N23AzOlA1k0fU2BDwmRkRW+hvul v3gkKCPEWXAt/gPrRqmOcIEEAxWnzRGoWbJYS5IGegL4Tek4KErEh6NORPT6bdVet2DQ Pen61l9P5ybtHKBOvbnhvWqJh5Z21bj3miit+V5ZEI6RmCQmXizpJg/q6WYIx6YefK7N gGbI3GPlfpxeyL66p+PGG2KPXKdekS2RqLce9QxsSRZ672/qnMN9X1KhoxhIeJKCEeUk SUKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=b8nXb0ykvu4Y3ceU2OL1wzsS0CLdc68tIEmu9s9rjfs=; b=MpDbyDNi16eglSt+5v0Zw51Pvj0yRDnSxt9210r3Z4NTnltcC0Q4KuKWTGw+kOV8ZM 3wmKdYtK901MxrouQlGytAPXrhqxmvFA2+3gpgoPLSKEfZ+AxrYB+OAD0pa6yJTo5VUA dvUksndcE6s7rxmRrEQZPyBbURq+fKIDX2smfhLqF0+3HLa3n+6xUHH7QLPh6ZmrYY3c 2O6B2ltDewKKMeE1K5/jFUthQvZlF+HD13Gy0R1KCh0E4iNHzgG/A96omSn0WJuo73F/ EiNxCyhqzrZSaSXGbLKETXphO6+Eccz5U3Sm4mIriTMYixo7ePrTYSWRselAgp/ojeyR 88jA== X-Gm-Message-State: AHPjjUhvinP5bNSGGi0wO7GjndwLbEQx9ouMMfdHsMFyDnqtzJvqsnL+ o28M5f9HfnBZr8KD7+hjD/53XnWlQZM= X-Google-Smtp-Source: AOwi7QDadd1n158rXYlZFT7PA5koCJW7id+5mXlyili4H/yhF1DHmEEs2tgoq9oh4eV8qbLdvdwVFw== X-Received: by 10.101.66.70 with SMTP id d6mr2081478pgq.169.1506539026912; Wed, 27 Sep 2017 12:03:46 -0700 (PDT) Received: from ?IPv6:2607:fb90:a455:e202:6514:24be:ff69:ae73? ([2607:fb90:a455:e202:6514:24be:ff69:ae73]) by smtp.gmail.com with ESMTPSA id d80sm21787507pfj.170.2017.09.27.12.03.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 12:03:46 -0700 (PDT) From: Mark Friedenbach Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Wed, 27 Sep 2017 12:03:44 -0700 Message-Id: <31968FFC-11BC-4331-B602-70B1F74AEEFC@friedenbach.org> References: <20170927160654.GA12492@savin.petertodd.org> In-Reply-To: <20170927160654.GA12492@savin.petertodd.org> To: Peter Todd , Bitcoin Protocol Discussion X-Mailer: iPhone Mail (15A372) X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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: Wed, 27 Sep 2017 19:06:08 +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: Wed, 27 Sep 2017 19:03:49 -0000 While there is a lot that I would like to comment on, for the moment I will j= ust mention that you should consider using the 17 bit relative time format u= sed in CSV as an offset from the birthdate of the address, a field all addre= sses should also have. This would also mean that addresses cannot last more than a year without use= r override, which might actually be a plus, but you could also extend the fi= eld by a few bits too if that was deemed not acceptable. An address should n= ot be considered valid longer than anticipated lifetime of the underlying cr= yptosystem in any case, so every address should have an expiry. > On Sep 27, 2017, at 9:06 AM, Peter Todd via bitcoin-dev 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; th= ere > are multiple examples of exchanges getting hacked, with users continuing t= o > lose funds well after the actual hack has occured due to continuing deposi= ts. > This also makes it difficult operationally to rotate private keys. I perso= nally > have even lost funds in the past due to people sending me BTC to addresses= that > I gave them long ago for different reasons, rather than asking me for fres= h > one. >=20 > To help combat this problem, I suggest that we add a UI-level expiration t= ime > to the new BIP173 address format. Wallets would be expected to consider > addresses as invalid as a destination for funds after the expiration time i= s > reached. >=20 > Unfortunately, this proposal inevitably will raise a lot of UI and termino= logy > questions. Notably, the entire notion of addresses is flawed from a user p= oint > of view: their experience with them should be more like "payment codes", w= ith a > code being valid for payment for a short period of time; wallets should no= t be > displaying addresses as actually associated with specific funds. I suspect= > we'll see users thinking that an expired address risks the funds themselve= s; > some thought needs to be put into terminology. >=20 > Being just an expiration time, seconds-level resolution is unnecessary, an= d > 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 > 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 th= e > 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 mak= ing > 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 a= t > least hour-level ensures we don't have any year 2038 problems. >=20 > Thoughts? >=20 > --=20 > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev