path: root/bd/ac9696ed15555edf74056915783635fe95c10b

Return-Path: <nick@pudar.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E0839B35
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Sep 2017 20:23:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
	(mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC28943A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Sep 2017 20:23:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Pudar.onmicrosoft.com; 
	s=selector1-pudar-com;
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=5GuNKaw5NRTbpW6s0UKXOQJD1LtbwiOn5iWJ4Bq0LvE=;
	b=QjaykOYYBKiDeLonjqnf4UHQaur3KauUWlj4lMNCNGP3yyA/TR337CwhYjCmE1WEcfINSuipi3+rKDdDUiHtGHNg/74cVX05s4VPfmK0sRydVhyVkOPTUM9G84ffzUpAk42e9n78MiSOdO/Qk/MfKzgBgtvBCxt7nZlwBN9fGvo=
Received: from CY4PR12MB1399.namprd12.prod.outlook.com (10.168.169.20) by
	CY4PR12MB1398.namprd12.prod.outlook.com (10.168.169.19) with Microsoft
	SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
	15.20.77.7; Wed, 27 Sep 2017 20:23:33 +0000
Received: from CY4PR12MB1399.namprd12.prod.outlook.com ([10.168.169.20]) by
	CY4PR12MB1399.namprd12.prod.outlook.com ([10.168.169.20]) with mapi id
	15.20.0077.011; Wed, 27 Sep 2017 20:23:33 +0000
From: Nick Pudar <nick@pudar.com>
To: Peter Todd <pete@petertodd.org>, Chris Priest <cp368202@ohiou.edu>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Address expiration times should be added to BIP-173
Thread-Index: AQHTN8yj65bHFQ/PhEqsdXW+w3jJj6LJK1U8
Date: Wed, 27 Sep 2017 20:23:33 +0000
Message-ID: <CY4PR12MB139977628660D809B611D8ACC8780@CY4PR12MB1399.namprd12.prod.outlook.com>
References: <20170927160654.GA12492@savin.petertodd.org>,
	<CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com>
In-Reply-To: <CAAcC9yvdw4Yphs-prpckaouzaU21D=kGRqK+gG9SbPr-=27z9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick@pudar.com; 
x-originating-ip: [198.208.159.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR12MB1398;
	6:tiY/gbuWgKq215nT2Aq4W98iiLtB1t7osDfitb5o7xU+nyJOEU45CMXtOUAg3ZQAvuu5bnhv6q9LjZlYJyc5LhdfG6qcCnh5TVSkrc/ws9IOEVzMCVYNiSH+zYoF3kG53KZ1lYNHKDrSDQNHOYbA4GXY7Z3f9Ctza3KpcF3HfGg8kE8opFMSR/TwYTjxh/prboG4Gqo+/45lyG1IWtyNhZSVzPBT828v8YZY+GNMlBGY6TvJR0LoWUBc30f9t9Sthy8vi4n4ZPYcoTe1Op7saRSxhxhcwGz3izJkj+rJBRXKKKP+wW46Egx4qtWAEpt52lnvUVmWbwzDstlmNM4O8A==;
	5:4sG3/a9HDXyngHvCehue9YJdX7bBwLO809veLBnDD3ojYBvNLWAoXaXWX8sIA9CdJmBIxk9gExr2BTFCpQCQnYMa/Aox6qAwtLMo9vJ7YgmBio1DpR0DePHvP8h/Oh8LNioREDoZhx/ec2SCE+OP5Q==;
	24:z7Xg1nJZHOOa9vQqBp6d4zUSxpglv/E4bhee7KzIvSB0BDmXVJN/UpTw5VT3x/tcSTEDfUDtzax1Wk0tzLvU72BNc8vR27e333DOWe8z8Bw=;
	7:FFOtUyEg0sEm82TYjkU889XiFJNGwDMPnhX1fV7H5il9mXyWBogYthD4oC53IO6N9ngAf0ZzFpvS0EXtG1Ceu/h5Th57lL+jalfZTYr4r/SQuc/pjyfjF8jFk7yoG4W4rAuwkbuxruKW1qb0pvOMiU0FXpbjcObFYPLEnvoSJl+Ic4tp1JQQqRJG1Bg8IjAIWXvjGqJPTRzeiA2Nxq8m/BdAv5e/ewjWvlYSLLJhCXc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 18ed5b5d-569f-4e6b-a56c-08d505e5a042
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(2017030254152)(2017082002075)(2017052603199)(201703131423075)(201702281549075);
	SRVR:CY4PR12MB1398; 
x-ms-traffictypediagnostic: CY4PR12MB1398:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <CY4PR12MB139882CD927E0017C7F9A0B7C8780@CY4PR12MB1398.namprd12.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(2016111802025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);
	SRVR:CY4PR12MB1398; BCL:0; PCL:0;
	RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);
	SRVR:CY4PR12MB1398; 
x-forefront-prvs: 04433051BF
x-forefront-antispam-report: SFV:NSPM;
	SFS:(10019020)(376002)(39830400002)(346002)(199003)(189002)(24454002)(377454003)(14454004)(6306002)(5660300001)(102836003)(236005)(6116002)(3280700002)(2906002)(81156014)(54356999)(55016002)(81166006)(9686003)(76176999)(101416001)(50986999)(316002)(97736004)(8936002)(99286003)(478600001)(189998001)(105586002)(6246003)(2171002)(53936002)(966005)(53546010)(106356001)(53386004)(54896002)(110136005)(561944003)(6606003)(33656002)(606006)(2950100002)(19627405001)(7736002)(74316002)(68736007)(229853002)(2900100001)(86362001)(6436002)(77096006)(6506006)(66066001)(7696004)(3660700001)(3846002)(25786009);
	DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR12MB1398;
	H:CY4PR12MB1399.namprd12.prod.outlook.com; FPR:; SPF:None;
	PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
received-spf: None (protection.outlook.com: pudar.com does not designate
	permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_CY4PR12MB139977628660D809B611D8ACC8780CY4PR12MB1399namp_"
MIME-Version: 1.0
X-OriginatorOrg: pudar.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 20:23:33.5602 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f1f6b170-5e9e-4033-afbb-29c23656ed60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1398
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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:24:55 +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 20:23:38 -0000

--_000_CY4PR12MB139977628660D809B611D8ACC8780CY4PR12MB1399namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As a long term silent reader of this list, I felt compelled to comment on t=
his address expiration topic.  I don't believe that address expiration shou=
ld be part of the protocol.  I think instead that the "sending" feature sho=
uld by default offer guidance to request a fresh address from the recipient=
.  Also allow the receiver of funds to be able to generate an "invoice" tha=
t the sender acts on.


I also think that re-directs are fraught with privacy issues.  At the end o=
f the day, the ultimate burden is on the sender (with much self interest fr=
om the receiver) that the correct address is being used.


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Chris Priest via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org>
Sent: Wednesday, September 27, 2017 3:35 PM
To: Peter Todd; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-=
173

A better solution is to just have the sending wallet check to see if the ad=
dress you are about to send to has been used before. If it's a fresh addres=
s, 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". Whe=
n you delete a wallet, you first send off an "expiration notice" which is j=
ust a message (signed with the private key) saying "I am about to delete th=
is address, here is my new address". When someone tries to send to that add=
ress, they first consult the address expiration service, and the service wi=
ll either tell them "this address is not expired, proceed", or "this addres=
s has been expired, please send to this other address instead...". Basicall=
y 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@l=
ists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wro=
te:
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; the=
re
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposit=
s.
This also makes it difficult operationally to rotate private keys. I person=
ally
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 ti=
me
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.

Unfortunately, this proposal inevitably will raise a lot of UI and terminol=
ogy
questions. Notably, the entire notion of addresses is flawed from a user po=
int
of view: their experience with them should be more like "payment codes", wi=
th 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 =3D 1914 years
2) Month resolution - 2^16 months =3D 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 maki=
ng
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.

Thoughts?

--
https://petertodd.org 'peter'[:-1]@petertodd.org<http://petertodd.org>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




--
Chris Priest
786-531-5938

--_000_CY4PR12MB139977628660D809B611D8ACC8780CY4PR12MB1399namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size: 12pt; color: rgb(0, 0,=
 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, &quot;Apple Co=
lor Emoji&quot;, &quot;Segoe UI Emoji&quot;, NotoColorEmoji, &quot;Segoe UI=
 Symbol&quot;, &quot;Android Emoji&quot;, EmojiSymbols;" dir=3D"ltr">
<p>As a long term silent reader of this list, I felt compelled to comment o=
n this address expiration topic.&nbsp; I don't believe that address expirat=
ion should be part of the protocol.&nbsp; I think instead that the &quot;se=
nding&quot; feature should by default offer guidance
 to request a fresh address from the recipient.&nbsp; Also allow the receiv=
er of funds to be able to generate an &quot;invoice&quot; that the sender a=
cts on.<br>
</p>
<p><br>
</p>
<p>I also think that re-directs are fraught with privacy issues.&nbsp; At t=
he end of the day, the ultimate burden is on the sender (with much self int=
erest from the receiver) that the correct address is being used.</p>
<br>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Chris Priest via bitcoin-dev &lt;bitcoin-dev@lists.linuxfo=
undation.org&gt;<br>
<b>Sent:</b> Wednesday, September 27, 2017 3:35 PM<br>
<b>To:</b> Peter Todd; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Address expiration times should be added =
to BIP-173</font>
<div>&nbsp;</div>
</div>
<div>
<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=
's a fresh address, it sends it through without any popup alert. If the add=
ress has history going back a certain
 amount of time, then a popup comes up and notifies the sender that they ar=
e sending to a non-fresh address that may no longer be controlled by the re=
ceiver anymore.
<div><br>
</div>
<div>Also, an even better idea is to set up an &quot;address expiration ser=
vice&quot;. When you delete a wallet, you first send off an &quot;expiratio=
n notice&quot; which is just a message (signed with the private key) saying=
 &quot;I am about to delete this address, here is my new
 address&quot;. When someone tries to send to that address, they first cons=
ult the address expiration service, and the service will either tell them &=
quot;this address is not expired, proceed&quot;, or &quot;this address has =
been expired, please send to this other address instead...&quot;.
 Basically like a 301 redirect, but for addresses. I don't think address ex=
piration should be part of the protocol.</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via=
 bitcoin-dev
<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1=
px #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'll see users thinking that an expired address risks the funds themselves=
;<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'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'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'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> 'peter'[:-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 class=3D"gmail_signature">
<div dir=3D"ltr">Chris Priest
<div>786-531-5938</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_CY4PR12MB139977628660D809B611D8ACC8780CY4PR12MB1399namp_--