|
@@ -0,0 +1,53 @@
|
|
|
+<pre>
|
|
|
+ PIP: PIP-0012
|
|
|
+ Title: Change account recovery to 10 years
|
|
|
+ Type: Protocol
|
|
|
+ Impact: Hard-Fork
|
|
|
+ Author: Herman Schoenfeld <i><[email protected]></i>
|
|
|
+ Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0012)
|
|
|
+ Status: Proposed
|
|
|
+ Created: 2018-01-03
|
|
|
+</pre>
|
|
|
+
|
|
|
+## Summary
|
|
|
+
|
|
|
+It is proposed that the RECOVER operation be changed from 4 years to 10 and to include the account itself in the recovery.
|
|
|
+
|
|
|
+## Motivation
|
|
|
+
|
|
|
+Coinrot is a serious economic issue afflicting almost all other cryptocurrencies. Coinrot is the phenomenon of coins being permanently lost due to lost/corrupted keys and/or natural death. It is estimated that 20% of Bitcoins have already rotted. PascalCoin solves this problem by allowing PASC to be transferred from an account, without owners signature, after an inactivity period of 4 years. Whilst this is a good start, it does not solve the problem of PASA-rot, which is a far more limited (and important) resource than PASC. Also, community has expressed discomfort with the 4 year period, pointing out long-term savers could be seriously afflicted.
|
|
|
+
|
|
|
+## Specification
|
|
|
+
|
|
|
+The proposal here is to simply to change RECOVER operation inactivity period from 4 years to 10 **and** to simply update the key of the recovered account rather than transferring it's balance. This allows both the PASA and PASC to be recovered in a single operation, with minimal code changes.
|
|
|
+
|
|
|
+### Definitions
|
|
|
+
|
|
|
+let RecoverOperation denote the recovery operation.
|
|
|
+
|
|
|
+let RecoverOperation.InactiveAccount denote the account being recovered
|
|
|
+
|
|
|
+let RecoverOperation.NewOwnerAccount denote the destination account to transfer the recovered PASC to.
|
|
|
+
|
|
|
+### Current Algorithm
|
|
|
+
|
|
|
+1. Verify RecoverOperation in similar way to TRANSACTION operations
|
|
|
+2. Verify ( SafeBox.LastBlockNumber - SafeBox.Accounts[ RecoverOperation.InactiveAccount].LastUpdatedBlock ) >= 420480
|
|
|
+3. Transfer balance from RecoverOperation.InactiveAccount to RecoverOperation.NewOwnerAccount
|
|
|
+
|
|
|
+### Proposed Algorithm
|
|
|
+
|
|
|
+let RecoverOperation.NewOwnerKey denote the new owners account key.
|
|
|
+
|
|
|
+1. Verify RecoverOperation in similar manner to CHANGE KEY operation
|
|
|
+2. Verify ( SafeBox.LastBlockNumber - SafeBox.Accounts[ RecoverOperation.InactiveAccount ].LastUpdatedBlock ) >= 1051200
|
|
|
+3. Change key of InactiveAccount to RecoverOperation.NewOwnerKey
|
|
|
+
|
|
|
+
|
|
|
+## Rationale
|
|
|
+
|
|
|
+Other approaches were considered such as allowing partial recovery of funds every sub-period. For example, allowing 10% of the balance to be recovered every 2 weeks, after 4 years of inactivity. All such approaches were significantly more complicated and required much more development, which adds hard-fork risk (especially when combined with other PIPs in V3 release). As a result, the simplest most elegant solution was chosen.
|
|
|
+
|
|
|
+## Backwards Compatibility
|
|
|
+
|
|
|
+This proposal is not backwards compatible and requires a hard-fork activation. However, since PascalCoin has not been around for 4 years, the old RECOVER algorithm can safely be discarded from the protocol.
|