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
Subject: Re: [bitcoin-dev] Address expiration times should be added to
	BIP-173
Precedence: list

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--