public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: CryptAxe <cryptaxe@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Address expiration times should be added to BIP-173
Date: Wed, 27 Sep 2017 13:19:48 -0700	[thread overview]
Message-ID: <12c4295c-9546-ba0a-5bd4-4e7e9282daf1@gmail.com> (raw)
In-Reply-To: <CY4PR12MB139977628660D809B611D8ACC8780@CY4PR12MB1399.namprd12.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]

I do agree with you to a degree, but address reuse is actually not even
supposed to work (it is a bug). Peter Todd is suggesting only to make
expiration a part of a new address format, and we could have a GUI
warning (but no protocol change) for the existing formats. What do you
think about that?


On 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote:
>
> As a long term silent reader of this list, I felt compelled to comment
> on this address expiration topic.  I don't believe that address
> expiration should be part of the protocol.  I think instead that the
> "sending" feature should 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" that the sender acts on.
>
>
> I also think that re-directs are fraught with privacy issues.  At the
> end of the day, the ultimate burden is on the sender (with much self
> interest from the receiver) that the correct address is being used.
>
>
>
> ------------------------------------------------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org
> <bitcoin-dev-bounces@lists.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 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
> <mailto: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
>     <http://petertodd.org>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> -- 
> Chris Priest
> 786-531-5938
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 10739 bytes --]

  reply	other threads:[~2017-09-27 20:28 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 16:06 [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-27 18:15 ` CryptAxe
2017-09-27 19:03 ` Mark Friedenbach
2017-09-27 21:20   ` Peter Todd
2017-09-27 19:35 ` Chris Priest
2017-09-27 20:11   ` CryptAxe
2017-09-27 20:23   ` Nick Pudar
2017-09-27 20:19     ` CryptAxe [this message]
2017-09-27 21:09     ` Mark Friedenbach
2017-09-27 21:15   ` Peter Todd
2017-09-28  0:22   ` Gregory Maxwell
2017-09-27 21:33 ` Peter Todd
2017-09-28  0:58 ` Gregory Maxwell
2017-09-29  1:50   ` Peter Todd
2017-09-29  2:06     ` Gregory Maxwell
2017-09-28 10:09 ` Andreas Schildbach
2017-09-28 12:43   ` Sjors Provoost
2017-09-28 14:13     ` Andreas Schildbach
2017-09-28 14:41       ` Sjors Provoost
2017-09-28 15:06         ` Andreas Schildbach
2017-09-28 15:45           ` Sjors Provoost
2017-09-28 16:59       ` Luke Dashjr
2017-09-29  2:18     ` Peter Todd
2017-09-29  7:18       ` Sjors Provoost
2017-09-29  2:55     ` [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks Peter Todd
2017-09-29  4:21       ` Omar Shibli
2017-09-29 13:14       ` Tomas
2017-09-29 17:40         ` Aymeric Vitte
2017-09-30 15:33       ` Andreas Schildbach
2017-09-29  1:45   ` [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-29  8:44     ` Andreas Schildbach
2017-09-29  9:55       ` Peter Todd
2017-09-29 12:45         ` Andreas Schildbach
2017-09-29 13:52           ` Peter Todd
2017-09-29 17:25           ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12c4295c-9546-ba0a-5bd4-4e7e9282daf1@gmail.com \
    --to=cryptaxe@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox