+Return-Path: <cryptaxe@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id A8D109C0

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 27 Sep 2017 18:23:32 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FFFA367

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 27 Sep 2017 18:23:32 +0000 (UTC)

+Received: by mail-pg0-f49.google.com with SMTP id v23so8224452pgc.5

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 27 Sep 2017 11:23:32 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;

+ h=subject:to:references:from:message-id:date:user-agent:mime-version

+ :in-reply-to:content-language;

+ bh=BWgioKGMxcDYfqpf0MBVh3FJFviP4zrsMkmOXhqIc4U=;

+ b=rxozI3Hvr4CAdnIAl97DAVTdqeXdfJDnTZqK9HJJwps1MgfiuiXNM8ZUsZfwRLxD26

+ AYp/R5kD6PcKc4KiIZ+5tDh0443QbiUn5oHZ1Rilfn5TIr7FwoWW3KX0hGR+cW/ZtBXF

+ YIqdxUIswXA2+2rFvUVNfWETbpSFz/h4Z+U5R0HVT0GzauD2WYfBW1tRt6Zcw5UWPYHY

+ avAxSqtMm/EhP5SAtGwnIG7jnbaIgW4VfPQjJUCbGMaQ6LcRG5lK2U1Xvnl8xn0rSH7E

+ pYISz6maSB5fmnsCRBHPFcXivSQWkTiOHuOfv9PwpOAhslmX65hogafwKTHKPa/N2O+3

+ P64Q==

+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

+ d=1e100.net; s=20161025;

+ h=x-gm-message-state:subject:to:references:from:message-id:date

+ :user-agent:mime-version:in-reply-to:content-language;

+ bh=BWgioKGMxcDYfqpf0MBVh3FJFviP4zrsMkmOXhqIc4U=;

+ b=sLzaCmmKOL4a7E2FMZ+szwix2w1/GrEKvqere8lG5z9nxhl3K90jQjpfO6niDZTZHm

+ h99KvMRF2iLWznnHUg7YbX1lbb+T3Gc7oDQyN06ZNQ8HVh5GXFa+fzB0fS6jPFkq4R27

+ Q6WClCkCV5qAZLEZT+IiLzjzkZ7NDjNSf0nwLR3yEO+GhOXidvhirBavqNLa9jKO6DPG

+ pInFCZ2n72vXfkjkfGymD3Sw6/FJhgP2OTzLucMpRR4PX7ySIDUYoIFA4aRbfv/Rf25M

+ KR+o5vIhXwCnKHF86UkgU5yYDcASLMMAjQILIWFez6rcfL0rZlxv6Kg0HV7yDyRkzQmY

+ /0SA==

+X-Gm-Message-State: AHPjjUgUizJfmp7LloiaBqI7e5NopUehtHTESqtpUmlFgQOvsd4EypJr

+ 9r4Hswdtf7MYvx6xwQizOMRnNHSp

+X-Google-Smtp-Source: AOwi7QDZ65HAo5dh4Nnva3g4xBTaqwpQdHN9X99H1tdrA1Olipo0o97BtJjxuMYXtreCQuPxFp0XFQ==

+X-Received: by 10.84.132.129 with SMTP id e1mr1949598ple.444.1506536611227;

+ Wed, 27 Sep 2017 11:23:31 -0700 (PDT)

+Received: from [192.168.1.3] (c-73-240-125-172.hsd1.or.comcast.net.

+ [73.240.125.172]) by smtp.gmail.com with ESMTPSA id

+ p85sm21677744pfj.47.2017.09.27.11.23.29

+ for <bitcoin-dev@lists.linuxfoundation.org>

+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

+ Wed, 27 Sep 2017 11:23:30 -0700 (PDT)

+To: bitcoin-dev@lists.linuxfoundation.org

+References: <20170927160654.GA12492@savin.petertodd.org>

+From: CryptAxe <cryptaxe@gmail.com>

+Message-ID: <f7ee0056-5fd3-e72a-9f9a-776c0f877ab1@gmail.com>

+Date: Wed, 27 Sep 2017 11:15:20 -0700

+User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101

+ Thunderbird/52.2.1

+MIME-Version: 1.0

+In-Reply-To: <20170927160654.GA12492@savin.petertodd.org>

+Content-Type: multipart/alternative;

+ boundary="------------D680DB84B4B46B9BB11EB50A"

+Content-Language: en-US

+X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,

+ DKIM_VALID_AU,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 18:25:44 +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 18:23:32 -0000

+

+This is a multi-part message in MIME format.

+--------------D680DB84B4B46B9BB11EB50A

+Content-Type: text/plain; charset=windows-1252

+Content-Transfer-Encoding: quoted-printable

+

+I think we need something like this. Hour resolution seems like the

+correct choice to me.

+

+Please someone steal whatever code you can from this PR when

+implementing the UI for BIP173 expiration:

+

+https://github.com/bitcoin/bitcoin/pull/9722

+

+I have a rebased version as well if anyone wants it.

+

+

+On 09/27/2017 09:06 AM, 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

+> are multiple examples of exchanges getting hacked, with users continuin=

+g to

+> lose funds well after the actual hack has occured due to continuing dep=

+osits.

+> This also makes it difficult operationally to rotate private keys. I pe=

+rsonally

+> have even lost funds in the past due to people sending me BTC to addres=

+ses that

+> I gave them long ago for different reasons, rather than asking me for f=

+resh

+> one.

+>

+> To help combat this problem, I suggest that we add a UI-level expiratio=

+n time

+> to the new BIP173 address format. Wallets would be expected to consider=

+

+> addresses as invalid as a destination for funds after the expiration ti=

+me is

+> reached.

+>

+> Unfortunately, this proposal inevitably will raise a lot of UI and term=

+inology

+> questions. Notably, the entire notion of addresses is flawed from a use=

+r 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 susp=

+ect

+> we'll see users thinking that an expired address risks the funds themse=

+lves;

+> 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 regardl=

+ess 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 sh=

+ort

+> validity periods, to reduce the risks of losses after a hack. Also, usi=

+ng at

+> least hour-level ensures we don't have any year 2038 problems.

+>

+> Thoughts?

+>

+>

+>

+> _______________________________________________

+> bitcoin-dev mailing list

+> bitcoin-dev@lists.linuxfoundation.org

+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+

+

+--------------D680DB84B4B46B9BB11EB50A

+Content-Type: text/html; charset=windows-1252

+Content-Transfer-Encoding: 8bit

+

+<html>

+ <head>

+ <meta http-equiv="Content-Type" content="text/html;

+ charset=windows-1252">

+ </head>

+ <body text="#000000" bgcolor="#FFFFFF">

+ <p>I think we need something like this. Hour resolution seems like

+ the correct choice to me.</p>

+ <p>Please someone steal whatever code you can from this PR when

+ implementing the UI for BIP173 expiration:</p>

+ <p><a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/pull/9722">https://github.com/bitcoin/bitcoin/pull/9722</a> <br>

+ </p>

+ <p>I have a rebased version as well if anyone wants it.<br>

+ </p>

+ <br>

+ <div class="moz-cite-prefix">On 09/27/2017 09:06 AM, Peter Todd via

+ bitcoin-dev wrote:<br>

+ </div>

+ <blockquote type="cite"

+ cite="mid:20170927160654.GA12492@savin.petertodd.org">

+ <pre wrap="">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?

+

+</pre>

+ <br>

+ <fieldset class="mimeAttachmentHeader"></fieldset>

+ <br>

+ <pre wrap="">_______________________________________________

+bitcoin-dev mailing list

+<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>

+<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>

+</pre>

+ </blockquote>

+ <br>

+ </body>

+</html>

+

+--------------D680DB84B4B46B9BB11EB50A--

+