|
January 01, 2017, 08:03:34 PM Last edit: January 22, 2017, 10:59:10 AM by alkan |
|
I have come up with an improved concept:
A) Account creation and transfer 1. There are two types of accounts: Regular accounts and minting accounts. Both accounts can be used to make payments to other accounts of any type. 2. Regular accounts can be created by anybody from scratch by generating a valid keypair, whereas new minting accounts (child accounts) can only be derived from existing minting accounts (parent accounts). 3. When a minting account creates a block, it gets the right to generate a child account. 4. The right to give birth to a child account expires after k blocks, preventing long-term speculation by holding back account generation. 5. To generate a child account, the parent account signs a public key provided by the new owner and thus makes the child account accessible through the corresponding private key. This is done by a special transaction which gets recorded in the blockchain like every other transaction. 6. Every child account must be activated by its owner prior to first use by: 6.1. Signing the latest block of the chain with the owner's private key for authentication. 6.2. Committing to the result of a hash chain with n layers based on a random nonce chosen by the owner: result := h(h(h(...(h(nonce))...))). Both the signature and the commitment are recorded in the blockchain. 7. While the parent account keeps its full balance, the child account starts empty.
B) Minting of blocks 1. All blocks are built by the owners of the minting accounts. Regular accounts have no minting/voting rights whatsoever. 2. Every minting account has the same minting power (one account, one vote). 3. In order to mint blocks, the minting account must have a certain minimum account balance (minimum deposit). This is to prevent existing accounts from being sold/transferred since the old owner who still knows the private key could steal back the stake from the new owner anytime. 4. Minting is performed as a random lottery among all minting accounts, according to the following inequality: h(hash_chain(i), hash chain values of the previous blocks) < t*difficulty
i: index pointing to the current position in the current minter's hash chain (with each created block, i is increased by 1) hash_chain(1..n): denotes the values of the hash layers within the minter's hash chain (while hash_chain(1) equals the committed result from the account's activating transaction A.6.2, hash_chain(n) corresponds to the nonce) t: elapsed time since the previous block difficulty: difficulty factor to regulate block time (mainly depending on the total number of minting accounts)
Every block must contain its minter's hash_chain(i) to be valid. Thus the minter has to peel off a layer of his full hash chain every time he creates a block. Other nodes can easily verify this by hashing the value i times and comparing it to the minter's commitment.
5. With each created block, EVERY minting account that fulfills B.3 receives a fixed-rate interest on its current balance (stake)
System parameters The coin's main parameters are as follows: - Interest rate (B.5) - Minimum account balance to mint (B.3) - Difficulty of the block hash target (B.4) - Timeframe to generate a child account (A.4)
Key points - There will be an actual market for child accounts since the minter of a block has an incentive to generate and sell its child account. This enables new investors to buy into the coin and receive interests. To facilitate the transfer of child accounts, the transaction in A.5 could be extended to include the payment by the buyer. That way account trades could be concluded entirely within the system without the need of a separate exchange platform.
- Used accounts will have no market value and won't be fungible since using them for minting would require the buyer to put his deposit at stake (see B.3).
- Economically, it doesn't make sense for an entity to have more than one account since the actual interest doesn't depend on the number of accounts. While a minter could theoretically buy and keep accounts with the purpose of selling child accounts later on, it isn't rational to do so because of the liquidity costs of holding the parent account until it gets the chance to mint a block. The average holding time will increase as the pool of minting accounts grows due to the decreasing probability for each account to create the next block. Therefore, asymptotically, the market price of a minting account will be determined by the interest rate in the first place rather than by the outlook of creating and selling child accounts.
- As a consequence, the system incentivizes decentralization of the consensus group which will consist of investors instead of miners.
- To gain control over the currency, an attacker has to buy 51% child accounts which is not only expensive but also time-consuming.
- The currency's security obviously increases over time both in terms of capital and time needed to take over control due to the ever-growing pool of minting accounts.
- Even if an attacker manages to get 51% of the minting power, he won't be able to deprive the honest nodes of their interest simply by orphaning all their blocks. The protocol enforces that the interests are paid out to every eligible minting account every time a block is built (B.5). Departing from this rule wouldn't be accepted by the other nodes and thus result in a hard fork.
- Other nodes cannot predict which account will produce the next block thanks to the hash chain. This results in "covert" minting and prevents DDOS attacks against the minting node.
- The hash chains also provide a source of randomness for the creation of the block chain.
- No stake grinding/precomputing attacks are possible since the hash that must hit the target depends on the pre-committed hash chain values of the current and the previous minters. These hashes cannot be influenced by the minter later on. Nor is it possible for an attacker to buy multiple accounts and set the hash chains in a way that increases his chances to mint multiple blocks in series because the hash chain values of the previous minters are hashed all together.
- Long-range attacks: Such attacks are practically infeasible even if the attacker could get hold of a majority of old accounts (and their private keys) that were in use at some point in time. Without knowing the private keys of all the accounts that have been generated henceforth, the attacker cannot recreate the latter due to the required authentication (see A.6.1). As a result, he could only build an alternative chain that would destroy all these accounts and thus the stakes of the current minters. It's obvious that the latter wouldn't accept such a chain, so that the attacker would again fork away.
- Short-time forking attacks: To combat short-time attacks (or more precisely: the nothing-at-stake problem that makes them easier), one could additionally apply punitive schemes like Slasher.
- In order to prevent transaction spam, one could add transaction fees that would have to be burnt for each transaction.
- Burning transaction fees would also counterbelance inflation caused by the interest on minters' stake.
- The fact that inflation rate depends on the percentage of coins held in minting accounts might have a stabilizing effect on the currency's value since a growing popularity among (minting) investors would increase the coin supply rate and thus inflation (and vice versa).
|