Geleceğin Koininin BeyazKağıdı WHİTEPAPER İNFİNİTYECONOMİCS

                    INFINITY ECONOMICS PLATFORM (IEP) WHITEPAPER  Created by the IEP Community  FINAL DRAFT ­ UNDER PEER REVIEW v.0.2 ­ October 3rd, 2017  www.infinity­economics.org Table of Contents  1. Abstract................................................. 3    1.1  What is a blockchain?............................... 3    1.2  Summary............................................. 3    1.3  TD;LR............................................... 3          1.4  Keywords............................................ 3 2. Introduction............................................. 4    2.1  Mission and Goals................................... 4    2.2  Current Challenges in the Market.................. . 4    2.3  Addressed Issues.................................... 4 3. Technology............................................... 4    3.1  Technical Background................................ 5    3.2  Proof of Stake (POS)................................ 5    3.3  Token............................................... 5    3.4  Nodes............................................... 6    3.5  Blocks.............................................. 6    3.6  Block Creation...................................... 7    3.7  Accounts............................................ 8    3.8  Transactions........................................ 9    3.9  Cryptographic....................................... 10    3.10 Architecture........................................ 11    3.11 Toolchains.......................................... 12    3.12 Integration......................................... 12 4. Features................................................. 12    4.1  Payments............................................ 12    4.2  Aliases............................................. 12    4.3  Messages............................................ 13    4.4  Assets.............................................. 13    4.5  Currencies.......................................... 13    4.6  Crowdfunding........................................ 14    4.7  Escrow.............................................. 14    4.8  Subscriptions....................................... 14    4.9  Shuffling........................................... 14    4.10 Voting.............................................. 15    4.11 Automated Transactions.............................. 15    4.12 Gateways............................................ 15    4.13 Proxies............................................. 16    4.14 Extensions.......................................... 16    4.15 Account Control..................................... 16    4.16 Light Client........................................ 17 5. e­Governance............................................. 17    5.1  DAO Overview........................................ 17    5.2  Smart Contracts Solutions........................... 17    5.3  IEP Solution........................................ 18 6. Conclusion............................................... 18 7. Sources, Additional Papers, References................... 19    7.1  Additional Resources................................ 19    7.2  Credits and Acknowledgement......................... 19    7.3  Additions........................................... 19          7.4  References.......................................... 20 2 1. Abstract  January 3rd 2009 marked the beginning of a new era of globalization and world interconnection   when   the   first   Bitcoin   transaction   was   conducted.   Satoshi Nakamoto[1]  made possible what was once thought to be impossible – a currency and payment system not controlled by any person or organization. We know this currency as Bitcoin and the underlying technology that powers it as Blockchain. It has been 8 years since people started using Bitcoin, but only now are we beginning   to   understand   the   real   potential   of   the   blockchain   technology   on which   Bitcoin   is   founded.   Blockchain   does   to   economic   processes   what   the Internet has done to information: today, anyone can have access to the global economy   on   equal   terms   with   others.   In   this   document   we   talk   about   IEP,   a multipurpose blockchain platform made for users.  1.1 What is a blockchain?  A blockchain is a distributed database which enables the creation of a digital ledger   of   transactions   and   the   sharing   of   the   ledger   among   a   distributed network of computers. It uses advanced cryptography to allow each participant on the network to interact with the ledger in a secure way without the need for a   central   authority.   It   maintains   a   continuously   growing   list   of   records (blocks), each containing a timestamp and a link to the previous block.  1.2 Summary  Crypto­currencies,  tokens, digital  coins  and  other  digital assets  based  upon blockchain technology are a mega trend that directly connect the finances of billions of people around the globe via a financial superhighway. The financial superhighway brings together billions of individuals across borders to directly trade products and services with one another anywhere over the Internet. Using blockchain technologies, the value of such financial products and services – and the transactions themselves – are stored in a system that cannot be diluted by politics, over­supply or altered in any way by third parties. The use of blockchain   will   significantly   impact   the   future   of   financial   interactions, rendering   the   traditional   model   of   a   centralized   financial   system   –   where individuals respond to posted numbers on a centralized computer – inadequate for the extremely large number of complex transactions that will be executed daily   on   the   financial   superhighway.   IEP   is   a   user­   and   service­centric multipurpose  blockchain platform and a  cryptocurrency  based  on  proven  crypto open   source   projects.   IEP   acts   as   an   crypto­tech   integrator,   combining   and enhancing   existing   and   new   crypto­tech   features   and   services   into   a   single powerful platform for the digital economy.  1.3 TF;LR IEP   is   the   next­gen   financial   ecosystem.   Its   main   goal   is   to   integrate cryptocurrencies into the traditional financial world and to create a single gateway   to   the   market   for   normal   users,   traders,   investors   and   financial institutions   by   building   a   new   full   service   and   limitless   decentralized financial ecosystem and digital economy. In the initial phase, IEP primarily targets community­based and humanitarian development and projects. To that end, decentralized   voting   and   messaging   are   implemented   to   allow   for   a   DAO­like experience (Hybrid Governance) in managing community projects, whilst remaining straightforward from a technical aspect.  1.4 Keywords cryptocurrency, blockchain, XIN, IEP, smart contracts, decentralized services, 3 asset exchange, currencies, escrow, blocks, nodes, extensions, proxies. 2. Introduction  Since  its  inception, blockchain  technology has  been fraught  with controversy over   its   most   natural   application   –   value   transfer   using   a   network   token. Decentralized money is a ground­breaking development, but blockchain technology cannot be reduced to this alone. Being essentially a distributed database, the blockchain allows for various types of distributed ledger entries, the nature of which depends on their interpretation by the blockchain's users. IEP is an innovative, secure, decentralized and low transaction cost payment system built by   using   cutting­edge   cryptocurrency   technologies,   designed   to   create   entire digital economies akin to traditional financial services. 2.1 Mission and Goals  IEP’s   Mission   is   to   make   the   daunting   cryptocurrency   market   accessible   to everybody, accelerating adoption of blockchain technology and democratisizing ownership   of   cryptocurrencies.   IEP   makes   cryptocurrencies   easier   to   purchase and transfer allowing the average individual to participate in the New Economy. The IEP foundation believes in the philosophical mission established by Satoshi Nakamoto. By creating a secure layer that is accessible to the average person, they put the power in the hands of the people – where it belongs.  2.2 Current Challenges in the Market The future success of cryptocurrencies relies on their widespread use. While crypto   certainly   has   the   potential   to   rise   as   a   global   payment   method,   it remains   the   victim   of   speculation.   Currently,   most   users   are   treating cryptocurrencies as speculative assets rather than using them in daily life. Given   the   sector’s   exponential   growth   and   the   way   Blockchain   technology   is becoming increasingly mainstream, many are optimistic that digital currencies will be used more as a currency and less as a speculative asset. Though several new blockchain technologies and cryptocurrencies have emerged over the past few years, none have yet achieved the breakthrough success required for mainstream adoption ­primarily due to negative publicity, bubble speculations, scams, and complicated   user­interfaces.   Hacking   and   other   cyberattacks   on   crypto exchanges, and directly on users devices and wallets, have also contributed to the overall uncertainty which accompanies this new technology.  2.3 Addressed Issues Cryptocurrency   is   a   decentralized   blockchainbased   financial   system   with immutability and autonomy being its most celebrated features. Cryptocurrencies enable   one   to   bypass   intermediaries   and   remain   independent   from   traditional financial   institutions.   However,   no   cryptocurrency,   including   Bitcoin,   has managed   to   become   a   commonly   used   monetary   asset.   Merchants   and   service providers   are   reluctant   to   accept   cryptocurrency   payments   as   it   involves additional   risks   of   exchange   losses   and   regulatory   issues   as   well   as   high volatility. An instrument capable of becoming a perfect global payments system is commonly used as a speculative asset. This project is devised as a solution for the fundamental problem in question, and takes into account the problems and challenges faced by the current global financial system. 3. Technology IEP   is   a   100%   proof­of­stake   cryptocurrency[11],   constructed   from   proven   open source projects[3]  written in Java. IEP's unique proof­of­stake algorithm does not depend on any implementation of the “coin age” concept used by other proof4 of­stake   cryptocurrencies,   and   is   resistant   to   so­called   “nothing   at   stake” attacks. A total quantity of 9 billion available tokens were distributed in the genesis   block.   Curve25519[8]  cryptography   is   used   to   provide   a   balance   of security  and  required  processing power, along with  more  commonly­used  SHA256 hashing algorithms[13].  3.1 Technical Background Blocks   are   generated   every   60   seconds,   on   average,   by   accounts   that   are unlocked  on   network   nodes.   Since   the   full   token   supply   already   exists,   IEP   is redistributed through the inclusion of transaction fees which are awarded to an account when it successfully creates a block. This process is known as forging, and   is   akin   to   the   “mining”   concept   employed   by   other   cryptocurrencies. Transactions are deemed safe after 10 block confirmations, and IEP's current architecture   and   block   size   cap   allows   for   the   processing   of   up   to   367,200 transactions   per   day,   with   unlimited   scalability   potential.   IEP   transactions are based on a series of core transaction types that do not require any script processing or transaction input/output processing on the part of network nodes. 3.2 Proof of Stake (POS) IEP uses a system where each "token" in an account can be thought of as a tiny mining rig[11]. The more tokens that are held in the account, the greater the chance that account will earn the right to generate a block. The total "reward" received as a result of block generation is the sum of the transaction fees located within the block. IEP does not generate any new tokens as a result of block   creation.   Redistribution   of   IEP   takes   place   as   a   result   of   block generators receiving transaction fees, so the term "forging" (meaning in this context   "to   create   a   relationship   or   new   conditions“)   is   used   instead   of “mining”.   Subsequent   blocks   are   generated   based   on   verifiable,   unique,   and almost­unpredictable information from the preceding block. Blocks are linked by virtue of these connections, creating a chain of blocks (and transactions) that can be traced all the way back to the genesis block. Block generation time is targeted   at  60  seconds,  but   variations   in   probabilities   have   resulted   in   an average   block   generation   time   of   80   seconds,   with   occasionally   longer   block intervals.   The   security   of   the   blockchain   is   always   of   concern   in   Proof   of Stake   systems.   The   following   basic   principles   apply   to   IEP   Proof   of   Stake algorithm:  ­ A cumulative difficulty value is stored as a parameter in each block, and    each subsequent block derives its new “difficulty” from the previous block’s    value. In case of ambiguity, the network achieves consensus by selecting    the block or chain fragment with the highest cumulative difficulty.  ­ To prevent account holders from moving their stake from one account to    another as a means of manipulating their probability of block generation,    tokens must be stationary within an account for 1,440 blocks before they    can contribute to the block generation process. Tokens that meet this    criterion contribute to an account’s effective balance, and this balance is    used to determine forging probability.  ­ To keep an attacker from generating a new chain all the way from the    genesis block, the network only allows chain re­organization 720 blocks    behind the current block height. Any block submitted at a height lower    than this threshold is rejected. This moving threshold may be viewed as    IEP only fixed checkpoint.  ­ Due to the extremely low probability of any account taking control of the  5   blockchain by generating its own chain of blocks, transactions are deemed    safe once they are encoded into a block that is 10 blocks behind the current    block height.  3.3 Token  The total supply is 9 billion tokens, divisible to eight decimal places. All tokens were issued with the creation of the genesis block (the first block in the   IEP   blockchain),   leaving   the   genesis   account[C]  with   an   initial   negative balance of 9 billion token. The existence of anti­tokens in the genesis account has a couple of interesting side effects:  ­ the genesis account cannot issue transactions of any kind, since its balance    is negative and it cannot pay transaction fees. ­ any tokens sent to the genesis account are effectively destroyed, since that    account’s negative balance will cancel them out . The choice of the word tokens is intentional due to IEP's intention to be used  as a base protocol that provides numerous other functions. IEP’s most basic  function is one of a traditional payment system, but it was designed to do far  more. 3.4 Nodes  A node on the IEP network is any device that is contributing transaction or block data to the network. Any device running the IEP software is seen as a node.   Nodes   can   be   subdivided   into   two   types:   hallmarked   and   normal.   A hallmarked node is simply a node that is tagged with an encrypted token derived from an account’s private key; this token can be decoded to reveal a specific token account address and balance that are associated with a node. The act of placing   a   hallmark   on   a   node   adds   a   level   of   accountability   and   trust,   so hallmarked nodes are more trusted than non­hallmarked nodes on the network. The larger the balance of an account tied to a hallmarked node, the more trust is given to that node. While an attacker might wish to hallmark a node in order to gain trustworthiness within the network and then use that trust for malicious purposes; the barrier to entry (cost of token required to build adequate trust) discourages such abuse. Each node on the IEP network has the ability to process and broadcast both transactions and block information. Blocks are validated as they   are   received   from   other   nodes[I],   and   in   cases   where   block   validation fails,   nodes   may   be   “blacklisted”   temporarily   to   prevent   the   propagation   of invalid   block   data.   Each   node   features   built­in   DDOS   (Distributed   Denial   of Services) defence mechanisms which restrict the number of network requests from any peer to 30 per second. 3.5 Blocks  As  in  other   cryptocurrencies,  the   ledger   of   token   transactions   is   built   and stored   in   a   linked   series   of   blocks,   known   as   a   blockchain.   This   ledger provides   a  permanent  record   of  transactions   that  have   taken   place,   and  also establishes   the   order   in   which   transactions   have   occurred.   A   copy   of   the blockchain is kept on  every node in the IEP network, and every account that is unlocked on a node (by supplying that account’s private key) has the ability to generate blocks, as long as at least one incoming transaction to the account has been confirmed 1440 times. Any account that meets these criteria is referred to as an active account. In IEP, each block contains up to 255 transactions, all prefaced by a 192­byte   header   that   contains   identifying   parameters.   Each   transaction   in   a 6 block is represented by a maximum of 160 bytes, and the maximum block size is 32KB. All blocks contain the following parameters:  ­ A block version, block height value, and block identifier  ­ A block timestamp, expressed in seconds since the genesis block  ­ The ID of the account that generated the block, as well as that account’s    public key  ­ The ID and hash of the previous block. The number of transactions stored    in the block  ­ The total amount of token represented by transactions and fees in the block  ­ Transaction data for all transactions included in the block, including their    transaction IDs  ­ The payload length of the block, and the hash value of the block payload  3.6 Block Creation  Three values are key to determining which account is eligible to generate a block, which account earns the right to generate a block, and which block is taken   to   be   the   authoritative   one   in   times   of   conflict:   base   target   value, target value and cumulative difficulty.  Base Target Value  In order to win the right to forge (generate) a block, all active IEP accounts 'compete' by attempting to generate a hash value that is lower than a given  base target value. This base target value varies from block to block, and is   derived from the previous block’s base target value.  Target Value Each account calculates its own target value, based on its current effective stake. This value is: T = Tb × S × Be  where:         T  is the new target value  Tb  is the base target value  S  is the time since the last block, in seconds  Be  is the effective balance of the account  As can be seen from the formula, the target value grows with each second that  passes since the timestamp of the previous block. The maximum target value  is 0.17080318 x 10e17 and the minimum target value is one half of the previous block’s base target value. This target value and the base target value are the same for all accounts attempting to forge on top of a specific block.  The only account­specific parameter is the effective balance parameter.  Cumulative Difficulty The cumulative difficulty value is derived from the  base target value, using the formula: Dcb = Dpb + 264 / Tb  where:  Dcb    is the difficulty of the current block  Dpb    is the difficulty of the previous block  Tb     is the base target value for the current block[j] The Forging Algorithm  Each block on the chain has a generation signature parameter. To participate in the   block   forging   process,   an   active   account   cryptographically   signs   the generation   signature   of   the   previous   block   with   its   own   public   key.   This creates a 64­byte signature, which is then hashed using SHA256. The first 8 bytes of the resulting hash gives a number, referred to as the account’s hit. 7 The hit is compared to the current target value. If the computed hit is lower than the target, then the next block can be generated. As noted in the target value   formula,  the   target   value   increases   with   each  passing   second.  Even   if there   are   only   a   few   active   accounts   on   the   network,   one   of   them   will eventually generate a block because the target value will become very large. The corollary of this  is  that  you   can  estimate   the  time   that   will  be  required   for  any  account  to forge a block by comparing that account’s hit value to the target value. When an  active   account   wins   the   right   to   generate   a   block,   it   bundles   up   to   255 available, unconfirmed transactions into a new block, and populates the block with   all   of   its   required   parameters.   This   block   is   then   broadcast   to   the network   as   a   candidate   for   the   blockchain.   The   payload   value,   generating account, and all of the signatures on each block can be verified by all network nodes who receive it. In a situation where multiple blocks are generated, nodes will   select   the   block   with   the   highest   cumulative   difficulty   value   as   the authoritative   block.   As   block   data   is   shared   between   peers,   forks   (nonauthoritative   chain   fragments)   are   detected   and   dismantled   by   examining   the chains'cumulative difficulty values stored in each fork.  3.7 Accounts  IEP implements a brain wallet as part of its design: all accounts are stored on the   network   with   private   keys   for   each   possible   account   address   directly derived   from   each   account’s   passphrase   using   a   combination   of   SHA256   and Curve25519 operations. Each account is represented by a 64­bit number, and this number   is   expressed   as   an   account   address   using   a   Reed­Solomon[k]  errorcorrecting   notation   that   allows   for   detection   of   up   to   four   errors   in   an account address, or correction of up to two errors. This format was implemented in response to concerns that a mistyped account address could result in tokens, aliases,   or   assets   being   irreversibly   transferred   to   erroneous   destination accounts. Account addresses are always prefaced by “XIN­”, making token account addresses easily recognizable and distinguishable from address formats used by other   cryptocurrencies.   The   Reed­Solomon­encoded   account   address   associated with a secret passphrase is generated as follows:  1. The secret passphrase is hashed with SHA256 to derive the account’s     private key.  2. The private key is encrypted with Curve25519 to derive the account’s     public key.  3. The public key is hashed with SHA256 to derive the account ID.  4. The first 64 bits of the account ID are the visible account number.  5. Reed­Solomon encoding of the visible account number, prefixed with     "XIN­", generates the account address.  When an account is accessed by a secret passphrase for the very first time, it is not secured by a public key. When the first outgoing transaction from an account is made, the 256­bit public key derived from the passphrase is stored on the blockchain, and this secures the account. The address space for public keys   (2256)   is   larger   than   the   address   space   for   account   numbers   (264),   so there is no one­to­one mapping of passphrases to account numbers and collisions are possible. These collisions are detected and prevented in the following way: once a specific passphrase is used to access an account, and that account is secured by a 256­bit public key, no other public­private key pair is permitted 8 to access that account number. Account Balance Properties  For each IEP account, several different types of balances are available. Each  type serves a different purpose, and many of these values are checked as part  of transaction validation and processing. ­ The effective balance of an account is used as the basis for an account’s    forging calculations[L]. An account’s effective balance consists of all tokens   that have been stationary in that account for 1440 blocks. In addition,    the Account Leasing feature allows an account’s effective balance to be    assigned to another account for a temporary period.  ­ The guaranteed balance of an account consists of all tokens that have been    stationary in an account for 1440 blocks. Unlike the effective balance, this    balance cannot be assigned to any other account.  ­ The basic balance of an account represents all transactions that have    had at least one confirmation.  ­ The forged balance of an account shows the total quantity of token that    have been earned as a result of successfully forging blocks.  ­ The unconfirmed balance of an account is the one that is displayed in IEP    clients. It represents the current balance of an account, minus the tokens    involved in unconfirmed, sent transactions.  ­ Guaranteed asset balances lists the guaranteed balances of all the assets    associated with a specific account.  ­ Unconfirmed asset balances lists the unconfirmed balances of all the assets    associated with a specific account. 3.8 Transactions Transactions are the only means IEP accounts have of altering their state or  balance. Each transaction performs only one function, the record of which is  permanently stored on the network once that transaction has been included in  a block.  Transaction Fees Transaction fees are the primary mechanism through which token are recirculated back   into   the   network.   Every   transaction   requires   a   minimum   fee   of   1   token while several services like aliases, assets or voting require higher fees. When a   IEP   account   forges   a   block,   all   of   the   transaction   fees   included   in   that block are awarded to the forging account as a reward. Until the size of all the transactions in a block exceeds the current 32 kilobyte block size limit, the minimum fee will be sufficient for all transactions to be included in blocks. In situations where the number of unconfirmed transactions exceeds the number that can be placed in a block, forging accounts will likely select transactions with   the   highest   fees.   This   suggests   that   transaction   processing   may   be prioritized by including a fee that is higher than the minimum.  Transaction Confirmations  All IEP transactions are considered unconfirmed until they are included in a valid network block. Newly created blocks are distributed to the network by the node   (and   associated   account)   that   creates   them,   and   a   transaction   that   is included   in   a   block   is   considered   as   having   received   one   confirmation.   As 9 subsequent blocks are added to the existing blockchain, each additional block adds one more confirmation to the number of confirmations for a transaction. If a transaction is not included in a block before its deadline, it expires and is removed from the transaction pool.  Transaction Deadlines  Every   transaction  contains  a   deadline   parameter,  set   to  a   number  of  minutes from the time the transaction is submitted to the network. The default deadline is   1440   minutes   (24   hours).   A   transaction   that   has   been   broadcast   to   the network but has not been included in a block is referred to as an unconfirmed transaction.   If   a   transaction   has   not   been   included   in   a   block   before   the transaction   deadline   expires,   the   transaction   is   removed   from   the   network. Transactions may be left unconfirmed because they are invalid or malformed, or because   blocks   are   being   filled   will   transactions   that   have   offered   to   pay higher   transaction   fees.   In   the   future,   features   such   as   multi­signature transactions may be able to take advantage of deadlines as a means of enforcing an expiry date.  Transaction Types  Categorizing IEP transactions into types and subtypes allows for modular growth and   development   of   the   IEP   protocol   without   creating   dependencies   on   other “base” functions. As features are added to the IEP core, new transaction types and   subtypes   can   be   added   to   support   them.   During   integration   additional transaction   types   like   subscriptions,   escrow   and   automated   transactions   are added, named as advanced transactions. Transaction Creation and Processing The details of creating and processing a IEP transaction are as follows:  1. The sender specifies parameters for the transaction. Types of transactions     vary, and the desired type is specified at transaction creation, but several    parameters must be specified for all transactions:     ­ the private key for the sending account     ­ a specified fee for the transaction     ­ a deadline for the transaction     ­ an optional referenced transaction  2. All values for the transaction inputs are checked. For example, mandatory     parameters must be specified; fees cannot be less than or equal to zero; a     transaction deadline cannot be less than one minute into the future; if a     referenced transaction is specified, then the current transaction cannot be     processed until the referenced transaction has been processed.  3. If no exceptions are thrown as a result of parameter checking:     (a) The public key for the generating account is computed using the         supplied secret passphrase     (b) Account information for the generating account is retrieved, and         transaction parameters are further validated:         ­ The sending account’s balance cannot be zero         ­ The sending account’s unconfirmed balance must not be lower           than the transaction amount plus the transaction fee  4. If the sending account has sufficient funds for the transaction:     (a) A new transaction is created, with a type and subtype value set to         match the kind of transaction being made. All specified parameters         are included. A unique transaction ID is generated with the creation         of the object     (b) The transaction is signed using the sending account’s private key  10    (c) The encrypted transaction data is placed within a message instruct­         ing network peers to process the transaction     (d) The transaction is broadcast to all peers on the network     (e) The server responds with a result code:         ­ the transaction ID, if the transaction creation was successful         ­ an error code and error message if any of the parameter checks fail. 3.9 Cryptographic Introduction Elliptic curve cryptography (ECC)[8] is a public­key cryptography method that  uses elliptic curves algebraic structures over finite fields. ECC provides  security using smaller keys than other cryptographic methods. ECC can be used  for key agreement, digital signatures, pseudo­random generators, etc. ECC can  be used for indirect encryption by using a symmetric encryption scheme with the key agreement.   Key exchange in IEP is based on the Curve25519 algorithm, which generates a shared secret key using a fast, efficient, high­security elliptic­curve DiffieHellman function[7]. The algorithm was first demonstrated by Daniel J. Bernstein in 2006[8]. IEP's Message signing in IEP is implemented using the Elliptic­Curve Korean Certificate based Digital Signature Algorithm (EC­KCDSA), specified as part of IEEE P1363a by the KCDSA Task Force team in 1998[9]. Both algorithms were chosen for their balance of speed and security for a key size of only 32 bytes.  Encryption Algorithm  When Alice sends an encrypted plain text to Bob, she:  1. Calculates a shared secret:     ­ shared_secret = Curve25519(Alice_private_key, Bob_public_key)  2. Calculates N seeds:     ­ seedn = SHA256(seedn­1 ), where seed0 = SHA256(shared_secret)  3. Calculates N keys:     ­ keyn = SHA256(Inv(seedn )), where Inv(X) is the inversion of all bits       of X  4. Encrypts the plaintext:     ­ ciphertext[n] = plaintext[n] XOR keyn Upon receipt Bob decrypts the ciphertext:  1. Calculates a shared secret:     ­ shared_secret = Curve25519(Bob_private_key, Alice_public_key)  2. Calculates N seeds (this is identical to Alice’s step):     ­ seedn = SHA256(seedn­1 ), where seed0 = SHA256(shared_secret)  3. Calculates N keys (this is identical to Alice’s step):     ­ keyn = SHA256(Inv(seedn )), where Inv(X) is the inversion of all bits       of X  4. Decrypts the ciphertext:     ­ plaintext[n] = ciphertext[n] XOR keyn  Note: If someone guesses part of the plaintext, he can decode some part of  subsequent messages between Alice and Bob if they use the same key pairs.  As a result, it’s advised to generate a new pair of private/public keys for  each  communication.  11 3.10 Architecture  First­generation cryptocurrencies were primarily designed as payment systems. IEP   recognizes   that   decentralized   blockchains   can   enable   a   broad   range   of applications and services, but is not prescriptive about what those services should be or how they should be built. By design, IEP strips away unnecessary complexity   in   its   core,   leaving   only   the   most   successful   components   of   its predecessors intact. As a result, IEP functions like a low­level, foundational protocol:   it   defines   the   interfaces   and   operations   required   to   operate   a lightweight   blockchain,   a   decentralized   communication   system,   and   a   rapid transaction processing framework, allowing higher­order components to build on those features. Transactions in IEP make simple adjustments to account balances instead of tracing sets of “input” or “output” credits. In addition, the core software does not support any form of scripting language. By providing a set of basic, flexible transaction types that can quickly and easily be processed, IEP creates a foundation that does not limit the ways in which those transaction types can be used, and does not create significant overhead for using them. This   flexibility   is   further   amplified   by   IEP's   low   resource   and   energy requirements, and its highly readable, highly organized object­oriented source code.  3.11 Toolchains  IEP is focused on industry standards for all platform developments. The core is written in enterprise friendly Java[D], the backends are powered by NodeJS[E] and all frontends are build with AngularJS[F], making it easy to allocate developer resources anytime, anywhere. Cross platform apps are build with electron[G]. The default backend storage is MongoDB[H]. This toolchain gives the foundation much more   freedom   to   choose   the   best   developers/contractors   for   all   upcoming programming tasks, since the developer communities for those tools is matured and large with plenty of proven components annd frameworks, ready to use. 3.12 Integration  The   cryptospace   is   evolving   very   rapidly.   New   technologies   and   powerful protocols   and   components   are   developed   daily.   To   address   this   devstream   IEP monitors the whole crypto development attentively for additional features worth adding   to   the   IEP   platform   either   for   the   core   or   for   the   services.   New transaction   types   can   be   added   on   the   fly   to   expand   the   core   with   powerful features as needed. This way IEP acts as an crypto­feature­integrator to always provide   state   of   the   art   building   blocks   for   the   digital   economy.   All   new features   are   introduced  to  the   community   for   voting  and   acceptance   prior   to implementation. 4. Features IEP   is   designed   to   integrate   building   blocks   for   the   digital   economy   and therefore relies heavily on secure and robust off­chain infrastructure to reach the average user. To achieve this objective, the IEP core and client is built for easy extensability[14]  and connection to others, very useful protocols and networks. IEP isn't meant to act, as most cryptos, as an island but to embrace and   welcome   all   new   technologies,   from   very   classical   to   the   most   advanced. Most  services   are   based   on   IEP's   enhanced   core   implementations   like   proxies   and gateways. Services can be public or private, running as UI­less bots or even as extensions within the wallet UI. Services play a very important role in IEP's future   development   and   growth   strategy,   therefore   the   foundation   will facilitate   the   enhancing   of   those   services   and   initiate   or   even   develop 12 community relevant services like the enhanced encrypted messaging/chat or news services  with  external  contractors.  The list  of  realized/planned services is growing constantly. Please refer to wallet extensions to get an overview about already implemented and planned services.  4.1 Payments Tokens (XIN) are most relevant to the user. A transfer transaction type is used to transfer tokens from one account to another. A small encrypted message can be attached to each transaction for an additional fee. The fee&nbs

Reklam2
Yorum Yaz
Arkadaşların Burada !
Arkadaşların Burada !