idnits 2.17.1 draft-nakajima-crypto-asset-terminology-04.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 (July 02, 2020) is 1395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 344 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: January 3, 2021 JDD 6 K. Hida 7 JBA 8 Y. Suga 9 Advanced Security Div, IIJ 10 T. Hayashi 11 Lepidum 12 July 02, 2020 14 Terminology for Cryptoassets 15 draft-nakajima-crypto-asset-terminology-04 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 January 3, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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: Approval works defined by the consensus algorithm. 107 A status that blocks and transactions in a certain block are 108 approved by miners and users of the blockchain network. 110 consensus: Coincidence the way of thinking. 112 cryptoassets: A digital representation of values that can be 113 exchanged or transferred digitally, realized by a distributed 114 ledger such as blockchain utilizing cryptography or similar 115 technology. 117 cryptoassets custody service: Business to manage the kind of 118 cryptoassets. 120 cryptoassets custodian: The business entities that operates the 121 cryptoasset custody business. 123 cryptoassets custody system: Information system responsible for 124 cryptoasset custody business. 126 cryptoassets exchange: A function for exchanging fiat currencies 127 and cryptoassets, and also exchanging cryptoassets with each 128 other. 130 cryptoassets exchange service provider: A business entitiy that 131 operates a cryptoasset exchange. 133 deterministic wallet: See: wallet 135 digital signature: Defined in [RFC4949] as "A value computed with a 136 cryptographic algorithm and associated with a data object in such 137 a way that any recipient of the data can use the signature to 138 verify the data's origin and integrity." 140 distributed ledger: A distributed database about cryptoassets with 141 agreed processed. 143 double spending: Defined in [MasteringBitcoinOnline] as "result of 144 successfully spending some money more than once." 146 fiat currency: Currency which has been established by government or 147 other authorities. 149 fork: A fork is a branch of a ledger. Ledger branching may occur 150 accidentally or by specification changes. 152 accidental fork: An accidental fork is a case where a block is 153 accidentally mined at about the same time, and a plurality of 154 chains coexist temporarily. It occurs on a daily basis and 155 converges to the longest chain by re-org. 157 soft fork: A soft fork may influence the implementation of a miner 158 in branches caused by specification change of block chain, but 159 does not affect wallet implementation. 161 hard fork: A hard fork is a branch caused by a specification change 162 without forward compatibility of the block chain, which may affect 163 the wallet implementation in addition to the miner. There is a 164 case where a plurality of chains continue to coexist permanentlys 165 because there is no consensus between developers regarding the 166 case where the majority of nodes stay in the specification change 167 by following the hard fork, we call it split. Examples of typical 168 splits include the division of Ethereum and Ethereum Classic in 169 the The DAO case of 2016, the division of Bitcoin and Bitcoin Cash 170 in 2017, and so on. The new coin born by division is called a 171 fork coin. 173 genesis block: An initial block on a blockchain. Genesis block may 174 differ to distinguish chains. 176 hash value: Defined in [RFC4949] as "The output of a hash function." 178 hash rate: Amount of a hash value which node is able to generate per 179 unit of time (generally per second) 181 hierarchy deterministic wallet: See: wallet 183 mining: A process to append a received transaction to a block by 184 validating a transaction with agreed consensus rules such as 185 proof-of-work and proof-of-stake. 187 miner: A network node which contributes its resources to mining. 189 multisignature: Defined in [MasteringBitcoinOnline] as "requiring 190 more than one key to authorize a bitcoin transaction". In this 191 scope, transaction is not limited to bitcoin transaction. 193 node: A device that connects to blockchain network. 195 off-chain transaction: The movement of value outside of the 196 blockchain 198 on-chain transaction: The movement of value on the blockchain 200 operator: It is a person who performs routine tasks based on 201 authority as a normal task. See also: administrator. 203 orphan block: Defined in [MasteringBitcoinOnline] as "Blocks whose 204 parent block has not been processed by the local node, so they 205 can't be fully validated yet." 207 permissioned-chain: A blockchain that only specified members can 208 join the blockchain network. 210 permissionless-chain: See: permissioned-chain 212 public-chain: An open blockchain that anyone can retrieve all of 213 blocks and transactions without special privileges. 215 public key: Defined in [RFC4949] as "The publicly disclosable 216 component of a pair of cryptographic keys used for asymmetric 217 cryptography." 219 private-chain: In contrast with "public-chain", A closed blockchain 220 that only permissioned users can access blocks and make 221 transactions. 223 private key: Defined in [RFC4949] as "The secret component of a pair 224 of cryptographic keys used for asymmetric cryptography." 226 proof-of-stake: Defined in [MasteringBitcoinOnline] as "method by 227 which a cryptocurrency blockchain network aims to achieve 228 distributed consensus." 230 proof-of-work: Defined in [MasteringBitcoinOnline] as "A piece of 231 data that requires significant computation to find." 233 reorganization: The convergence into one chain based on a certain 234 consensus from multiple chains that are temporarily branched. 236 reward: Value by the blockchain network which assigned to a miner 237 who successfully validates a transaction. Rules may differ among 238 blockchains and consensus rules. 240 side-chain: See off-chain 242 smart contract: A guaranteed digital procedure that automatically 243 enforced on a blockchain network. 245 soft fork: See: fork 247 token: 1) Data that represents the amount of cryptoassets like ERC20 248 specifiation, 2) Data used in the API as one of the factors with the 249 authentication process. 251 transaction: Defined in [MasteringBitcoinOnline] as "More precisely, 252 a transaction is a signed data structure expressing a transfer of 253 value." 255 incoming transaction: Transfer of cryptoassets from other addresses 256 to one's own address. 258 outgoing transaction: Transfer of cryptoassets from one's own 259 address to another addresses. 261 validation: Checking the accuracy and consistency of given 262 transactions and blocks. Specifically, it is general to verify the 263 integrity of data to be digital-signed and also the integrity of 264 other transactions and blocks. By verifying a transaction 265 repeatedly, it is possible to verify blocks in the transaction. 267 validated: See: validation 269 validator: See: validation 271 wallet: A wallet is a mechanism that handles a key pair of a public 272 key and a secret key used for transmitting cryptoassets and such 273 a key pair. 275 hot wallet: It is a wallet that is online connected to the network, 276 the key is activated, and you can coin out the crypto assets by 277 automatic processing. 279 cold wallet: Normally it is disconnected from the network and the 280 key is inactivated and it is a wallet that can not be coined out 281 unless there is an explicit operation by the operator. Frequency 282 of outgoing coins is limited. 284 Between Hot Wallet and Cold Wallet, there are various intermediate 285 forms such as wallet that is online, but requires manual operation 286 at the time of signing a transaction, wallet that is offline but 287 operation is automated, and warm wallet There are also sometimes 288 called. 290 4. Symbols and abbreviated terms 292 AML Anti-Money Laundering 294 API: Application Programming Interface 296 CFT: Counter Financing of Terrorism 298 DAO: Distributed Autonomous Organization 300 DLT: Distributed Ledger Technologies 302 HD: Hierarchy Deterministic (wallet) 304 PKI: Public Key Infrastructure 306 5. Security Considerations 308 This document defines terminology for cryptoassets. Therefore, there 309 is no security considerations. 311 6. IANA Considerations 313 None. 315 7. References 317 7.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 7.2. Informative References 330 [MasteringBitcoinOnline] 331 Antonopoulos, A., "Mastering Bitcoin", March 2018, 332 . 334 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 335 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 336 . 338 7.3. URIs 340 [1] https://cgtf.github.io/ 342 Acknowledgments 344 Thanks to members of the Cryptoassets Governance Task Force [1] for 345 help and feedback. 347 Authors' Addresses 349 Hirotaka Nakajima 350 Mercari, Inc. R4D 351 Roppongi Hills Mori Tower 21F 352 6-10-1 Roppongi 353 Minato, Tokyo 106-6125 354 JAPAN 356 Email: nunnun@mercari.com 358 Masanori Kusunoki 359 Japan Digital Design, Inc. 360 Nihonbashi Talk Building 361 3-3-5, Nihonbashi-Hongokucho 362 103-0021 363 JAPAN 365 Email: masanori.kusunoki@japan-d2.com 367 Keiichi Hida 368 Japan Blockchain Association 370 Email: hida@jba-web.jp 372 Yuji Suga 373 Advanced Security Division, Internet Initiative Japan Inc. 374 Iidabashi Grand Bloom, 375 2-10-2 Fujimi 376 Chiyoda, Tokyo 102-0071 377 JAPAN 379 Email: suga@iij.ad.jp 380 Tatsuya HAYASHI 381 Lepidum Co. Ltd. 383 Email: hayashi@lepidum.co.jp