Skip to content

Latest commit

 

History

History
73 lines (53 loc) · 4.32 KB

rip-0020.mediawiki

File metadata and controls

73 lines (53 loc) · 4.32 KB

RIP: 20
Title: 12 words and a number
Author: Tron Black <[email protected]>
Comments-Summary: No comments yet
Comments-URI: https://github.com/RavenProject/rips
Status: Draft
Type: Process
Created: 2021-03-23

Table of Contents

Abstract

This RIP proposes including a number when giving the user their 12-word backup words. The number is the number of weeks since Jan 3, 2018 00:00 UTC. This will allow SPV mobile wallets to begin scanning for crypto-currency (or assets) later in the blockchain which will save hours of sync time.

Motivation

Sync times are long and getting longer. Mobile wallets can verify block headers quickly, but scanning through large blocks looking for crypto-currency or assets that belong to the addresses derived from 12-word seed can take a long time.

Further security optimizations like checkpoints can allow SPV wallets to skip the history which isn't relevant to the user's crypto-currencies.

Methodology

The Unix epoch is the time 00:00:00 UTC on Jan 1, 1970, and the Unix timestamp is the number of seconds since then.

Take the Unix timestamp for Jan 3, 2018 at 0:00 UTC 1514962800

Take the Unix timestamp for the date/time that the seed words are generated: Now = 1616530560

Take the difference: 1616530560 - 1514962800 = 101567760 That gives you the number of seconds since the Ravencoin genesis block. A notable time in history and Bitcoin's 9th birthday.

Divide the result by 604800 (seconds in a week) 101567760 / 604800 = 167.936111111111111

Truncate after the decimal FLOOR(167.936111111111111) = 167

That's the number that should be included after the 12-words.

Benefits

  • The number is optional. If the wallet doesn't support it, then the wallet scans from the beginning of the blockchain.
  • The number is optional. If the wallet does support it, and the user doesn't have it, then the wallet scans from the beginning of the blockchain.
  • The number is small, and unlikely to be written down wrong. Even ten years from now the number is: 689
  • It will be a 3 digit number for another 15 years.
  • It gets more valuable over time, potentially shaving off ten or twenty years of blockchain to scan.
  • For someone restoring a recently created mobile wallet, this could save 18 hours of sync time -- every time it is restored.
  • The Unix timestamp is based off of UTC, so it is the same around the world. It does not factor in time zones.
  • By lopping off the decimal, the wallet is starting on average 1/2 week before the first transaction.
  • At-worst at the time of the transaction if the transaction was instantly put into a block and instantly mined. Clocks may be off, but are rarely off by much, and since transactions take time to be mined the transaction will almost certainly take place after the calculated Unix timestamp.
  • If, in the extreme case of the timestamp in the block being off (late) indicating to the wallet that it does not need to scan earlier, and the transaction was missed, then decrementing the number by 1 will solve it. This is an extreme case, and unlikely to ever happen.
  • If you want to know when you created the wallet, you can use this:
  • 1514962800 + (604800 * number), and paste it in here: https://www.epochconverter.com/. That'll get you within a week of when you created your wallet.

Implementation

This simple specification is intended to be implemented by wallets which use addresses derived using BIP32, BIP39, and BIP44, and in particular use a 12 or 24 word mnemonic to back up the seed that generates the private keys and associated addresses.

Take the number and multiply it by 604800 and add it to 1514962800, and start scanning blocks from there.

There's a few ways to go about this: - Estimate the starting block based on the coins block time. If the timestamps in the block header are before the calculated Unix timestamp, then scan from there. If less, then back up by some number of blocks and try again. - If the SPV has checkpoints, then use the closest checkpoint that has a timestamp in the block header that is before the Unix timestamp.

References