Proposal: Distributing minting power by account splitting (Splitcoin)

[alkan]

Splitcoin

Account creation and split
1. Initially, a number of accounts are created, each of which being associated with the same minting power (share of the total minting power).
2. New accounts cannot be created from scratch but must be derived from an existing account by making a split transaction. An account can only be split two times.
3. For a split transaction, the existing account has to sign a new public key that will be linked to the new account. Before using the derived account, the new owner must authenticate it by signing the latest block of the chain with his private key through a special signing transaction.
4. While the existing account keeps its full balance, the derived account will be empty at the beginning.
5. The minting power is split between the accounts: The existing account keeps 3/4 and the derived account gets 1/4.

Minting of blocks
6. In order to mint blocks, an account must have a stake in the currency that is at least as high as its minting power.
7. Minting is performed proportionally to the accounts' minting power, according to the following inequality:
h(h(prev_block),account) < t*minting_power*difficulty
8. With every created block, a fixed-rate interest is assigned (but not yet paid out) to each stakeholder that fulfills point 6.
9. The accrued interests are unlocked when an account successfully mints a valid block.

Rationale: Instead of pushing the boundaries of adverserial impact that the network can tolerate, let's make it impractical to build up the impact necessary to attack the currency.

Account owners have a strong incentive to split their accounts in order to reduce the minimum stake needed to get interests. As the number of accounts is limited, they also have an incentive to transfer/sell derived accounts.

To get 51% of the minting power, an attacker must either a) buy/rent existing accounts or b) get enough new derived accounts.
a) is very risky as the attacker has to put his own stake "at stake": To have enough minting power, the attacker must deposit an equally large sum on his accounts (point 6) that could easiliy be stolen by the seller/lender who still knows the private key.  
b) is not possible even if the attacker can get derived accounts from every existing account since he cannot exceed the remaining accounts' minting power due to points 3 and 5: Let's suppose an attacker that has no accounts yet but who can convince/bribe every existing stakeholder to do a split transaction and give him the derived account. As one account can only be split two times, the attacker can at most get 1/4 in the first and 3/16 (=3/4*1/4) minting power in the second split round, which will leave at least 9/16 (=3/4*3/4) of the minting power in the hands of the other stakeholders.

[alkan]

The proposed model is based on the idea of invitation-based membership as suggested for Swirlds:

Hybrid - the original founders of a swirld each start with an equal voting stake. This is like a
permissioned system. From then on, anyone can join the swirld, if any existing member
invites them, so membership can spread virally. Each member will split their own voting stake
with all those they invite. In this way, a member can invite 1000 sock puppets to be members,
but all 1001 of them together will still have the same total voting stake as the member had
originally. So sock puppets will not help in launching a Sybil attack.

http://www.swirlds.com/downloads/Swirlds-and-Sybil-Attacks.pdf

[alkan]

Some findings about Splitcoin:
- There will be a market for new derived accounts but no market for accounts that have already been used.
- Accounts with higher minting power will usually have a higher monetary value.
- Stakeholders will strive to buy/use an account with as much minting power as they can cover with their stake in order to get a faster payout schedule which
also increases the compound interests.
- Long-time forking attacks: Such attacks are practically infeasible even if the attacker could get hold of all the accounts (and their private keys) that were in use at some point in time. Without knowing the private keys of all the accounts that were derived later, the attacker won't be able to recreate them due to the required authentication (see point 3) and could only build an alternative that destroys them and thus the stake of all the current stakeholders. It's obvious that the latter won't accept such a chain fork which makes them lose their stake.
- Short-time forking attacks: To combat short-time attacks (or more precisely: the nothing-of-stake problem that makes them easier), one could additionally apply punitive schemes like Slasher.

[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).