path: root/cc/938a10b1316793f7275e5bd78cb3d098da8ec5

Return-Path: <nbvfour@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BA0472C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Sep 2017 19:35:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com
	[209.85.223.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F005217E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Sep 2017 19:35:34 +0000 (UTC)
Received: by mail-io0-f178.google.com with SMTP id k101so16643488iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Sep 2017 12:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to; bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=;
	b=TbvkmpoYNG1ot+NEKB15/Knqp+MKzvv1e+0A+qV6AH24An/vsYo2lhzXddAyXlTx9P
	HW2yuE2ZJKrdVxbD3kElEsE0KTWXXLV45f4cQv/vVvBooURgYPlVekV1PRqSCKdhcbRh
	uIvUcDXsYoDLIRPwDLxgJ72Rv6BhlHlBN1PJGaM8SA/xo+oTRJUbCI5XOICDBATcwI3I
	OuR0oo3EAikRd9e9ab2MYilGZgUlqj4bhj+2pRVQbG+2UGgXVcIfyLRr/CQj0kCOBT7u
	yIsPihFlli4h2j4IYLRJDZVXe3vL0ZS0Is7bu5aT93xqV5FA1yZ2ZFP1mHTfpEZcTJci
	+aLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to;
	bh=+IFSPu9TsaZxkQNzErLg5afC72Q3UPCv5nOYuUQl35s=;
	b=dSDDor+lr6HH63XN5hSP3PxGllnXV/QlJdd3Il0BmOIEeaPBbX8B6iemYn8bhiOeK+
	e5UBffxzPgL5Ck87SdX5NxMSekukGyD2U3hKy05cYgJg3fog9q/IjAT7lJrX6/wyoCJV
	LSZ272D3jmR4BSbpGU8dfV2U8OxYqi75JCiQF0Zjms5OBiHvJqX1IMXLGlp2y9DbhJiv
	6AbgPqxiuohh3Z2oqOIr3rBNgvWhFuWHHYQHImw974kmjlUU+/GjGuqFxIqRyuSGfbdd
	trU2+53OxxEuNeYbopIVxtNGtawy8s7wdCa62fzZsWkBq8Cak8V6ih/jY+xoRkh1hrf7
	mbxg==
X-Gm-Message-State: AMCzsaUl61nyxUy40H3HFjdFW40cTt6GngWVf0uSZC5PaALxa0MNzNuD
	6jR2it4ObaqIhad7jAEszfZpiyMFmG11W/U0+VI=
X-Google-Smtp-Source: AOwi7QBzh4k2ywN/lGl4YP9uZ2UlUjWEiLs3ZyNjLHdvg7ggjug5sGIZ/NCUgiGt1rQS5QAALB7k5qWDIdte0YsRgZs=
X-Received: by 10.107.78.6 with SMTP id c6mr3768880iob.128.1506540934160; Wed,
	27 Sep 2017 12:35:34 -0700 (PDT)
MIME-Version: 1.0
Sender: nbvfour@gmail.com
Received: by 10.79.138.3 with HTTP; Wed, 27 Sep 2017 12:35:33 -0700 (PDT)
In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>
References: <20170927160654.GA12492@savin.petertodd.org>
From: Chris Priest <cp368202@ohiou.edu>
Date: Wed, 27 Sep 2017 13:35:33 -0600
X-Google-Sender-Auth: TH0EI_7I703XG7te4wZlWgY7Rhw
Message-ID: <CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403043ccee03867ad055a30e50d"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	FREEMAIL_FROM,HTML_MESSAGE,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 20:09:53 +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: Wed, 27 Sep 2017 19:35:35 -0000

--f403043ccee03867ad055a30e50d
Content-Type: text/plain; charset="UTF-8"

A better solution is to just have the sending wallet check to see if the
address you are about to send to has been used before. If it's a fresh
address, it sends it through without any popup alert. If the address has
history going back a certain amount of time, then a popup comes up and
notifies the sender that they are sending to a non-fresh address that may
no longer be controlled by the receiver anymore.

Also, an even better idea is to set up an "address expiration service".
When you delete a wallet, you first send off an "expiration notice" which
is just a message (signed with the private key) saying "I am about to
delete this address, here is my new address". When someone tries to send to
that address, they first consult the address expiration service, and the
service will either tell them "this address is not expired, proceed", or
"this address has been expired, please send to this other address
instead...". Basically like a 301 redirect, but for addresses. I don't
think address expiration should be part of the protocol.

On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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;
> there
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing
> deposits.
> This also makes it difficult operationally to rotate private keys. I
> personally
> 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 fresh
> one.
>
> 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.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from a user
> point
> of view: their experience with them should be more like "payment codes",
> with a
> code being valid for payment for a short period of time; wallets should
> not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> 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.
>
> 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.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Chris Priest
786-531-5938

--f403043ccee03867ad055a30e50d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A better solution is to just have the sending wallet check=
 to see if the address you are about to send to has been used before. If it=
&#39;s a fresh address, it sends it through without any popup alert. If the=
 address has history going back a certain amount of time, then a popup come=
s up and notifies the sender that they are sending to a non-fresh address t=
hat may no longer be controlled by the receiver anymore.<div><br></div><div=
>Also, an even better idea is to set up an &quot;address expiration service=
&quot;. When you delete a wallet, you first send off an &quot;expiration no=
tice&quot; which is just a message (signed with the private key) saying &qu=
ot;I am about to delete this address, here is my new address&quot;. When so=
meone tries to send to that address, they first consult the address expirat=
ion service, and the service will either tell them &quot;this address is no=
t expired, proceed&quot;, or &quot;this address has been expired, please se=
nd to this other address instead...&quot;. Basically like a 301 redirect, b=
ut for addresses. I don&#39;t think address expiration should be part of th=
e protocol.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev <span di=
r=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Re-use of old addresses is a major problem=
, not only for privacy, but also<br>
operationally: services like exchanges frequently have problems with users<=
br>
sending funds to addresses whose private keys have been lost or stolen; the=
re<br>
are multiple examples of exchanges getting hacked, with users continuing to=
<br>
lose funds well after the actual hack has occured due to continuing deposit=
s.<br>
This also makes it difficult operationally to rotate private keys. I person=
ally<br>
have even lost funds in the past due to people sending me BTC to addresses =
that<br>
I gave them long ago for different reasons, rather than asking me for fresh=
<br>
one.<br>
<br>
To help combat this problem, I suggest that we add a UI-level expiration ti=
me<br>
to the new BIP173 address format. Wallets would be expected to consider<br>
addresses as invalid as a destination for funds after the expiration time i=
s<br>
reached.<br>
<br>
Unfortunately, this proposal inevitably will raise a lot of UI and terminol=
ogy<br>
questions. Notably, the entire notion of addresses is flawed from a user po=
int<br>
of view: their experience with them should be more like &quot;payment codes=
&quot;, with a<br>
code being valid for payment for a short period of time; wallets should not=
 be<br>
displaying addresses as actually associated with specific funds. I suspect<=
br>
we&#39;ll see users thinking that an expired address risks the funds themse=
lves;<br>
some thought needs to be put into terminology.<br>
<br>
Being just an expiration time, seconds-level resolution is unnecessary, and=
<br>
may give the wrong impression. I&#39;d suggest either:<br>
<br>
1) Hour resolution - 2^24 hours =3D 1914 years<br>
2) Month resolution - 2^16 months =3D 5458 years<br>
<br>
Both options have the advantage of working well at the UI level regardless =
of<br>
timezone: the former is sufficiently short that UI&#39;s can simply display=
 an<br>
&quot;exact&quot; time (though note different leap second interpretations),=
 while the<br>
latter is long enough that rounding off to the nearest day in the local<br>
timezone is fine.<br>
<br>
Supporting hour-level (or just seconds) precision has the advantage of maki=
ng<br>
it easy for services like exchanges to use addresses with relatively short<=
br>
validity periods, to reduce the risks of losses after a hack. Also, using a=
t<br>
least hour-level ensures we don&#39;t have any year 2038 problems.<br>
<br>
Thoughts?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
Chris Priest<div>786-531-5938</div></div></div>
</div>

--f403043ccee03867ad055a30e50d--