idnits 2.17.1 draft-nakajima-crypto-asset-terminology-00.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, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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, 2019 JDD 6 K. Hida 7 JBA 8 Y. Suga 9 Advanced Security Div, IIJ 10 T. Hayashi 11 Lepidum 12 July 02, 2018 14 Terminology for Crypto Asset 15 draft-nakajima-crypto-asset-terminology-00 17 Abstract 19 This document provides terminology used in crypto asset. 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, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Our goal with this document is to improve our understanding on a set 69 of terms which frequently used in documents which related to crypto 70 asset. Mutual understanding about terminology may help to reach a 71 consensus on issues we're trying to solve. 73 2. Conventions and Definitions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in BCP 78 14 [RFC2119] [RFC8174] when, and only when, they appear in all 79 capitals, as shown here. 81 3. Terms and Definitions 83 address: An identifier to represent a public key in a blockchain 84 network. 86 asymmetric cryptography: Defined in [RFC4949] as "A modern branch of 87 cryptography (popularly known as "public-key cryptography") in 88 which the algorithms use a pair of keys (a public key and a 89 private key) and use a different component of the pair for each of 90 two counterpart cryptographic operations (e.g., encryption and 91 decryption, or signature creation and signature verification). " 93 block: A basic unit of the blockchain. A set of transactions on a 94 blockchain which contains a cryptographic hash value of previous 95 block. 97 blockchain: A digital ledger about transactions for crypto assets. 99 confirmation: (For transactions,) checking correctness of a 100 transaction in the mainchain. 102 consensus: Coincidence the way of thinking. 104 crypto assets: Cryptographically guaranteed value. 106 deterministic wallet: See: wallet 108 digital signature: Defined in [RFC4949] as "A value computed with a 109 cryptographic algorithm and associated with a data object in such 110 a way that any recipient of the data can use the signature to 111 verify the data's origin and integrity." 113 distributed ledger: A distributed database about crypto assets with 114 agreed processed. 116 double spending: Defined in [MasteringBitcoinOnline] as "result of 117 successfully spending some money more than once." 119 fiat money: Currency which has been established by government or 120 other authorities. 122 fork: Defined in [MasteringBitcoinOnline] as "Fork, also known as 123 accidental fork, occurs when two or more blocks have the same 124 block height, forking the block chain. Typically occurs when two 125 or more miners find blocks at nearly the same time." 127 genesis block: An initial block on a blockchain. Genesis block may 128 differ to distinguish chains. 130 hard fork: See: fork 132 hash value: Defined in [RFC4949] as "The output of a hash function." 134 hash rate: Amount of a hash value which node is able to generate per 135 unit of time (generally per second) 137 hierarchy deterministic wallet: See: wallet 139 mining: A process to append a received transaction to a block by 140 validating a transaction with agreed consensus rules such as 141 proof-of-work and proof-of-stake. Miner is a network node which 142 contributes its resources to mining. 144 miner: See: mining 145 multisignature: Defined in [MasteringBitcoinOnline] as "requiring 146 more than one key to authorize a bitcoin transaction". In this 147 scope, transaction is not limited to bitcoin transaction. 149 node: A device that connects to blockchain network. 151 off-chain transaction: The movement of value outside of the 152 blockchain 154 on-chain transaction: The movement of value on the blockchain 156 orphan block: Defined in [MasteringBitcoinOnline] as "Blocks whose 157 parent block has not been processed by the local node, so they 158 can't be fully validated yet." 160 permissioned-chain: A public blockchain that only specified members 161 can join the blockchain network. 163 permissionless-chain: See: permissioned-chain 165 public-chain: An open blockchain that anyone can retrieve all of 166 blocks and transactions without special privileges. 168 public key: Defined in [RFC4949] as "The publicly disclosable 169 component of a pair of cryptographic keys used for asymmetric 170 cryptography." 172 private-chain: In contrast with "public-chain", A closed blockchain 173 that only permissioned users can access blocks and make 174 transactions. 176 private key: Defined in [RFC4949] as "The secret component of a pair 177 of cryptographic keys used for asymmetric cryptography." 179 proof-of-stake: Defined in [MasteringBitcoinOnline] as "method by 180 which a cryptocurrency blockchain network aims to achieve 181 distributed consensus." 183 proof-of-work: Defined in [MasteringBitcoinOnline] as "A piece of 184 data that requires significant computation to find." 186 reorganization: Invalidation process of branched blockchains. 188 reward: Value by the blockchain network which assigned to a miner 189 who successfully validates a transaction. Rules may differ among 190 blockchains and consensus rules. 192 side-chain: See off-chain 193 smart contract: A guaranteed digital procedure that automatically 194 enforced on a blockchain network. 196 soft fork: See: fork 198 token: An unforgeable data object. 200 transaction: Defined in [MasteringBitcoinOnline] as "More precisely, 201 a transaction is a signed data structure expressing a transfer of 202 value." 204 validation: Checking correctness and consistency of given data. 206 validated: See: validation 208 validator: See: validation 210 wallet: A set of key pair composed of public key and private key. 212 4. Security Considerations 214 This document defines terminology for crypto asset. Therefore, there 215 is no security considerations. 217 5. IANA Considerations 219 None. 221 6. References 223 6.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 232 May 2017, . 234 6.2. Informative References 236 [MasteringBitcoinOnline] 237 Antonopoulos, A., "Mastering Bitcoin", March 2018, 238 . 240 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 241 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 242 . 244 Acknowledgments 246 Thanks to members of the Virtual Currency Governance Task Force for 247 help and feedback. 249 Authors' Addresses 251 Hirotaka Nakajima 252 Mercari, Inc. R4D 253 Roppongi Hills Mori Tower 18F 254 6-10-1 Roppongi 255 Minato, Tokyo 106-6118 256 JAPAN 258 Email: nunnun@mercari.com 260 Masanori Kusunoki 261 Japan Digital Design, Inc. 263 Email: masanori.kusunoki@japan-d2.com 265 Keiichi Hida 266 Japan Blockchain Association 268 Email: hida@jba-web.jp 270 Yuji Suga 271 Advanced Security Division, Internet Initiative Japan Inc. 272 Iidabashi Grand Bloom, 273 2-10-2 Fujimi 274 Chiyoda, Tokyo 102-0071 275 JAPAN 277 Email: suga@iij.ad.jp 279 Tatsuya HAYASHI 280 Lepidum Co. Ltd. 282 Email: hayashi@lepidum.co.jp