CryptAxe [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-27 📝 Original message:I do agree with you to a ...
📅 Original date posted:2017-09-27
📝 Original message: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 at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Chris
> Priest via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/c2fbfa44/attachment-0001.html>;
📝 Original message: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 at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Chris
> Priest via bitcoin-dev <bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/c2fbfa44/attachment-0001.html>;