Skip to content

Latest commit

 

History

History
154 lines (107 loc) · 5.32 KB

NOTE-Protocol-V1-English.md

File metadata and controls

154 lines (107 loc) · 5.32 KB

NOTE Protocol User White Paper

1. Introduction

We propose a new protocol for private data storage in a distributed peer-to-peer internet, which uses the underlying blockchain to store the data in a directed graph structure. The protocol uses the BIP32 standard to determine the rules for generating the private key, employs the Electrum BIE1 ECIES algorithm to encrypt the data, specifies the data storage format, and implements the rules for adding, modifying, deleting, and sharing the data.

According to the NOTE protocol, your information security does not require trust in any third party. Data security and storage security are achieved, and only mnemonic holders can access the data. The data is not stored on a specific third-party server or cloud service.

This is a layer-2 solution, built on the immutable Bitcoin protocol and the consensus rule of the blockchain.

The protocol supports high-concurrency chaining of data from the same mnemonic account, encryption and decryption of each record using unpredictable random public-private keys, sharing of encrypted data among multiple users, and other features.

2. Prerequisite Knowledge

2.1 BIP32

BIP32 defines an algorithm for deriving a private key from a mnemonic. The corresponding public key and public key hash (i.e., address) can be obtained from the private key.

2.2 Electrum BIE1 ECIES

Electrum BIE1 ECIES defines how to encrypt and decrypt data using the elliptic curve algorithm.

2.3 Bitcom

Bitcom protocol defines each account namespace.

3. NOTE Protocol

3.1 Derived Index and Private Key Derivation Path

m/purpose'/coin_type'/account'/target/quotient/remainder

where:

purpose = 44
coin_type=236
account=0
target=2

A 64-bit number is randomly generated as a derived index, and the quotient and remainder are calculated. The index complies with IEEE754 and requires a value between 1 and 2^53-1.

  const Hardened = 0x80000000
  const quotient = Math.floor(index / Hardened)
  const remainder = index % Hardened

The full derivation path is:

  const extPath = `m/44'/236'/0'/2/${quotient}/${remainder}`

3.2 Root Private Key and Root Address

The root private key is derived based on the following path:

  const extPath = `m/44'/236'/0'`

3.3 Storage Format

The data is stored as an OP_RETURN value and is divided into four parts:

OP_FALSE OP_RETURN Root address, derived index, encrypted data, signature

where

  1. Root address: generated by the root private key
  2. Derived index: a randomly generated 64-bit number
  3. Encrypts data: data encrypted using a key pair created with a derived index, using the public key
  4. Signature: the encrypted data is signed using the root private key

3.4 Signature

The signature uses the root private key to sign the SHA256 hash of the encrypted data. The root address public key can be made public, and anyone can verify that the data has not been tampered with using the root address public key. This is used for determining authority.

sign（sha256( encrypedNote ))

3.5 Data Format

User data can be in any format. The data is encrypted using the Electrum BIE1 ECIES encryption algorithm.

The following JSON format definition belongs to NoteSV, the secure note and password management software. Other software using the NOTE protocol can define their own formats:

{
  id:
  tpl:
  ttl:
  mem:
  fid:
  pwd:
  url:
  otp:
  ptx:
  tags: []
  files:[],
  tms
}

Where

  • id: main key
  • tpl: template
  • ttl: title
  • mem: content
  • fid: user name
  • pwd: user password
  • url: website link
  • otp: one-time password key
  • tags: tags/labels
  • files: attached files
  • del: delete flag
  • ptx: parent Tx ID
  • tms: Unix timestamp

4. Create, Update, and Delete Data

The ID of the data creation is in the form of the current Unix timestamp plus a random number. This allows you to sort ids chronologically and avoid multiple apps that store data concurrently with the account.

Data updates do not change the data id, only the other fields.

The Data ID is not changed when the data is deleted, but the DEL field is set to true.

5. Data Fetching

The root address in the data store is entered into the BITCOM protocol, and all transactions are retrieved using a Bitcom-enabled bitcoin data service provider.

6. Data Sharing

Before sharing the data, you need to get the other party’s root public key. The storage format is:

OP_FALSE OP_RETURN Root address, derived index, encrypted data, signature

Where

  1. Root address: get the root address of the other party through the public key
  2. Derived index: set to 0
  3. Encrypted data: encrypts data using the other party’s root public key
  4. Signature: the encrypted data is signed using your own root private key

7. Data security

7.1 Signature

All data can be verified using the root address public key to determine whether the data was created by the person who owns the root address or by the sharers. The reason for this check is that the person who created the data knew the public key of the encrypted data and forged a piece of data, but did not know the private key of the root address and could not forge the signature.