Nyzo is designed to be a sustainable, fixed-supply, fee-supported cryptocurrency. A 0.25% fee is applied to all standard transactions, rounded up to the nearest micronyzo.
While Nyzo's fixed-percentage fee is fair and reasonable for transactions, it discourages the use of cold wallets for storage. A round trip of coins between a hot wallet and a cold wallet will cost almost 0.5% of the original coin amount in transaction fees. For example, ∩100.000000 will be reduced to ∩99.500625 after two transactions.
Though not related to account fees, the need for in-cycle verifiers to use their private keys to sign messages and blocks raises a concern that key theft could compromise the cycle. In its current state, the entire Nyzo cycle could be compromised by a single catastrophic flaw in the Nyzo verifier software. Key-swapping solutions to keep the verifier's key in memory only are neither complete nor simple to implement. Ultimately, a cold-storage solution for verifier keys, where a verifier never needs to possess its key, would be the only truly secure solution for this problem.
NTTP-1: we propose adding an account-alias mechanism to Nyzo. An account alias would be specified by an authorization transaction that is signed by a primary key. An alias would allow a different key to sign blocks and transactions for the primary key until the primary key revokes the alias. An alias would include a cumulative cap on transfers out of the account, allowing an account holder to limit the amount of coins that could be stolen if the key for the alias were compromised.
To illustrate how the mechanism would work for an in-cycle verifier, let us consider a verifier key as it is currently used in Nyzo. We will call this key primary_key. In the current system, primary_key must be stored on a verifier, and it is used to sign all blocks. All other verifiers know this verifier only by its identifier, which we will call primary_identifier.
With the alias mechanism, primary_key would be stored offline only, and it would sign an authorization transaction granting alias_key permission to sign blocks and transactions for it. The transaction would contain the primary_identifier, the alias_identifier, and the cumulative transaction cap for the alias. The transaction would be signed by the primary_key, and it would be subject to a transaction fee of µ1. If the verifier does not want to allow the alias_key to sign transactions, the transaction cap could be set to ∩0.
If an attacker compromises a verifier and obtains its alias_key, the rightful owner of the verifier could regain control of the verifier by signing a new authorization transaction for a different alias_identifier.
The sentinel would be also able to use an alias_key for every verifier it manages. This means that a sentinel would still be able to offer the same protection that it does now, but the risk of permanently losing control of a large number verifiers due to a single compromised sentinel would be eliminated.
For transactions, let us consider an account that contains ∩1500. An alias could be permitted to transfer ∩10 from this account. If the alias transfers ∩9 from this account, the transaction cap would be reduced to ∩1. If the alias_key is stolen at this point, the attacker would only be able to steal ∩1, not the remaining ∩1491 in the account. At any time, the holder of the primary key can assign a new alias or reset the cumulative transaction cap for the current alias by sending a new authorization transaction.
NTTP-1 was approved by the cycle in a cycle transaction that was processed at block 7085632. The client currently displays only the final signature transaction in this block, and one would need to examine the balance list to see that the transaction was approved and funds transferred from the cycle account. The client will be updated to provide a more informative display of cycle transactions.
The price for this NTTP is currently under consideration.
The implementation time for this NTTP is currently under consideration.