├── arch.png ├── did.png ├── data_en.png ├── data_zh.png ├── LICENSE ├── Readme.md ├── NOTE-Protocol-V1-Chinese.md ├── NOTE-Protocol-V1-English.md ├── NOTE-Protocol-V2-Chinese.md └── NOTE-Protocol-V2-English.md /arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Note-sv/Protocol/HEAD/arch.png -------------------------------------------------------------------------------- /did.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Note-sv/Protocol/HEAD/did.png -------------------------------------------------------------------------------- /data_en.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Note-sv/Protocol/HEAD/data_en.png -------------------------------------------------------------------------------- /data_zh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Note-sv/Protocol/HEAD/data_zh.png -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020-2024 The NOTE Team - note.sv 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /Readme.md: -------------------------------------------------------------------------------- 1 | # NOTE Protocol 2 | 3 | The NOTE protocol enables blockchain systems based on the Bitcoin UTXO model to create and manage digital assets. This protocol supports secure encrypted data storage and communication, and is also applicable to public and transparent data storage, including the management of ownership rights for digital assets such as Tokens and NFTs. 4 | 5 | This protocol is grounded in the BIP32 standard to determine the generation rules for Decentralized Identities (DID). 6 | 7 | For encrypted data, the protocol employs DID rules. Each record is encrypted and decrypted with unpredictable random public and private keys, using the Electrum BIE1 ECIES algorithm for data encryption. 8 | 9 | The protocol specifies the data storage format and defines the rules for data creation, deletion, modification, retrieval, and sharing. 10 | 11 | Information security does not rely on third-party trust; only the holders of mnemonic phrases can access the data, ensuring both data and storage security. 12 | 13 | Utilizing on-chain smart contracts for Bitcoin consensus-level asset verification, combined with off-chain asset indexers, the protocol efficiently interprets on-chain assets and provides Merkle proofs for these assets. 14 | 15 | This is a second-layer solution built upon the unshakeable Bitcoin protocol and its underlying blockchain consensus rules. The protocol also lays the foundational application requirements for Layer 2 networks. 16 | 17 | [Protocol English version](./NOTE-Protocol-V2-English.md) 18 | 19 | [Protocol Chinese version](./NOTE-Protocol-V2-Chinese.md) 20 | 21 | If there are any language errors or logic problems, please let us know. 22 | 23 | 24 | --- 25 | NOTE协议使基于比特币UTXO模型的区块链能够创建及管理数字资产。该协议支持强加密数据存储与通信，亦适用于公开透明的数据存储，包括Token与NFT等数字资产的所有权管理。 26 | 27 | 本协议基于BIP32标准，确定去中心化身份（DID）的生成规则。 28 | 29 | 针对加密数据，本协议采用DID规则，对每条记录以难以预测的随机公私钥加密解密，并使用Electrum BIE1 ECIES算法进行数据加密。 30 | 31 | 协议明确数据存储格式，并定义了数据的增删改查及分享规则。 32 | 33 | 信息安全无须依赖第三方信任，仅助记词持有者可访问数据，确保数据安全与存储安全。 34 | 35 | 利用链上智能合约进行比特币共识级别的资产校验，结合链下资产索引器，高效解读链上资产并提供资产的默克尔证明。 36 | 37 | 此为一种第二层解决方案，基于牢不可破的比特币协议及其底层区块链共识规则。本协议也为Layer 2网络奠定应用基础需求。 38 | 39 | 40 | [中文版协议](./NOTE-Protocol-V2-Chinese.md) 41 | 42 | [英文版协议](./NOTE-Protocol-V2-English.md) 43 | 44 | 如果有任何语言错误或者逻辑问题，请告知 45 | 46 | 47 | -------------------------------------------------------------------------------- /NOTE-Protocol-V1-Chinese.md: -------------------------------------------------------------------------------- 1 | # NOTE协议用户白皮书 2 | 3 | ## 1. 简介 4 | 5 | 我们提出了一种新的NOTE协议，用于在分布式点对点互联网中保护隐私数据。该协议使用底层区块链将数据存储在有向图结构中。该协议利用BIP32标准确定私钥的生成规则，使用Electrum BIE1 ECIES算法对数据进行加密，指定了数据的存储格式，并实现了数据的增删改查和分享规则。 6 | 7 | 根据NOTE协议，您的信息安全不需要信任任何第三方。数据安全和存储安全得以实现，只有助记词持有人可以访问数据。数据不会保存在特定的第三方服务器或云服务上。 8 | 9 | 这是一个第二层解决方案，它建立在不可更改的Bitcoin协议和底层区块链的共识规则之上。 10 | 11 | 该协议支持同一个助记词账号的数据高并发上链，每一条记录使用无法预测的随机公私钥进行加密解密，支持多用户之间的加密数据分享等特性。 12 | 13 | ## 2. 准备知识 14 | ### 2.1 BIP32 15 | 16 | [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)定义了一套通过助记词派生私钥的算法。通过私钥可以获取对应的公钥和公钥哈希（即地址）。 17 | 18 | ### 2.2 Electrum BIE1 ECIES 19 | 20 | [Electrum BIE1 ECIES](https://github.com/benw46/BIE1)定义了如何使用椭圆曲线算法加密和解密数据。 21 | 22 | ### 2.3 Bitcom 23 | 24 | [Bitcom](https://bitcom.planaria.network/#/?id=bitcom)协议定义了每个账号的命名空间。 25 | 26 | ## 3. NOTE协议 27 | ### 3.1 派生索引和私钥派生路径 28 | 29 | 私钥派生路径定义如下： 30 | 31 | 32 | ```plain 33 | m/purpose'/coin_type'/account'/target/quotient/remainder 34 | ``` 35 | 其中 36 | 37 | ```plain 38 | purpose = 44 39 | coin_type=236 40 | account=0 41 | target=2 42 | ``` 43 | 随机生成一个64位数字作为派生索引，计算商和余数。索引需符合IEEE754标准，值应在1和2^53-1之间。 44 | 45 | ```javascript 46 | const Hardened = 0x80000000 47 | const quotient = Math.floor(index / Hardened) 48 | const remainder = index % Hardened 49 | ``` 50 | 完整的派生路径为： 51 | 52 | ```javascript 53 | const extPath = `m/44'/236'/0'/2/${quotient}/${remainder}` 54 | ``` 55 | ### 3.2 根私钥和根地址 56 | 57 | 根私钥基于以下路径派生 58 | 59 | ```javascript 60 | const extPath = `m/44'/236'/0'` 61 | ``` 62 | ### 3.3 存储格式 63 | 64 | 数据存储在OP_RETURN后面，分为四个部分： 65 | 66 | 67 | ```plain 68 | OP_FALSE OP_RETURN 根地址 派生索引 加密数据 签名 69 | ``` 70 | 其中 71 | 72 | 1. 根地址：根私钥生成 73 | 2. 派生索引：随机生成的64Bit数字 74 | 3. 加密数据：使用派生索引创建的密钥对，使用其中的公钥加密数据 75 | 4. 签名：使用根私钥对加密后的数据进行签名 76 | 77 | ### 3.4 签名 78 | 79 | 签名使用根私钥对加密数据的SHA256哈希进行签名。根地址公钥可以公开，任何人都可以用根地址公钥校验数据是否被伪造，以达到确权的目的。 80 | 81 | ```plain 82 | sign（sha256( encrypedNote )) 83 | ``` 84 | ### 3.5 数据格式 85 | 86 | 用户数据可以使用任意格式。数据经过使用Electrum BIE1 ECIES加密算法进行加密。 87 | 88 | 以下JSON格式定义属于NoteSV，这是一个密码管理软件。其他使用NOTE协议的软件可以自行定义： 89 | 90 | ```plain 91 | { 92 | id: 93 | tpl: 94 | ttl: 95 | mem: 96 | fid: 97 | pwd: 98 | url: 99 | otp: 100 | ptx: 101 | tags: [] 102 | files:[], 103 | tms 104 | } 105 | ``` 106 | 其中 107 | 108 | * id: 数据的主键 109 | * tpl: 内容模版 110 | * ttl: 标题 111 | * mem: 正文 112 | * fid: 用户名 113 | * pwd: 用户密码 114 | * url: 网站链接 115 | * otp: 一次性密码key 116 | * tags: 内容标签 117 | * files: 文件数组 118 | * del: 删除标志 119 | * ptx: 父内容的交易id 120 | * tms: Unix时间戳 121 | 122 | ## 4. 数据的创建更新与删除 123 | 124 | 数据创建时的id使用当前UNIX时间戳外加随机数的形式。这样做可以按照时间顺序排列id，并且可以避免多个同账号APP并发存储数据时产生冲突。 125 | 126 | 数据更新时不改变数据id，只改变其他字段。 127 | 128 | 数据删除时不改变数据id，只是将del字段设置为true。 129 | 130 | 131 | ## 5. 数据检索 132 | 133 | 数据存储中的根地址输入Bitcom协议，使用支持Bitcom协议的比特币数据服务商，可以检索到所有交易记录。 134 | 135 | 136 | ## 6. 数据分享 137 | 138 | 数据分享之前，需要获取对方的根公钥。存储格式为： 139 | 140 | 141 | ```plain 142 | OP_FALSE OP_RETURN 根地址 派生索引 加密数据 签名 143 | ``` 144 | 其中 145 | 146 | 1. 根地址：通过对方根公钥获取对方的根地址 147 | 2. 派生索引：设置为0 148 | 3. 加密数据：使用对方根公钥加密数据 149 | 4. 签名：使用己方根私钥对加密后的数据进行签名 150 | 151 | ## 7. 数据防伪 152 | ### 7.1 签名 153 | 154 | 所有数据均可使用根地址公钥校验，确定数据是拥有根地址的人创建的，或者由分享方创建。这步校验的理由是，创建数据的人知道了加密数据的公钥，伪造一条数据，但是不知道根地址的私钥，所以无法伪造签名。 155 | -------------------------------------------------------------------------------- /NOTE-Protocol-V1-English.md: -------------------------------------------------------------------------------- 1 | # NOTE Protocol User White Paper 2 | 3 | ## 1. Introduction 4 | 5 | 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. 6 | 7 | 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. 8 | 9 | This is a layer-2 solution, built on the immutable Bitcoin protocol and the consensus rule of the blockchain. 10 | 11 | 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. 12 | 13 | ## 2. Prerequisite Knowledge 14 | ### 2.1 BIP32 15 | 16 | [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 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. 17 | 18 | ### 2.2 Electrum BIE1 ECIES 19 | 20 | [Electrum BIE1 ECIES](https://github.com/benw46/BIE1) defines how to encrypt and decrypt data using the elliptic curve algorithm. 21 | 22 | ### 2.3 Bitcom 23 | 24 | [Bitcom](https://bitcom.planaria.network/#/?id=bitcom) protocol defines each account namespace. 25 | 26 | ## 3. NOTE Protocol 27 | ### 3.1 Derived Index and Private Key Derivation Path 28 | 29 | ```plain 30 | m/purpose'/coin_type'/account'/target/quotient/remainder 31 | ``` 32 | where: 33 | 34 | ```plain 35 | purpose = 44 36 | coin_type=236 37 | account=0 38 | target=2 39 | ``` 40 | 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. 41 | 42 | ```javascript 43 | const Hardened = 0x80000000 44 | const quotient = Math.floor(index / Hardened) 45 | const remainder = index % Hardened 46 | ``` 47 | The full derivation path is: 48 | ```javascript 49 | const extPath = `m/44'/236'/0'/2/${quotient}/${remainder}` 50 | ``` 51 | ### 3.2 Root Private Key and Root Address 52 | 53 | The root private key is derived based on the following path: 54 | 55 | ```javascript 56 | const extPath = `m/44'/236'/0'` 57 | ``` 58 | ### 3.3 Storage Format 59 | 60 | The data is stored as an OP_RETURN value and is divided into four parts: 61 | 62 | ```plain 63 | OP_FALSE OP_RETURN Root address, derived index, encrypted data, signature 64 | ``` 65 | where 66 | 67 | 1. Root address: generated by the root private key 68 | 2. Derived index: a randomly generated 64-bit number 69 | 3. Encrypts data: data encrypted using a key pair created with a derived index, using the public key 70 | 4. Signature: the encrypted data is signed using the root private key 71 | 72 | ### 3.4 Signature 73 | 74 | 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. 75 | 76 | ```plain 77 | sign（sha256( encrypedNote )) 78 | ``` 79 | ### 3.5 Data Format 80 | 81 | User data can be in any format. The data is encrypted using the Electrum BIE1 ECIES encryption algorithm. 82 | 83 | 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: 84 | 85 | 86 | ```plain 87 | { 88 | id: 89 | tpl: 90 | ttl: 91 | mem: 92 | fid: 93 | pwd: 94 | url: 95 | otp: 96 | ptx: 97 | tags: [] 98 | files:[], 99 | tms 100 | } 101 | ``` 102 | 103 | Where 104 | 105 | * id: main key 106 | * tpl: template 107 | * ttl: title 108 | * mem: content 109 | * fid: user name 110 | * pwd: user password 111 | * url: website link 112 | * otp: one-time password key 113 | * tags: tags/labels 114 | * files: attached files 115 | * del: delete flag 116 | * ptx: parent Tx ID 117 | * tms: Unix timestamp 118 | 119 | ## 4. Create, Update, and Delete Data 120 | 121 | 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. 122 | 123 | Data updates do not change the data id, only the other fields. 124 | 125 | The Data ID is not changed when the data is deleted, but the DEL field is set to true. 126 | 127 | 128 | ## 5. Data Fetching 129 | 130 | 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. 131 | 132 | 133 | ## 6. Data Sharing 134 | 135 | Before sharing the data, you need to get the other party’s root public key. The storage format is: 136 | 137 | 138 | ```plain 139 | OP_FALSE OP_RETURN Root address, derived index, encrypted data, signature 140 | ``` 141 | 142 | Where 143 | 144 | 1. Root address: get the root address of the other party through the public key 145 | 2. Derived index: set to 0 146 | 3. Encrypted data: encrypts data using the other party’s root public key 147 | 4. Signature: the encrypted data is signed using your own root private key 148 | 149 | ## 7. Data security 150 | ### 7.1 Signature 151 | 152 | 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. 153 | 154 | 155 | -------------------------------------------------------------------------------- /NOTE-Protocol-V2-Chinese.md: -------------------------------------------------------------------------------- 1 | # NOTE协议用户白皮书(draft) 2 | 3 | 4 | ## 1. 简介 5 | 6 | NOTE协议使基于比特币UTXO模型的区块链能够创建及管理数字资产。该协议支持强加密数据存储与通信，亦适用于公开透明的数据存储，包括Token与NFT等数字资产的所有权管理。 7 | 8 | 本协议基于BIP32标准，确定去中心化身份（DID）的生成规则。 9 | 10 | 针对加密数据，本协议采用DID规则，对每条记录以难以预测的随机公私钥加密解密，并使用Electrum BIE1 ECIES算法进行数据加密。 11 | 12 | 协议明确数据存储格式，并定义了数据的增删改查及分享规则。 13 | 14 | 信息安全无须依赖第三方信任，仅助记词持有者可访问数据，确保数据安全与存储安全。 15 | 16 | 利用链上智能合约进行比特币共识级别的资产校验，结合链下资产索引器，高效解读链上资产并提供资产的默克尔证明。 17 | 18 | 此为一种第二层解决方案，基于牢不可破的比特币协议及其底层区块链共识规则。本协议也为Layer 2网络奠定应用基础需求。 19 | 20 | 21 | ## 2. 协议解决的问题和方案 22 | 基于UTXO模型的区块链特点，本协议解决以下问题： 23 | - 去中心化身份（DID） 24 | - 数据格式 25 | - 数据存储位置 26 | - 数据所有权确认 27 | - 所有权转移 28 | - 链上合约 29 | - 数据解析 30 | - 数据索引 31 | - 资产创建 32 | - 资产挖掘 33 | - 资产转移 34 | - 资产销毁 35 | - 资产通知 36 | - 资产证明 37 | 38 | 设计过程中考虑了交易顺序，以避免双重支付、减少链上数据冗余，以及防止资产误消耗等问题。 39 | 40 | ### 2.2 去中心化ID 41 | 在用户的终端设备（如手机或电脑）上，基于BIP32协议派生账户公私钥和用于数据加密的私钥。这些私钥作为去中心化身份标识，使用公开的账户公钥来标识用户。在所有权确认、签名、数据创建和分享等所有场景中均使用此身份。 42 | 43 | ![DID](./did.png) 44 | 45 | #### 2.2.1 账号密钥 46 | 账号密钥基于以下路径派生： 47 | 48 | `m/purpose'/coin_type'/account'/target/index` 49 | 50 | 在NOTE.SV软件中使用了下面的变量 51 | ``` 52 | purpose = 44 53 | coin_type=236 54 | account=0 55 | target=0 56 | index=0 57 | ``` 58 | 完整的派生路径为： 59 | 60 | `m/44'/236'/0'/0/0` 61 | 62 | 顺序增加index可以创建多账号。 63 | 64 | #### 2.2.2 数据加密密钥的派生 65 | 数据加密密钥的派生路径定义如下： 66 | 67 | `m/purpose'/coin_type'/account'/target/quotient/remainder` 68 | 69 | 在NOTE.SV软件中，使用了以下变量： 70 | ``` 71 | purpose = 44 72 | coin_type = 236 73 | account = 0 74 | target = 2 75 | ``` 76 | 77 | 派生路径的生成步骤如下： 78 | 1. 随机生成一个64位整数 n。 79 | 2. 遵循IEEE754标准，对随机数取模 `n % (2^53-2) + 1`，生成派生索引。 80 | 3. 使用派生索引除以Hardened，获取商和余数。代码如下： 81 | ```typescript 82 | const Hardened = 0x80000000; 83 | const quotient = Math.floor(index / Hardened); 84 | const remainder = index % Hardened; 85 | ``` 86 | 完整的派生路径为： 87 | 88 | `m/44'/236'/0'/2/${quotient}/${remainder}` 89 | 90 | ### 2.3 数据的格式和顺序 91 | 链上数据的格式和顺序规定如下： 92 | - 公钥HASH：持有者的账号公钥的HASH160。 93 | - 明文HASH： 94 | - 如果是加密信息，则为明文的SHA256值。 95 | - 如果是公开数据，则为0x00。 96 | - 数据：明文或密文。数据可为加密或公开数据。原始数据使用[Msgpack](https://msgpack.org/)协议编码，需排序键值（sortKeys=true）。 97 | - 签名：使用持有者账号私钥对明文HASH进行的签名。签名可通过持有者账号公钥验证。签名算法采用Bitcoin Message标准。如果可以提供交易的公钥签名，此处为0x00；否则必须有签名。 98 | - 附加信息：描述数据的表现形式 99 | - 1字节的整数0x00，表示数据使用了持有者的账号公钥加密。 100 | - 1字节的整数0xff，表示数据未加密。 101 | - 8字节的整数，范围：1～2^53 - 1，表示数据使用了数据加密公钥加密。 102 | - NOTE：全大写，固定的协议标识符。 103 | 104 | 105 | ![Data](./data_zh.png) 106 | 107 | ### 2.4 存储位置 108 | 数据需放置在交易的解锁脚本中。在解锁过程中，矿工将对交易签名和其他解锁条件进行校验。同时，输出部分也需要有相应的脚本输出，以形成交易链条。索引器会根据区块和UTXO交易链确定交易的执行顺序，并据此验证资产交易的有效性。此类解锁签名的flag设置为 SINGLE | ANYONECANPAY。 109 | 本协议采用非标准脚本，与P2PKH等标准脚本不同，从而避免UTXO被误消费的情况。 110 | 本协议所使用的最简单比特币脚本示例如下。 111 | 112 | #### 2.4.1 非标脚本 113 | 非标脚本按照以下格式定义： 114 | 115 | ``` 116 | 解锁脚本：交易签名 公钥HASH 明文数据Hash 数据 数据签名 附加信息 117 | 锁定脚本：NOTE OP_2DROP OP_2DROP OP_2DROP 原公钥 OP_CHECKSIG 118 | 交易输出：NOTE OP_2DROP OP_2DROP OP_2DROP 新公钥 OP_CHECKSIG 119 | ``` 120 | 121 | #### 2.4.2 使用P2WSH 122 | 在支持P2WSH的区块链中，格式定义如下： 123 | ``` 124 | 解锁脚本：交易签名 公钥HASH 明文数据Hash 数据 数据签名 附加信息 125 | 锁定脚本：NOTE OP_2DROP OP_2DROP OP_2DROP 原公钥 OP_CHECKSIG 126 | 输出脚本：NOTE OP_2DROP OP_2DROP OP_2DROP 新公钥 OP_CHECKSIG 127 | 脚本地址：赎回脚本的HASH地址 128 | ``` 129 | 数据信息被保存在隔离见证数据区中。 130 | 131 | #### 2.4.3 使用P2TR 132 | 类似于P2WSH，赎回脚本作为MAST的一个解锁分支。由包含数据解锁脚本提供解锁。 133 | 在支持P2TR的区块链中，格式定义如下： 134 | 135 | ``` 136 | 解锁脚本：交易签名 公钥HASH 明文数据Hash 数据 数据签名 附加信息 137 | 锁定分支脚本：NOTE OP_2DROP OP_2DROP OP_2DROP 公钥 OP_CHECKSIG 138 | 输出分支脚本：NOTE OP_2DROP OP_2DROP OP_2DROP 公钥 OP_CHECKSIG 139 | 交易输出：Taproot地址输出 140 | ``` 141 | 解锁脚本信息保存在隔离见证数据区中。 142 | 143 | > 建议使用非标脚本和P2WSH以获取更清晰的语义。P2TR MAST可实现更复杂的交易逻辑，但可能导致索引器设计更为复杂。 144 | 145 | ### 2.5 链上合约 146 | 通过更复杂的锁定脚本，可以创建链上智能合约，使得只有符合合约条件的交易才能被确认上链。以下是一个简单示例：该脚本要求，除了签名外，还必须提供特定的消息（message），才能发起交易并使信息成功上链。 147 | 148 | ```typescript 149 | class Scryptdemo extends SmartContract { 150 | @prop() 151 | static note: ByteString = toByteString('NOTE', true) 152 | 153 | @prop() 154 | pubKey: PubKey 155 | 156 | @prop() 157 | hash: ByteString 158 | 159 | constructor(hash: Sha256) { 160 | super(...arguments) 161 | this.hash = hash 162 | } 163 | 164 | @method() 165 | public unlock( 166 | sig: Sig, 167 | message: ByteString, 168 | owner: ByteString, 169 | plainHash: ByteString, 170 | data: ByteString, 171 | hashSig: ByteString, 172 | extra: bigint 173 | ) { 174 | Scryptdemo.note 175 | // owner 176 | // plainHash 177 | // data 178 | // hashSig 179 | // extra 180 | assert(sha256(message) == this.hash, 'Hash does not match') 181 | assert(this.checkSig(sig, this.pubKey), 'signature check failed') 182 | } 183 | } 184 | ``` 185 | 186 | 编译后的脚本为 187 | ``` 188 | 044e4f544500006175615279755879a85179876959795279ac77777777777777777777 189 | ``` 190 | ASM: 191 | ```typescript 192 | 4e4f5445 0 0 OP_NOP OP_DROP OP_NOP OP_2 OP_PICK OP_DROP OP_8 OP_PICK OP_SHA256 OP_1 OP_PICK OP_EQUAL OP_VERIFY OP_9 OP_PICK OP_2 OP_PICK OP_CHECKSIG OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP 193 | ``` 194 | 195 | > 示例合约使用[Scrypt](https://Scrypt.io)制作。 196 | 197 | 无论是最简单的合约还是更复杂的合约，在由解锁脚本和锁定脚本构成的交易脚本中，数据的格式和顺序都必须遵循本协议的规定。由于支持智能合约，链上Oracle和Swap等功能也将成为可能。 198 | 199 | ### 2.6 数据所有权确认 200 | 数据上链必须通过花费符合本协议规定的UTXO来完成交易签名或数据签名。链上矿工以及链下索引和钱包通过检查签名来确认数据所有权。UTXO链保证交易顺序，防止双重支付。数据签名和交易签名的二选一机制允许第三方代付交易费用。如果未提供数据签名，则交易签名者被视为数据的持有者。 201 | 数据所有权可通过以下步骤确认： 202 | 1. 如果存在数据签名，首先检查持有者的数据签名，提取公钥，并与持有者的公钥HASH一起验证。如果验证通过，则所有权归公钥持有者。如果验证不通过，则该交易为非法交易。 203 | 2. 如果未提供数据签名，则提供交易解锁的公钥即为数据所有者。 204 | 205 | ### 2.7 所有权的转移 206 | 207 | #### 2.7.1 提供数据签名时 208 | 1. 获取接收方的公钥。 209 | 2. 计算接收方公钥的HASH。 210 | 3. 使用发送方的账户私钥进行签名。 211 | 4. 代付方或发送方使用私钥签名交易。 212 | 213 | #### 2.7.2 未提供数据签名时 214 | 1. 获取接收方的公钥。 215 | 2. 将交易输出到对方的公钥脚本或公钥脚本的HASH。 216 | 3. 将接收方的HASH数据设置为0x00，以节约交易空间。 217 | 4. 发送方使用私钥签署交易。 218 | 219 | ### 2.8 数据解析 220 | 交易发布到区块链后，数据索引器对交易进行解析，检查签名以确认所有权是否符合协议，并解析数据内容以确定其有效性。不符合规定的交易将被丢弃。大量的非合规交易可通过垃圾邮件过滤器标记发起方。 221 | 222 | ## 3. 加密数据 223 | ### 3.1 数据的创建 224 | 加密数据的创建过程如下： 225 | 1. 准备明文数据内容。 226 | 2. 使用msgpack对数据进行打包。 227 | 3. 获取打包数据的SHA256 HASH。 228 | 4. 生成随机数，创建派生索引，并根据索引派生出加密私钥。 229 | 5. 使用派生出的公钥对数据进行加密。 230 | 6. 使用账户私钥对加密后的数据进行Bitcoin Message签名。 231 | 7. 构建数据脚本。 232 | 8. 构造交易并广播。 233 | 234 | ### 3.2 数据签名加密数据的分享 235 | 加密数据转让时的步骤： 236 | 1. 转让加密数据时，设置附加数据为0。 237 | 2. 获取交易对方的公钥。 238 | 3. 使用对方公钥加密数据。 239 | 4. 使用自己的根私钥进行签名。由于从签名中可以提取出公钥，因此可以确认自身身份。 240 | 5. 设置交易对方的公钥HASH。 241 | 6. 接收方在解密数据后可以验证明文的Hash256。 242 | 243 | `接收方公钥HASH 明文Hash 加密数据 持有者的数据签名 00 NOTE` 244 | 245 | 246 | ## 4. NFT 247 | 由于比特币区块链的愿景和技术限制，本协议不要求也不建议将大量数据存储在区块链上。只需将数据的HASH上链，数据本身可以存储在其他去中心化或中心化系统中。 248 | 249 | ## 5. Token 250 | TODO 251 | 252 | ## 6. 数据索引 253 | TODO 254 | 255 | ## 6.1 资产证明 256 | TODO 257 | 258 | 259 | ## 7. 参考 260 | 感谢以下列出及未列出的所有个人和团队对比特币的贡献，他们的文章和代码给予了我们极大的启发。 261 | 262 | ### 比特币 263 | [白皮书](https://bitcoin.org/bitcoin.pdf) - 牢不可破的比特币协议。 264 | 265 | ### BIP32 266 | [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 定义了一套通过助记词派生私钥的算法，可用于获取相应的公钥和公钥哈希（即地址）。 267 | 268 | ### Electrum BIE1 ECIES 269 | [Electrum BIE1 ECIES](https://github.com/benw46/BIE1) 定义了使用椭圆曲线算法进行数据加密和解密的方法。 270 | 271 | ### Paymail 272 | [Paymail](https://bsvalias.org/) 启发了我们的DID设计。 273 | 274 | ### Ordinals 275 | [Ordinals](https://docs.ordinals.com/) 促使我们升级协议。 276 | 277 | ### BRC-20 278 | [BRC-20](https://domo-2.gitbook.io/brc-20-experiment/) 对标准数据格式提出了建议。 279 | 280 | ### Atomicals 281 | [Atomicals](https://docs.atomicals.xyz/) 帮助我们更好地理解需求。 282 | 283 | ### Scrypt 284 | [Scrypt](https://Scrypt.io) 带来比特币智能合约 285 | 286 | ### Msgpack 287 | [Msgpack](https://msgpack.org/) 节省每一个字节 288 | 289 | 290 | 291 | -------------------------------------------------------------------------------- /NOTE-Protocol-V2-English.md: -------------------------------------------------------------------------------- 1 | # NOTE Protocol(draft) 2 | 3 | ## 1. Introduction 4 | 5 | The NOTE protocol enables blockchain systems based on the Bitcoin UTXO model to create and manage digital assets. This protocol supports secure encrypted data storage and communication, and is also applicable to public and transparent data storage, including the management of ownership rights for digital assets such as Tokens and NFTs. 6 | 7 | This protocol is grounded in the BIP32 standard to determine the generation rules for Decentralized Identities (DID). 8 | 9 | For encrypted data, the protocol employs DID rules. Each record is encrypted and decrypted with unpredictable random public and private keys, using the Electrum BIE1 ECIES algorithm for data encryption. 10 | 11 | The protocol specifies the data storage format and defines the rules for data creation, deletion, modification, retrieval, and sharing. 12 | 13 | Information security does not rely on third-party trust; only the holders of mnemonic phrases can access the data, ensuring both data and storage security. 14 | 15 | Utilizing on-chain smart contracts for Bitcoin consensus-level asset verification, combined with off-chain asset indexers, the protocol efficiently interprets on-chain assets and provides Merkle proofs for these assets. 16 | 17 | This is a second-layer solution built upon the unshakeable Bitcoin protocol and its underlying blockchain consensus rules. The protocol also lays the foundational application requirements for Layer 2 networks. 18 | 19 | ## 2. Problems Solved and Solutions by the Protocol 20 | Based on the characteristics of blockchains using the UTXO model, this protocol addresses the following issues: 21 | - Decentralized Identity (DID) 22 | - Data Format 23 | - Data Storage Location 24 | - Confirmation of Data Ownership 25 | - Transfer of Ownership 26 | - On-chain Contracts 27 | - Data Parsing 28 | - Data Indexing 29 | - Asset Creation 30 | - Asset Mining 31 | - Asset Transfer 32 | - Asset Destruction 33 | - Asset Notification 34 | - Asset Proof 35 | 36 | During the design process, considerations were made for transaction sequencing to prevent double spending, reduce data redundancy on the blockchain, and avoid accidental asset consumption. 37 | 38 | ### 2.1 System Relationship Diagram 39 | As shown in the diagram below, asset private keys are generated and stored in user wallets or related software. Once data asset transactions are broadcasted to the blockchain, the blockchain ensures transparency of information and its irreversibility, clearly defining the timing and sequence of transactions, and verifying ownership signatures through on-chain smart contracts. Data indexers and validators are responsible for interpreting transaction data, executing off-chain smart contracts, and providing Merkle proofs of assets. Data indexers will evolve into a Layer 2 network with a consensus mechanism. 40 | 41 | ![Arch](./arch.png) 42 | 43 | 44 | ### 2.2 Decentralized ID 45 | On users' end devices (such as mobile phones or computers), account public and private keys, along with private keys for data encryption, are derived based on the BIP32 protocol. Serving as decentralized identities, these keys utilize the publicly accessible account public key for user identification. This identity is used in all scenarios including ownership confirmation, signing, data creation, and sharing. 46 | 47 | 48 | ![DID](./did.png) 49 | 50 | #### 2.2.1 Account Keys 51 | Account keys are derived following this path: 52 | 53 | 54 | `m/purpose'/coin_type'/account'/target/index` 55 | 56 | In the NOTE.SV software, the following variables are used: 57 | 58 | ``` 59 | purpose = 44 60 | coin_type=236 61 | account=0 62 | target=0 63 | index=0 64 | ``` 65 | Thus, the complete derivation path is: 66 | 67 | `m/44'/236'/0'/0/0` 68 | 69 | By sequentially increasing the index, multiple accounts can be created. 70 | 71 | #### 2.2.2 Derivation of Data Encryption Keys 72 | The derivation path for data encryption keys is defined as follows: 73 | 74 | `m/purpose'/coin_type'/account'/target/quotient/remainder` 75 | 76 | In the NOTE.SV software, the following variables are used: 77 | ``` 78 | purpose = 44 79 | coin_type = 236 80 | account = 0 81 | target = 2 82 | ``` 83 | 84 | The steps for generating the derivation path are as follows: 85 | 1. Randomly generate a 64-bit integer n. 86 | 2. Following the IEEE754 standard, modulate the random number `n % (2^53-2) + 1` to generate the derivation index. 87 | 3. Divide the derivation index by Hardened to obtain the quotient and remainder. The code is as follows: 88 | ```typescript 89 | const Hardened = 0x80000000; 90 | const quotient = Math.floor(index / Hardened); 91 | const remainder = index % Hardened; 92 | ``` 93 | The complete derivation path is: 94 | 95 | `m/44'/236'/0'/2/${quotient}/${remainder}` 96 | 97 | ### 2.3 Data Format and Order 98 | The format and order of data on the blockchain are stipulated as follows: 99 | - Public Key HASH: The HASH160 of the holder's account public key. 100 | - Plaintext HASH: 101 | - If it is encrypted information, then it is the SHA256 value of the plaintext. 102 | - If it is public data, then it is 0x00. 103 | - Data: Plaintext or ciphertext. Data can be either encrypted or public. Original data should be encoded using the [Msgpack](https://msgpack.org/) protocol with sorted keys (sortKeys=true). 104 | - Signature: A signature made using the holder's account private key on the plaintext HASH. This signature can be verified using the holder's account public key. The signature algorithm uses the Bitcoin Message standard. If a public key signature for the transaction can be provided, this field is 0x00; otherwise, a signature is required. 105 | - Additional Information: Describes the data representation form 106 | - A 1-byte integer 0x00, indicating the data is encrypted using the holder's account public key. 107 | - A 1-byte integer 0xff, indicating the data is unencrypted. 108 | - An 8-byte integer, range: 1 to 2^53 - 1, indicating the data is encrypted using the data encryption public key. 109 | - NOTE: All uppercase, fixed protocol identifier. 110 | 111 | 112 | ![Data](./data_en.png) 113 | 114 | ### 2.4 Storage Location 115 | Data is required to be placed in the unlocking script of a transaction. During the unlocking process, miners verify the transaction signature and other unlocking conditions. At the same time, it is required that the output section includes a corresponding script output to form a transaction chain. Indexers will determine the execution order of transactions based on the block and UTXO transaction chain, thereby verifying the validity of asset transactions. The unlocking signature flag for this type of transaction is set to SINGLE | ANYONECANPAY. 116 | This protocol uses non-standard scripts, which, unlike standard scripts such as P2PKH, prevent the accidental consumption of UTXOs. 117 | An example of the simplest Bitcoin script used in this protocol is as follows. 118 | 119 | #### 2.4.1 Non-standard Scripts 120 | Non-standard scripts are defined in the following format: 121 | 122 | ``` 123 | Unlocking Script: Transaction Signature, Public Key HASH, Plaintext Data Hash, Data, Data Signature, Additional Information. 124 | Locking Script: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, Original Public Key, OP_CHECKSIG. 125 | Transaction Output: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, New Public Key, OP_CHECKSIG. 126 | 127 | ``` 128 | 129 | #### 2.4.2 Using P2WSH 130 | In blockchains supporting P2WSH, the format is defined as follows: 131 | 132 | ``` 133 | Unlocking Script: Transaction Signature, Public Key HASH, Plaintext Data Hash, Data, Data Signature, Additional Information. 134 | Locking Script: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, Original Public Key, OP_CHECKSIG. 135 | Output Script: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, New Public Key, OP_CHECKSIG. 136 | Script Address: HASH address of the redemption script. 137 | ``` 138 | Data information is stored in the segregated witness data area. 139 | 140 | #### 2.4.3 Using P2TR 141 | Similar to P2WSH, the redemption script serves as an unlocking branch of MAST, unlocked by a script containing data unlocking instructions. 142 | In blockchains supporting P2TR, the format is defined as follows: 143 | 144 | ``` 145 | Unlocking Script: Transaction Signature, Public Key HASH, Plaintext Data Hash, Data, Data Signature, Additional Information. 146 | Locking Branch Script: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, Public Key, OP_CHECKSIG. 147 | Output Branch Script: NOTE, OP_2DROP, OP_2DROP, OP_2DROP, Public Key, OP_CHECKSIG. 148 | Transaction Output: Taproot address output. 149 | ``` 150 | Unlocking script information is stored in the segregated witness data area. 151 | 152 | 153 | Using non-standard scripts and P2WSH is recommended for clearer semantics. P2TR MAST can provide more complex transaction logic but may lead to more complex indexer designs. 154 | 155 | ### 2.5 On-Chain Contracts 156 | More complex locking scripts can be used to create on-chain smart contracts, ensuring that only transactions meeting the contract's conditions can be confirmed on the blockchain. Below is a simple example: This script requires that, in addition to a signature, a specific message must be provided in order to initiate a transaction and successfully record the information on the blockchain. 157 | 158 | 159 | ```typescript 160 | class Scryptdemo extends SmartContract { 161 | @prop() 162 | static note: ByteString = toByteString('NOTE', true) 163 | 164 | @prop() 165 | pubKey: PubKey 166 | 167 | @prop() 168 | hash: ByteString 169 | 170 | constructor(hash: Sha256) { 171 | super(...arguments) 172 | this.hash = hash 173 | } 174 | 175 | @method() 176 | public unlock( 177 | sig: Sig, 178 | message: ByteString, 179 | owner: ByteString, 180 | plainHash: ByteString, 181 | data: ByteString, 182 | hashSig: ByteString, 183 | extra: bigint 184 | ) { 185 | Scryptdemo.note 186 | // owner 187 | // plainHash 188 | // data 189 | // hashSig 190 | // extra 191 | assert(sha256(message) == this.hash, 'Hash does not match') 192 | assert(this.checkSig(sig, this.pubKey), 'signature check failed') 193 | } 194 | } 195 | ``` 196 | The compiled script is 197 | ``` 198 | 044e4f544500006175615279755879a85179876959795279ac77777777777777777777 199 | ``` 200 | ASM: 201 | ```typescript 202 | 4e4f5445 0 0 OP_NOP OP_DROP OP_NOP OP_2 OP_PICK OP_DROP OP_8 OP_PICK OP_SHA256 OP_1 OP_PICK OP_EQUAL OP_VERIFY OP_9 OP_PICK OP_2 OP_PICK OP_CHECKSIG OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP 203 | ``` 204 | 205 | > The example contract is created using [Scrypt](https://Scrypt.io). 206 | 207 | Whether it's the simplest contract or more complex ones, in the transaction script formed by the unlocking and locking scripts, the format and order of data must comply with the regulations of this protocol. With support for smart contracts, functionalities like on-chain Oracles and Swaps will also become possible. 208 | 209 | 210 | ### 2.6 Data Ownership Confirmation 211 | To record data on the blockchain, it must be done by spending a UTXO defined by this protocol and completing either a transaction signature or a data signature. On-chain miners and off-chain indexers and wallets confirm data ownership by checking the signature. The UTXO chain ensures the order of transactions, preventing double-spending. The option to choose between a data signature and a transaction signature allows third parties to pay transaction fees. If no data signature is provided, the signer of the transaction is considered the data owner. 212 | Data ownership can be confirmed by the following steps: 213 | 214 | 1. If a data signature exists, first check the holder's data signature, extract the public key, and verify it together with the holder's public key HASH. If the verification passes, the ownership belongs to the public key holder. If not, the transaction is deemed illegal. 215 | 216 | 2. If no data signature is provided, the public key used to unlock the transaction is considered the data owner. 217 | 218 | ### 2.7 Transfer of Ownership 219 | #### 2.7.1 When Providing a Data Signature 220 | 1. Obtain the recipient's public key. 221 | 2. Calculate the HASH of the recipient's public key. 222 | 3. Sign using the sender's account private key. 223 | 4. The payer or sender signs the transaction with their private key. 224 | 225 | #### 2.7.2 When No Data Signature is Provided 226 | 1. Obtain the recipient's public key. 227 | 2. Direct the transaction output to the recipient's public key script or the HASH of the public key script. 228 | 3. Set the recipient's HASH data to 0x00 to save transaction space. 229 | 4. The sender signs the transaction using their private key. 230 | 231 | ### 2.8 Data Parsing 232 | After a transaction is published to the blockchain, data indexers parse the transaction, checking the signatures to ensure ownership complies with the protocol, and analyzing the data content to determine its validity. Non-compliant transactions will be discarded. A large volume of non-compliant transactions can be flagged by spam filters. 233 | 234 | ## 3. Encrypted Data 235 | ### 3.1 Creation of Data 236 | The creation of encrypted data follows these steps: 237 | 1. Prepare plaintext data content. 238 | 2. Package the data using msgpack. 239 | 3. Obtain the SHA256 HASH of the packaged data. 240 | 4. Generate a random number, create a derivation index, and derive an encryption private key based on the index. 241 | 5. Encrypt the data using the derived public key. 242 | 6. Sign the encrypted data using the account private key with a Bitcoin Message signature. 243 | 7. Construct the data script. 244 | 8. Construct and broadcast the transaction. 245 | 246 | ### 3.2 Sharing of Signed Encrypted Data 247 | When transferring encrypted data, follow these steps: 248 | 1. Set the additional data to 0 when transferring encrypted data. 249 | 2. Obtain the public key of the counterparty. 250 | 3. Encrypt the data using the counterparty's public key. 251 | 4. Sign with your own root private key. Since the public key can be extracted from the signature, it confirms your identity. 252 | 5. Set the counterparty's public key HASH. 253 | 6. The recipient can verify the plaintext Hash256 after decrypting the data. 254 | 255 | `Pubkeyhash PlaintextHash EncryptedData Signature 00 NOTE` 256 | 257 | ## 4. NFT 258 | Due to the vision and technical limitations of the Bitcoin blockchain, this protocol does not require nor recommend storing a large amount of NFT data on the blockchain. It is sufficient to record only the HASH of the NFT data on the chain, with the actual data being stored in other decentralized or centralized systems. 259 | 260 | ## 5. Token 261 | TODO 262 | 263 | ## 6. Data Indexing 264 | TODO 265 | 266 | ### 6.1 Asset Proof 267 | TODO 268 | 269 | ## 7. References 270 | Special thanks to the following individuals and teams, listed and unlisted, for their contributions to Bitcoin. Their articles and code have provided us with much inspiration. 271 | 272 | ### Bitcoin 273 | 274 | [White Paper](https://bitcoin.org/bitcoin.pdf) - The unshakeable Bitcoin protocol. 275 | 276 | ### BIP32 277 | 278 | [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) defines a set of algorithms for deriving private keys from mnemonic phrases. Through private keys, corresponding public keys and public key hashes (i.e., addresses) can be obtained. 279 | 280 | ### Electrum BIE1 ECIES 281 | 282 | [Electrum BIE1 ECIES](https://github.com/benw46/BIE1) defines how to encrypt and decrypt data using elliptic curve algorithms. 283 | 284 | ### Paymail 285 | [Paymail](https://bsvalias.org/) inspired the design of DID. 286 | 287 | ### Ordinals 288 | [Ordinals](https://docs.ordinals.com/) prompted us to upgrade the protocol. 289 | 290 | ### BRC-20 291 | [BRC-20](https://domo-2.gitbook.io/brc-20-experiment/) suggestions for standard data formats. 292 | 293 | ### Atomicals 294 | [Atomicals](https://docs.atomicals.xyz/) helped us better understand the requirements. 295 | 296 | ### Scrypt 297 | [Scrypt](https://Scrypt.io) Smart Contract for Bitcoin 298 | 299 | ### Msgpack 300 | [Msgpack](https://msgpack.org/) Save every byte. 301 | 302 | 303 | --------------------------------------------------------------------------------