Difference between revisions of "MIP-0001"

From Mochimo Wiki
Jump to: navigation, search
(Sponsor(s))
(Solution Summary)
 
Line 11: Line 11:
  
 
== Solution Summary ==
 
== Solution Summary ==
Within the ledger in a Mochimo node, a new field will be added to each address entry.  This field will contain the block in which an address was created.  After a certain number of blocks has passed (equal to about 82 years total) the coins in a wallet that have never been spent will return to the pool of coins available to be mined.  For the purposes of this MIP, "created" means the block in which a tag changes WOTS+ addresses (meaning the tag is spent and bound to a new WOTS+ address), or in which the tag was first created if it has never been spent.  For raw WOTS addresses, this is the block in which the WOTS address was created.
+
After 2^23 blocks (approximately 82 years), an unspent address will be removed from the ledger, and those coins will be added back to the pool of mineable coins.  Within the ledger in a Mochimo node, a new field will be added to each address entry.  This field will contain the block in which an address was created.  For the purposes of this MIP, "created" means the block in which a tag changes WOTS+ addresses (meaning the tag is spent and bound to a new WOTS+ address), or in which the tag was first created if it has never been spent.  For raw WOTS addresses, this is the block in which the WOTS address was created.  As each block is mined, the existing ledger will be scanned for addresses that haven't been spent in the last 82 years, remove them, and add their balances to the pool of mineable coins.
  
 
== Hard Fork Required ==
 
== Hard Fork Required ==

Latest revision as of 19:46, 5 October 2020

MIP-0001 - Add Upper Limit to Wallet Lifespan

Presented to the Core Contributor Team on October 4th, 2020 by user NickP05

Sponsor(s)

The following Core Contributors have "sponsored" this MIP.

Stackoverflo (talk · contribs) This looks like it's worth doing. I'll implement if the community wants it.



NOTE: Sponsorship for these purposes means that these Core Contributors have committed to developing the code on behalf of the community if this MIP is adopted. Note: Core Contributor sponsorship is not required for a MIP to be implemented. It just makes things easier on the community.

Problem Definition

Existing blockchain based cryptocurrencies allow coins to become "lost" over time, never to be recovered. This happens because cryptocurrency wallet keys are lost. Eventually many millions of coins are lost this way.

Solution Summary

After 2^23 blocks (approximately 82 years), an unspent address will be removed from the ledger, and those coins will be added back to the pool of mineable coins. Within the ledger in a Mochimo node, a new field will be added to each address entry. This field will contain the block in which an address was created. For the purposes of this MIP, "created" means the block in which a tag changes WOTS+ addresses (meaning the tag is spent and bound to a new WOTS+ address), or in which the tag was first created if it has never been spent. For raw WOTS addresses, this is the block in which the WOTS address was created. As each block is mined, the existing ledger will be scanned for addresses that haven't been spent in the last 82 years, remove them, and add their balances to the pool of mineable coins.

Hard Fork Required

Yes.

Technical Details

  • In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.
  • In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.
  • In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).
  • Add 8-byte global variable Recovered_coins
  • In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.
    • If the above is true, set the mining reward for the current block to +=1 MCM.
  • In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.
    • If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.
  • In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.
    • If the above is false, the block fails validation.
  • In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.
    • If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.
      • If the above is false, the block fails validation.
  • In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.
    • If the above is true, increment the global Recovered_coins variable with the Amount from the address.
    • If the above is true, remove the Ledger entry for that address.