idnits 2.17.1 draft-nakajima-crypto-asset-terminology-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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, 2019) is 1575 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 317 Summary: 1 error (**), 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 2, 2020 JDD 6 K. Hida 7 JBA 8 Y. Suga 9 Advanced Security Div, IIJ 10 T. Hayashi 11 Lepidum 12 December 31, 2019 14 Terminology for Cryptoassets 15 draft-nakajima-crypto-asset-terminology-03 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 2, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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. 91 See also: operator. 93 asymmetric cryptography: Defined in [RFC4949] as "A modern branch of 94 cryptography (popularly known as "public-key cryptography") in 95 which the algorithms use a pair of keys (a public key and a 96 private key) and use a different component of the pair for each of 97 two counterpart cryptographic operations (e.g., encryption and 98 decryption, or signature creation and signature verification). " 100 block: A basic unit of the blockchain. A set of transactions on a 101 blockchain which contains a cryptographic hash value of previous 102 block. 104 blockchain: A digital ledger about transactions for cryptoassets. 106 confirmation: (For transactions,) checking correctness of a 107 transaction in the mainchain. 109 consensus: Coincidence the way of thinking. 111 cryptoassets: Cryptographically guaranteed value. 113 deterministic wallet: See: wallet 115 digital signature: Defined in [RFC4949] as "A value computed with a 116 cryptographic algorithm and associated with a data object in such 117 a way that any recipient of the data can use the signature to 118 verify the data's origin and integrity." 120 distributed ledger: A distributed database about cryptoassets with 121 agreed processed. 123 double spending: Defined in [MasteringBitcoinOnline] as "result of 124 successfully spending some money more than once." 126 fiat money: Currency which has been established by government or 127 other authorities. 129 fork: A fork is a branch of a ledger. Ledger branching may occur 130 accidentally or by specification changes. 132 accidental fork: An accidental fork is a case where a block is 133 accidentally mined at about the same time, and a plurality of 134 chains coexist temporarily. It occurs on a daily basis and 135 converges to the longest chain by re-org. 137 soft fork: A soft fork may influence the implementation of a miner 138 in branches caused by specification change of block chain, but 139 does not affect wallet implementation. 141 hard fork: A hard fork is a branch caused by a specification change 142 without forward compatibility of the block chain, which may affect 143 the wallet implementation in addition to the miner. There is a 144 case where a plurality of chains continue to coexist permanently 145 because there is no consensus between developers regarding the 146 case where the majority of nodes stay in the specification change 147 by following the hard fork, We call it split. Examples of typical 148 splits include the division of Ethereum and Ethereum Classic in 149 the The DAO case of 2016, the division of Bitcoin and Bitcoin Cash 150 in 2017, and so on. The new coin born by division is called a 151 fork coin. 153 genesis block: An initial block on a blockchain. Genesis block may 154 differ to distinguish chains. 156 hash value: Defined in [RFC4949] as "The output of a hash function." 158 hash rate: Amount of a hash value which node is able to generate per 159 unit of time (generally per second) 161 hierarchy deterministic wallet: See: wallet 163 mining: A process to append a received transaction to a block by 164 validating a transaction with agreed consensus rules such as 165 proof-of-work and proof-of-stake. Miner is a network node which 166 contributes its resources to mining. 168 miner: See: mining 170 multisignature: Defined in [MasteringBitcoinOnline] as "requiring 171 more than one key to authorize a bitcoin transaction". In this 172 scope, transaction is not limited to bitcoin transaction. 174 node: A device that connects to blockchain network. 176 off-chain transaction: The movement of value outside of the 177 blockchain 179 on-chain transaction: The movement of value on the blockchain 181 operator: It is a person who performs routine tasks based on 182 authority as a normal task. See also: administrator. 184 orphan block: Defined in [MasteringBitcoinOnline] as "Blocks whose 185 parent block has not been processed by the local node, so they 186 can't be fully validated yet." 188 permissioned-chain: A public blockchain that only specified members 189 can join the blockchain network. 191 permissionless-chain: See: permissioned-chain 192 public-chain: An open blockchain that anyone can retrieve all of 193 blocks and transactions without special privileges. 195 public key: Defined in [RFC4949] as "The publicly disclosable 196 component of a pair of cryptographic keys used for asymmetric 197 cryptography." 199 private-chain: In contrast with "public-chain", A closed blockchain 200 that only permissioned users can access blocks and make 201 transactions. 203 private key: Defined in [RFC4949] as "The secret component of a pair 204 of cryptographic keys used for asymmetric cryptography." 206 proof-of-stake: Defined in [MasteringBitcoinOnline] as "method by 207 which a cryptocurrency blockchain network aims to achieve 208 distributed consensus." 210 proof-of-work: Defined in [MasteringBitcoinOnline] as "A piece of 211 data that requires significant computation to find." 213 reorganization: Invalidation process of branched blockchains. 215 reward: Value by the blockchain network which assigned to a miner 216 who successfully validates a transaction. Rules may differ among 217 blockchains and consensus rules. 219 side-chain: See off-chain 221 smart contract: A guaranteed digital procedure that automatically 222 enforced on a blockchain network. 224 soft fork: See: fork 226 token: An unforgeable data object. 228 transaction: Defined in [MasteringBitcoinOnline] as "More precisely, 229 a transaction is a signed data structure expressing a transfer of 230 value." 232 Incoming transaction: Transfer of cryptoassets from other addresses 233 to one's own address. 235 Outgoing transaction: Transfer of cryptoassets from one's own address 236 to another addresses. 238 validation: Checking correctness and consistency of given data. 240 validated: See: validation 241 validator: See: validation 243 wallet: A wallet is an implementation that handles a key pair of a 244 public key and a secret key used for transmitting a crypto assets 245 and such a key pair. In this document, the latter is 246 distinguished and called wallet implementation. 248 hot wallet: It is a wallet that is online connected to the network, 249 the key is activated, and you can coin out the crypto assets by 250 automatic processing. 252 cold wallet: Normally it is disconnected from the network and the 253 key is inactivated and it is a wallet that can not be coined out 254 unless there is an explicit operation by the operator. Frequency 255 of outgoing coins is limited. 257 Between Hot Wallet and Cold Wallet, there are various intermediate 258 forms such as wallet that is online, but requires manual operation 259 at the time of signing a transaction, wallet that is offline but 260 operation is automated, and warm wallet There are also sometimes 261 called. 263 4. Symbols and abbreviated terms 265 AML Anti-Money Laundering 267 API: Application Programming Interface 269 CFT: Counter Financing of Terrorism 271 DAO: Distributed Autonomous Organization 273 DLT: Distributed Ledger Technologies 275 HD: Hierarchy Deterministic (wallet) 277 PKI: Public Key Infrastructure 279 5. Security Considerations 281 This document defines terminology for cryptoassets. Therefore, there 282 is no security considerations. 284 6. IANA Considerations 286 None. 288 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 7.2. Informative References 303 [MasteringBitcoinOnline] 304 Antonopoulos, A., "Mastering Bitcoin", March 2018, 305 . 307 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 308 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 309 . 311 7.3. URIs 313 [1] https://https://cgtf.github.io/ 315 Acknowledgments 317 Thanks to members of the Cryptoassets Governance Task Force [1] for 318 help and feedback. 320 Authors' Addresses 322 Hirotaka Nakajima 323 Mercari, Inc. R4D 324 Roppongi Hills Mori Tower 21F 325 6-10-1 Roppongi 326 Minato, Tokyo 106-6125 327 JAPAN 329 Email: nunnun@mercari.com 330 Masanori Kusunoki 331 Japan Digital Design, Inc. 332 Nihonbashi Talk Building 333 3-3-5, Nihonbashi-Hongokucho 334 103-0021 335 JAPAN 337 Email: masanori.kusunoki@japan-d2.com 339 Keiichi Hida 340 Japan Blockchain Association 342 Email: hida@jba-web.jp 344 Yuji Suga 345 Advanced Security Division, Internet Initiative Japan Inc. 346 Iidabashi Grand Bloom, 347 2-10-2 Fujimi 348 Chiyoda, Tokyo 102-0071 349 JAPAN 351 Email: suga@iij.ad.jp 353 Tatsuya HAYASHI 354 Lepidum Co. Ltd. 356 Email: hayashi@lepidum.co.jp