Re: [bitcoin-dev] BIP - Dead Man's Switch

[Nick Pudar via bitcoin-dev]

This topic has come up several times in recent years. While it is well 
intentioned, it can have devastating outcomes for people that want to save long 
term. If such a system were implemented, it would force people to move funds 
around in order to not get nullified. In that process, it introduces multiple 
opportunities for errors. Cold storage should be able to stay cold. I 
personally would be apprehensive about implementing this kind of a system.

...via Android



From: Teweldemedhin Aberra via bitcoin-dev
Sent: Monday, December 11, 1:04 PM
Subject: [bitcoin-dev] BIP - Dead Man's Switch
To: bitcoin-dev@lists.linuxfoundation.org


It is estimated that about 4 million of the about 16.4 Bitcoins ever mined are 
lost forever because no one knows the private keys of some Bitcoin addresses. 
This effectively mean there are actually only 14.4 million Bitcoins in 
circulation even though 16.4 million are mined. There is no way of eliminating 
the human errors that cause these losses of Bitcoin from circulation, while the 
number of Bitcoin that will ever be mined is capped at 21 million. This means 
the total number of Bitcoins that are in circulation will eventually become 
zero, bringing the network to an end.
The solution this BIP proposes is to implementing a dead man's switch to 
Bitcoin addresses. The dead man's switch causes the Bitcoins assigned to 
dormant addresses to automatically expire. A Bitcoin address is deemed dormant 
if it is not used in transactions for some fixed length of time, say ten years.
The calculation of the miner's reward should take into account the Bitcoins 
that has expired. This means there is a possibility that miner's reward can 
increase if sufficient number of Bitcoins expire.

Ref:
http://fortune.com/2017/11/25/lost-bitcoins/


Virus-free.


www.avast.com




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

[Nick Pudar via bitcoin-dev]

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-boun...@lists.linuxfoundation.org 
 on behalf of Chris Priest via 
bitcoin-dev 
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 
>
 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
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