idnits 2.17.1 draft-nakajima-crypto-asset-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 31, 2018) is 1935 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 310 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Nakajima 3 Internet-Draft Mercari R4D 4 Intended status: Informational M. Kusunoki 5 Expires: July 4, 2019 JDD 6 K. Hida 7 JBA 8 Y. Suga 9 Advanced Security Div, IIJ 10 T. Hayashi 11 Lepidum 12 December 31, 2018 14 Terminology for Cryptoassets 15 draft-nakajima-crypto-asset-terminology-01 17 Abstract 19 This document provides terminology used in cryptoassets. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 4, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 57 3. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 58 4. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Our goal with this document is to improve our understanding on a set 70 of terms which frequently used in documents which related to 71 cryptoassets. Mutual understanding about terminology may help to 72 reach a consensus on issues we're trying to solve. 74 2. Conventions and Definitions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in BCP 79 14 [RFC2119] [RFC8174] when, and only when, they appear in all 80 capitals, as shown here. 82 3. Terms and Definitions 84 address: An identifier to represent a public key in a blockchain 85 network. 87 administrator: It is a person who conducts operational maintenance 88 of the system with authority to change system setting. From the 89 viewpoint of mutual checking, there are administrators with 90 different authorities depending on the subjects to be managed. 92 asymmetric cryptography: Defined in [RFC4949] as "A modern branch of 93 cryptography (popularly known as "public-key cryptography") in 94 which the algorithms use a pair of keys (a public key and a 95 private key) and use a different component of the pair for each of 96 two counterpart cryptographic operations (e.g., encryption and 97 decryption, or signature creation and signature verification). " 99 block: A basic unit of the blockchain. A set of transactions on a 100 blockchain which contains a cryptographic hash value of previous 101 block. 103 blockchain: A digital ledger about transactions for cryptoassets. 105 confirmation: (For transactions,) checking correctness of a 106 transaction in the mainchain. 108 consensus: Coincidence the way of thinking. 110 cryptoassets: Cryptographically guaranteed value. 112 deterministic wallet: See: wallet 114 digital signature: Defined in [RFC4949] as "A value computed with a 115 cryptographic algorithm and associated with a data object in such 116 a way that any recipient of the data can use the signature to 117 verify the data's origin and integrity." 119 distributed ledger: A distributed database about cryptoassets with 120 agreed processed. 122 double spending: Defined in [MasteringBitcoinOnline] as "result of 123 successfully spending some money more than once." 125 fiat money: Currency which has been established by government or 126 other authorities. 128 fork: A fork is a branch of a ledger. Ledger branching may occur 129 accidentally or by specification changes. 131 accidental fork: An accidental fork is a case where a block is 132 accidentally mined at about the same time, and a plurality of 133 chains coexist temporarily. It occurs on a daily basis and 134 converges to the longest chain by re-org. 136 soft fork: A soft fork may influence the implementation of a miner 137 in branches caused by specification change of block chain, but 138 does not affect wallet implementation. 140 hard fork: A hard fork is a branch caused by a specification change 141 without forward compatibility of the block chain, which may affect 142 the wallet implementation in addition to the miner. There is a 143 case where a plurality of chains continue to coexist permanently 144 because there is no consensus between developers regarding the 145 case where the majority of nodes stay in the specification change 146 by following the hard fork, We call it split. Examples of typical 147 splits include the division of Ethereum and Ethereum Classic in 148 the The DAO case of 2016, the division of Bitcoin and Bitcoin Cash 149 in 2017, and so on. The new coin born by division is called a 150 fork coin. 152 genesis block: An initial block on a blockchain. Genesis block may 153 differ to distinguish chains. 155 hash value: Defined in [RFC4949] as "The output of a hash function." 157 hash rate: Amount of a hash value which node is able to generate per 158 unit of time (generally per second) 160 hierarchy deterministic wallet: See: wallet 162 mining: A process to append a received transaction to a block by 163 validating a transaction with agreed consensus rules such as 164 proof-of-work and proof-of-stake. Miner is a network node which 165 contributes its resources to mining. 167 miner: See: mining 169 multisignature: Defined in [MasteringBitcoinOnline] as "requiring 170 more than one key to authorize a bitcoin transaction". In this 171 scope, transaction is not limited to bitcoin transaction. 173 node: A device that connects to blockchain network. 175 off-chain transaction: The movement of value outside of the 176 blockchain 178 on-chain transaction: The movement of value on the blockchain 180 operator: It is a person who performs routine tasks based on 181 authority as a normal task. 183 orphan block: Defined in [MasteringBitcoinOnline] as "Blocks whose 184 parent block has not been processed by the local node, so they 185 can't be fully validated yet." 187 permissioned-chain: A public blockchain that only specified members 188 can join the blockchain network. 190 permissionless-chain: See: permissioned-chain 191 public-chain: An open blockchain that anyone can retrieve all of 192 blocks and transactions without special privileges. 194 public key: Defined in [RFC4949] as "The publicly disclosable 195 component of a pair of cryptographic keys used for asymmetric 196 cryptography." 198 private-chain: In contrast with "public-chain", A closed blockchain 199 that only permissioned users can access blocks and make 200 transactions. 202 private key: Defined in [RFC4949] as "The secret component of a pair 203 of cryptographic keys used for asymmetric cryptography." 205 proof-of-stake: Defined in [MasteringBitcoinOnline] as "method by 206 which a cryptocurrency blockchain network aims to achieve 207 distributed consensus." 209 proof-of-work: Defined in [MasteringBitcoinOnline] as "A piece of 210 data that requires significant computation to find." 212 reorganization: Invalidation process of branched blockchains. 214 reward: Value by the blockchain network which assigned to a miner 215 who successfully validates a transaction. Rules may differ among 216 blockchains and consensus rules. 218 side-chain: See off-chain 220 smart contract: A guaranteed digital procedure that automatically 221 enforced on a blockchain network. 223 soft fork: See: fork 225 token: An unforgeable data object. 227 transaction: Defined in [MasteringBitcoinOnline] as "More precisely, 228 a transaction is a signed data structure expressing a transfer of 229 value." 231 validation: Checking correctness and consistency of given data. 233 validated: See: validation 235 validator: See: validation 237 wallet: A wallet is an implementation that handles a key pair of a 238 public key and a secret key used for transmitting a virtual 239 currency and such a key pair. In this document, the latter is 240 distinguished and called wallet implementation. 242 hot wallet: It is a wallet that is online connected to the network, 243 the key is activated, and you can coin out the virtual currency by 244 automatic processing. 246 cold wallet: Normally it is disconnected from the network and the 247 key is inactivated and it is a wallet that can not be coined out 248 unless there is an explicit operation by the operator. Frequency 249 of outgoing coins is limited. 251 Between Hot Wallet and Cold Wallet, there are various intermediate 252 forms such as wallet that is online, but requires manual operation 253 at the time of signing a transaction, wallet that is offline but 254 operation is automated, and warm wallet There are also sometimes 255 called. 257 4. Symbols and abbreviated terms 259 AML Anti-Money Laundering 261 API: Application Programming Interface 263 CFT: Counter Financing of Terrorism 265 DAO: Distributed Autonomous Organization 267 DLT: Distributed Ledger Technologies 269 HD: Hierarchy Deterministic (wallet) 271 PKI: Public Key Infrastructure 273 5. Security Considerations 275 This document defines terminology for cryptoassets. Therefore, there 276 is no security considerations. 278 6. IANA Considerations 280 None. 282 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 7.2. Informative References 296 [MasteringBitcoinOnline] 297 Antonopoulos, A., "Mastering Bitcoin", March 2018, 298 . 300 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 301 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 302 . 304 7.3. URIs 306 [1] https://vcgtf.github.io/ 308 Acknowledgments 310 Thanks to members of the Cryptoassets Governance Task Force [1] for 311 help and feedback. 313 Authors' Addresses 315 Hirotaka Nakajima 316 Mercari, Inc. R4D 317 Roppongi Hills Mori Tower 25F 318 6-10-1 Roppongi 319 Minato, Tokyo 106-6125 320 JAPAN 322 Email: nunnun@mercari.com 323 Masanori Kusunoki 324 Japan Digital Design, Inc. 325 Nihonbashi Talk Building 326 3-3-5, Nihonbashi-Hongokucho 327 103-0021 328 JAPAN 330 Email: masanori.kusunoki@japan-d2.com 332 Keiichi Hida 333 Japan Blockchain Association 335 Email: hida@jba-web.jp 337 Yuji Suga 338 Advanced Security Division, Internet Initiative Japan Inc. 339 Iidabashi Grand Bloom, 340 2-10-2 Fujimi 341 Chiyoda, Tokyo 102-0071 342 JAPAN 344 Email: suga@iij.ad.jp 346 Tatsuya HAYASHI 347 Lepidum Co. Ltd. 349 Email: hayashi@lepidum.co.jp