http://cryptonite.info/wiki/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=Mini-blockchain Project - New pages [en]2024-03-29T07:35:33ZFrom Mini-blockchain ProjectMediaWiki 1.23.1http://cryptonite.info/wiki/index.php?title=Advantages_and_potentialAdvantages and potential2014-07-18T18:59:52Z<p>Admin: Added page to wiki</p>
<hr />
<div>__TOC__<br />
<br />
==Scalability==<br />
<br />
The main advantage of the [[mini-blockchain scheme]] is obviously the increased level of scalability. Having the ability to discard all old [[transactions]] is a tremendously useful feature because it means a lot of disk space can be saved and it also means that new nodes can synchronize to the network without having to download every transaction ever made.<br />
<br />
The reason old transactions can be discarded is because transactions are applied to the [[account tree]] as soon as a block is accepted by other nodes, we don't need to go back and reference that transaction at a later time like we do in Bitcoin. Keep in mind there is no such thing as unspent transactions in this scheme, it doesn't even make use of scripts. <br />
<br />
The inputs and outputs in our transactions do not point to other transactions, they simply point to addresses in the account tree, so the transactions aren't linked together the same way they are in Bitcoin, and we can discard all transactions after a safe amount of time has elapsed (enough to make the [[Weaknesses_and_attack_vectors | Secret Chain Attack]] infeasible). <br />
<br />
Of course the account tree will grow over time as new non-empty addresses come into existence but the level of compression and scalability this system offers is truly unbeatable. There is no other known scheme that achieves anything close to this level of scalability, and with this level of scalability comes new possibilities and potential:<br />
<br />
===Micro-Transactions===<br />
<br />
The Bitcoin community generally discourages tiny payment amounts, such as the small transactions made by Satoshi Dice, in fact many people feel that those types of "dust" transactions represent spam because they "bloat" the blockchain. This is a problem for Bitcoin because nodes require the full blockchain before they can synchronize with the network. However blockchain bloat isn't such a problem for [[Cryptonite]] because in this scheme old transactions can be discarded and new nodes don't need the full blockchain to sync with the network, they only need transactions younger than the [[cycle time]].<br />
<br />
So because of this we have more freedom to support smaller transactions and a higher transaction rate overall. However there is one small catch: although we can support small value transactions, we can only be so lenient when the receiving address already exists in the account tree. The reason for this is because we don't want to go filling up the account tree with many low balance addresses because that is our schemes version of "dust". The solution is a simple rule: if sending to an address which does not already exist in the account tree the amount being sent cannot be lower than the transaction fee.<br />
<br />
===Transaction Messages===<br />
<br />
Like micro-transactions, although possible, the Bitcoin community tends to discourage the storage of text messages in the blockchain because they must be stored forever. The early versions of the bitcoin-qt GUI included a feature for including a custom text message with your transaction but it has since been removed from the GUI in order to slow down blockchain bloat. Including a custom message with a transaction is a very common and useful feature that can play an important role in many merchant scenarios, so it's clearly important for any currency to support such a common and useful feature.<br />
<br />
The scalable nature of the mini-blockchain scheme relieves us from the concern of blockchain bloat and we can have full support for transaction messages for the same reason we can support micro-transactions: all the transactions containing the messages can be forgotten by the network after some relatively short period of time. Cryptonite has native support for attaching custom messages to transactions, since we don't use script the message field is embedded into the structure of the transaction, meaning you cannot have a different message for each output, only one message per transaction.</div>Adminhttp://cryptonite.info/wiki/index.php?title=AccountAccount2014-07-18T12:25:42Z<p>Admin: Added page to wiki</p>
<hr />
<div>An account is simply a leaf node in the [[account tree]]. Each account is connected to exactly one address, so you may hear the words "account" and "address" used some what interchangeably, which can get quite confusing since Bitcoin has it's own special definition of account which is different from the type of account being described on this page. Each account holds 5 values: address, balance, age, limit, futurelimit. When the [[Withdrawal_limits | withdrawal limit]] of an account is updated the age will be updated, and the new limit value will be saved in the futurelimit field. When the age is more than 100 blocks futurelimit will be copied into the limit field the next time a transaction is made.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Withdrawal_limitsWithdrawal limits2014-07-16T09:06:55Z<p>Admin: small grammar fix</p>
<hr />
<div>A withdrawal limit is exactly what it sounds like, a limit set on addresses dictating the maximum number of coins which can be withdrawn from an address in a certain amount of time. The main downside is that a few extra fields need to be added to the [[account]] structure to enable the withdrawal limit system.<br />
<br />
The limit is self-set by account owners using a special [[transactions|transaction]] and the default value for new accounts is unlimited. The purpose of such a system is to help prevent double spending, so that merchants can have more faith in transactions with zero or a small number of confirmations.<br />
<br />
==How it Works==<br />
<br />
A brief outline of how withdrawal limits work:<br />
<br />
# Send the network a special transaction to modify the withdrawal limit of your account. Limit is specified as number of coins per block, and is saved into queue field. Such change will take effect in eg. 100 blocks and after that time the queued value overwrites the actual withdrawal limit value.<br />
# Network accepts the special transaction and after 100 blocks it will reject any transaction that would cause newly specified limit to be exceeded.<br />
<br />
A merchant can ensure he will receive funds by:<br />
<br />
# Checking that there is no queued withdrawal limit change on sending account.<br />
# Check that sending account balance is high enough so it can't be emptied too fast.<br />
# Ensure transaction is not low priority and has propagated enough in network.<br />
<br />
==In Practice==<br />
<br />
Withdrawal limits are implemented in [[Cryptonite]] and as a result quite secure 0-confirmation transactions are possible. Imagine that a buyer wants to purchase something from a merchant, but neither of them want to wait for confirmations. Before this can happen the buyer must already have an address which has a withdrawal limit set on it. The buyer can achieve this using the following [[Cryptonite_API | API command]]:<br />
<br />
<pre>./cryptonited setlimit "10.0000000000ep" C59FG7kCspznKMhvpLWkAXCDLr4fnmEZxx</pre><br />
<br />
Now with this withdrawal limit in place the buyer can only withdraw 10 coins per block at most, so if the buyer has a balance of 500 coins it will take at least 50 blocks to empty the address. The withdrawal limit will be updated immediately in this case because the new withdrawal limit is lower than the last, however the change will be delayed by 100 blocks if the new withdrawal limit is greater than the last.<br />
<br />
Now the buyer can send payment to the merchant and once the merchant receives the transaction they can lookup the withdrawal limit and the balance of the address which they received payment from. Since the withdrawal limit and the balance are stored in the [[account tree]] this isn't a very computationally expensive task. So to lookup the details of the buyers address the merchant can use the following API command:<br />
<br />
<pre>./cryptonited listbalances 5 [\"C59FG7kCspznKMhvpLWkAXCDLr4fnmEZxx\"]</pre><br />
<br />
This will return details about the buyers address, ignoring transactions with less than 5 confirmations. What the merchant really cares about is the "balance, "limit", and "futurelimit" fields. If the limit field is 10 but the balance is 500 then the merchant knows that the address cannot be emptied quickly. The merchant must rebroadcast the buyers transaction to ensure that it gets into a block quickly enough.<br />
<br />
The merchant can also check that there is no pending update to the buyers withdrawal limit by making sure the futurelimit field is the same as the limit field. The futurelimit field is used to delay any increases to the withdrawal limit, so when it holds a value different to the value of the limit field you know there must be a pending update to the withdrawal limit. And there you have it, fast yet secure transactions.<br />
<br />
==Why it Works==<br />
<br />
Double spending is possible because you can send one transaction to a merchant while simultaneously sending another one to miners which moves all your coins to another address. But with withdrawal limits you cannot send all your coins at once and this can help secure merchant transactions.<br />
<br />
Suppose you have 100 coins in your account with a withdrawal limit of 1 coin per block. To send a secure 0-confirmation transaction of 1 coin you sign a transaction to send 1 coin to the merchant and it's considered valid if included in one of next 10 blocks (or whatever amount is deemed secure).<br />
<br />
If an attacker tries to double spend his coins in an alternative blockchain he would only be able to move 1 coin from his account per block, so even if his network branch is accepted as the longest, the merchant transaction will still be valid and included in a later block. To successfully make a double spend the attacker would need to exclude the merchants transaction from the next 10 blocks.<br />
<br />
However, if the double-spender issues a very large number of transactions, there's a chance that the legitimate transaction could get excluded from all 10 blocks. There are ways this could potentially be solved, but with the right rules in place there's very little chance an attacker could actually keep a transaction out of the blockchain so long due to the way transactions are prioritized based on age.<br />
<br />
However it is important to keep in mind that this withdrawal limit system is not perfect and should not be trusted absolutely by merchants. Cryptonite uses this simple type of withdrawal limit system, so while it can be much safer to accept 0-confirmation transactions in Cryptonite, it's not totally secure and it may be possible to double spend given enough effort on the part of the attacker.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Weaknesses_and_attack_vectorsWeaknesses and attack vectors2014-07-16T09:03:46Z<p>Admin: fixed up some wording and spelling</p>
<hr />
<div>==Weaknesses==<br />
<br />
===Less Flexible===<br />
<br />
Script is not used within the mini-blockchain scheme. Since the [[account tree]] holds the final balance of all non-empty addresses and is not reliant on interlocking transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the [[mini-blockchain]] are discarded after a relatively small period of time (the length of the mini-blockchain [[cycle time]]).<br />
<br />
However, it is still possible to allow more complex types of transactions such as a [[multi-signature transactions]], and by not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.<br />
<br />
It's also clear that most people really just want simple types of transactions, most people don't even use multi-signature transactions, what they mostly want is basic banking tools. If we want this extreme level of scalability we're going to have to give up some flexibility, and that's not such a bad trade off considering that Bitcoin already has pretty strict rules about what transactions are considered standard format.<br />
<br />
==Attack Vectors==<br />
<br />
===The Secret Chain Attack===<br />
<br />
If an attacker had enough hashing power he could generate a fake chain in secret using the real [[proof chain]] but a fake [[account tree]]. He would need to out-pace the real mini-blockchain for a full cycle until there's no evidence left to indicate his account tree is fake and then start broadcasting the fake chain.<br />
<br />
This wont affect older nodes who have been validating blocks for longer than the cycle of the [[mini-blockchain]] because they can detect the fake chain or simply ignore super long forks. In [[Cryptonite]] existing nodes will just stick with the chain they have if the origin point of the fork appears to be older than the cycle time.<br />
<br />
So there's no way the attacker could trick existing nodes to accept his fake chain, but new nodes are still at risk. New nodes have no way of determining which is the valid chain because they have no history of what happened before the oldest block in the mini-blockchain. Using some sort of consensus mechanism is not perfect either.<br />
<br />
'''Minimizing risk of attack success'''<br />
<br />
If a new node detects multiple chains which originate from the same proof chain it can try to query other nodes for older blocks all the way to the block in which the competing chains diverged and if no one around has this long history (no one is required to have it) the user can either take a chance on the chain the nodes recieves first, or refuse to participate in the network until one of the chains has won the race.<br />
<br />
The user will be warned when any type of fork longer than 24 hours is detected. The user could also manually point the node to the correct chain with the use of a community checkpoint. The community will release a new checkpoint as quickly as possible if this situation does arise. When the checkpoint is released new nodes will be able to safely join the network and help the other nodes work against the attacker.<br />
<br />
Since this attack will only put new nodes at risk and since it will most likely never happen, let alone succeed, this strategy is an acceptable contingency plan for dealing with the attack. Worse case scenario is that new nodes have to wait until the situation has been resolved or wait until a new checkpoint is released which points to the real chain. Anyone already running a node would not be affected in any way.<br />
<br />
In summary, this attack is unconcerning and unlikely for several reason:<br />
<br />
# requires an incredible amount of hashing power<br />
# requires that no one has historic blockchain data<br />
# only nodes which haven't synced for more than a week are susceptible<br />
# when all else fails new nodes can resolve the problem with a checkpoint<br />
# attack will never succeed due to checkpoints and probably could never be profitable<br />
<br />
<br />
===Double-Spending===<br />
<br />
With most crypto-currencies which use a typical blockchain scheme merchants are protected from double-spending to a degree which depends on how many confirmations they want before deciding the payment is valid. The more confirmations a transaction has, the deeper it is buried into the blockchain and the less likely it is to be orphaned.<br />
<br />
However if a merchant is willing to accept a 0-confirmation transaction an attacker can exploit this oversight and send multiple payments to different addresses, emptying their balance before the merchant can get paid. This same weakness applies to the mini-blockchain scheme however we have multiple methods of minimizing the risk of it happening.<br />
<br />
'''Minimizing risk of attack success'''<br />
<br />
The primary method for reducing the risk of double-spending is to implement [[withdrawal limits]] which will help make low-confirmation transactions more secure. By allowing users to set a withdrawal limit on their accounts a merchant can see the balance and withdrawal limit of the buyers address and be assured that the buyer cannot empty their account within a small amount of time.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Transaction_typesTransaction types2014-07-16T09:01:31Z<p>Admin: Added page to wiki</p>
<hr />
<div>There are 3 main types of [[transactions]] used in the mini-blockchain scheme:<br />
<br />
# Send coins to other addresses<br />
# Claiming block reward<br />
# Change [[Withdrawal_limits | withdrawal limit]]<br />
<br />
Changing the withdrawal limit is a special type of transaction where the output address is the same as the input. A transaction using a multi-signature address as an input is similar to a normal transaction but requires multiple signatures for verification. See the [[multi-signature transactions]] page for more information.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Transaction_signingTransaction signing2014-07-16T08:58:12Z<p>Admin: Fixed up stupid wording.</p>
<hr />
<div>__TOC__<br />
<br />
A signed [[Transactions | transaction]] is essentially some signed message very similar to a Bitcoin transaction, but without any scripting. It's a set of instructions for modifying the balance sheet (the [[account tree]]). To verify a withdrawal from any [[account]], the owner of the account must sign the transaction with the private key which corresponds to the account address. The [[mini-blockchain]] is designed in such a way, that old transactions can be forgotten, so transaction signing must be done in a way that prevents rebroadcasting of old forgotten transactions while not affecting the ability of the system to handle multiple concurrent transactions. <br />
<br />
==Preventing Reuse of Signed Transactions==<br />
<br />
A scheme with limited duplicate checking:<br />
* Lets define N to be less than minimum number of historical blocks every node is required to keep (see [[cycle time]]).<br />
* Creator of transaction puts latest block number inside txn and signs it. Lets call this block number K.<br />
* Network treats such transaction as valid if it is included in one of blocks from K+1 to K+N.<br />
* If the same transaction with the same signature was already included in one of past N blocks then it is rejected.<br />
<br />
This scheme has the following advantages:<br />
* Does not affect concurrent transaction generation.<br />
* Can be used to make time locked transactions ([[Cryptonite]] allows delay of no more than 5 blocks to prevent DoS attacks).<br />
* Nodes can incorporate transactions from abandoned branches into main chain if reorganization is smaller than N blocks.<br />
* It helps to make [[withdrawal limits]] work which makes double-spending considerably harder.<br />
<br />
So, in order to make sure the same signed transaction isn't processed by the network more than once, the transaction must also contain a “lockheight” field. The transaction becomes invalid once the lockheight is outside the range of blocks which nodes are required to keep (lets call this the blocks “in view”), and same txid cannot be included twice in any of the blocks which are in view. This makes it impossible to use the same txid twice. However this solution requires that the txid is not malleable.<br />
<br />
==Removing Transaction Malleability==<br />
<br />
One of the reasons Cryptonite does not suffer from transaction malleability is because it doesn't use scripting, but more importantly it doesn't include the signatures when hashing a transaction because signing the same data with the same key produces different signatures each time. The sender will sign the txid, but signing it many times in no way alters the txid, only the signatures. Thus attempting to alter the contents of the transaction will always change the txid and as a result invalidate the signature(s).</div>Adminhttp://cryptonite.info/wiki/index.php?title=TransactionsTransactions2014-07-16T08:54:57Z<p>Admin: fixed transaction types link</p>
<hr />
<div>Bitcoin keeps track of address balances simply by reading through the blockchain to see what has happened, it's a continual ledger instead of a self contained balance sheet. Bitcoin transactions use a system which include “inputs” and “outputs” and the inputs of most new transactions usually reference the outputs of previous transactions. The [[mini-blockchain scheme]] uses the basic input and output concept but the inputs point to [[Account | accounts]] in the account tree and the outputs also refer to accounts in the account tree.<br />
<br />
The input accounts will fund the coins which are sent to the output accounts. This operation will cause the balance of the input accounts to decrease and the balance of the output accounts to increase. Fees are still used as normal to give priority to transactions and provide incentive to miners. Obviously a transaction should not be accepted as valid if it reduces the balance of any account below 0, or if it requests anything which conflicts with the value of any balance, or it tries anything it doesn't have permission to do.<br />
<br />
== Technical details ==<br />
<br />
A transaction represents one atomic modification on the account tree. For example: "Move X coins from account A to account B" or "Update withdrawal limit of Account C", etc. Modifications made by single transactions are virtually limitless, but they must have a few important properties. Transaction types used by this scheme can be found on the [[transaction types]] page. <br />
* Transactions need to be easily reverted, because we need an efficient way of handling [[Blockchain_reorganization | blockchain reorganizations]].<br />
:When blockchain reorganization occurs, nodes must rollback all transactions which were included in the orphaned branch. This is achieved with an [[inversion database]] which holds instructions for undoing changes made to the account tree.<br />
* There must be a mechanism for authorization of modification which can be checked by anyone. For this we use a ECDSA signature scheme similarly to bitcoin.<br />
* The [[mini-blockchain]] is designed in such a way, that old transactions can be forgotten, so [[transaction signing]] must be done in a way that prevents rebroadcasting of old forgotten transactions while not affecting the ability of the system to handle multiple concurrent transactions.<br />
: An example of a bad way to do it is to include previous transaction hashes as a means of making transactions globally unique. Doing it that way would disallow concurrent transaction signing.<br />
<br />
==Does this scheme use script?==<br />
<br />
Script is not used within the mini-blockchain scheme. Since the account tree holds the final balance of all non-empty addresses and is not a continuous ledger of transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the [[mini-blockchain]] may be discarded after a relatively small period of time (the length of the mini-blockchain [[cycle time]]).<br />
<br />
However, it is still possible to allow more complex types of transactions such as a [[multi-signature transactions]]. By not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.<br />
<br />
At present the Bitcoin network only accepts a couple of standard scripts for basic types of transactions and every other type of script is considered non-standard. On top of that new script formats are very hard to get standardized. In reality it's best to include the types of transactions that you want to allow before you ever release the client, instead of trying to gradually phase in new types of transactions.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Account_tree_pruningAccount tree pruning2014-07-16T08:51:19Z<p>Admin: Added page to wiki</p>
<hr />
<div>The bulkiest part of the [[mini-blockchain scheme]] is actually the [[account tree]]. Given enough time the account tree may become filled with many low balance accounts and it would be advantageous if we could prune this type of “dust” from the tree once the accounts were old enough. There are several ways this can potentially be achieved but none of them are remotely simple or easy to implement. The best approach seems to be one where you collect “account maintenance” fees for maintaining an account in the account tree. <br />
<br />
The fees would be collected when a withdrawal is made from an account, and included along with the transaction fees. The fee would be calculated based on the age of the sending account. In this way low balance accounts eventually reach a balance of 0 and get pruned from the tree. Even if no withdrawals are made from the account we could have a system for allowing the pruning of accounts which would have a non-positive balance had they been paying their account maintenance fees.<br />
<br />
The benefit of this type of system is that it places a cost on storing data in the account tree, which is economically beneficial, and it helps keep the account tree compact. The other useful feature of this system is that we can feed the maintenance fees back into the “[[coinbase account]]” (pays out block rewards) and ensure that the block reward never reaches 0, without actually inflating the money supply, just by recycling coins back through the mining system, maintaining a finite money supply while not cutting off the minting process.<br />
<br />
Note: [[Cryptonite]] does not implement account tree pruning.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Proof_chainProof chain2014-07-16T08:46:16Z<p>Admin: Added page to wiki</p>
<hr />
<div>[[File:Mini-blockchain_headers.jpg|right|thumb|300px|Figure 0-a: Diagram of proof chain]]<br />
__TOC__<br />
<br />
The proof chain is 1 of the [[3 core components]] of the [[mini-blockchain scheme]] and provides our 3rd [[functions of the blockchain|function of the blockchain]]. It is essentially just a chain of block headers. When nodes discard the old blocks, they will not discard the block headers, only the transactions. So the [[mini-blockchain]] is essentially a blockchain pruned of all but the most recent transactions. This means all nodes can still use the chain of block headers to verify the best mini-blockchain with the highest cumulative difficulty, and thanks to the [[account tree]] they don't need old transactions to calculate address balances.<br />
<br />
The way the proof chain works is that it essentially acts as a container of spent network energy because the proof-of-work solutions (or “proofs”) are chained together in such a way that each proof is connected to the one before it and each proof corresponds to the block it was created for. The proof chain proves which mini-blockchain has the most long-term computational backing. We are able to store this proof chain indefinitely because it is extremely small and trimmable and we don't need to store all the block data along with it.<br />
<br />
We have what is essentially a normal blockchain, so mining can work the same way as it does in Bitcoin. Nodes must hash the block headers and search for resulting hashes below the current target. It's possible to discard old transactions and store only a chain of block headers because proving the solution doesn't rely upon knowing the transactions in the block. It's secure for the same reason Bitcoin is secure, each proof in the proof chain feeds into the next proof, making it nearly impossible to generate a fake proof chain.<br />
<br />
The master hash needs to be embedded in the block headers as detailed in figure 0-a because it allows the nodes to verify the [[transactions]] in the block and make sure their account tree has been altered correctly by the block. The master hash stored in the block header is calculated after the transactions in the block have been applied to the account tree. We can work our way from the start of the proof chain up to where it feeds into the back-end of the mini-blockchain and we can verify that the most recent blocks we have are valid.<br />
<br />
Without the proof chain it's impossible to tell which blockchain and account tree should be trusted, the proof chain essentially helps to secure the entire network and point nodes to the right chain. It gives us some historical data about what happened before the oldest block in the mini-blockchain, and it's the best type of data: proof-of-work. We can work our way from the start of the proof chain up to where it feeds into the back-end of the mini-blockchain and we can verify that the oldest block in the mini-blockchain has the backing of the proof chain.<br />
<br />
==Security provided by proof chain==<br />
<br />
Since the proof chain proves which mini-blockchain has the most long-term computational backing, an attacker cannot sit around forever generating a fake proof chain because the proof chain must feed into the mini-blockchain. So if an attacker tries to create a totally invalid mini-blockchain they will also need a strong proof chain to go along with it. This essentially takes us back to the level of security of offered by a typical full blockchain scheme, but it's still not perfectly secure in all situations.<br />
<br />
The main problem is that an attacker could build on the legitimate proof chain in secret using an invalid account tree, and then release the secret chain to the network when the they think it's so long that no one will have history going back that far. In that situation new nodes would not be able to detect which chain was real. We call this the "The Secret Chain Attack". If all transactions can be discarded after a week (as in [[Cryptonite]]) the attacker must maintain the majority of the hashing power for more than a week (in secret).<br />
<br />
We believe even if this attack does happen it wont be catastrophic because:<br />
<br />
# the attack will only affect nodes who haven't synced with the network in more than a week, all other nodes can detect the attack and reject the fake chain.<br />
# a possible Secret Chain Attack underway can be detected by new nodes, although they cannot know which chain is the real one.<br />
# the release of "community checkpoints" will point nodes to the correct chain in the off chance this attack did happen, thereby making it a worthless attack.<br />
<br />
See [[weaknesses and attack vectors]] page for more info.<br />
<br />
==Trimming the proof chain==<br />
<br />
It's possible to trim down the proof chain because after a sufficient period of time has passed it wont reduce the total cumulative difficultly of the chain enough to pose a problem. Assuming the trimmings are not done periodically the security risk should be low once the chain is long enough. There's no real reason to store proofs which go right back to original genesis block, we can simply update the genesis data in the source code after a sufficient period of time, without requiring any type of forking to take place.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Network_synchronizationNetwork synchronization2014-07-16T08:32:55Z<p>Admin: Added page to wiki</p>
<hr />
<div>Network synchronization is achieved in 4 steps:<br />
<br />
# Acquire [[proof chain]] with the highest cumulative difficulty.<br />
# Acquire [[mini-blockchain]] which is associated with proof chain.<br />
# Build [[account tree]] by requesting slices and verifying the hashes.<br />
# Use recent [[transactions]] to complete sync of account tree.<br />
<br />
First the node will use a “headers first” approach to locate the chain with the highest cumulative difficulty. Then it will acquire a collection of the most recent blocks connected to those block headers. Then it will attempt to acquire slices of the account tree until it has a complete tree. The account tree structure allows the node to prove it has received complete slices so that the node can be sure it has the all the [[Account | accounts]]. Finally, the node can use recent transactions to update all slices of the tree to the latest master hash.<br />
<br />
No one is required to store old account tree data but the node must build an account tree which is fully consistent with the master hash they have; they can't mix and match slices associated with different master hashes. That is why the height of each slice must be determined, so that we know what transactions need to be applied in step 4. Since all slices contain the master hash, when a node requests a particular slice it can match the slice against a particular block by comparing the hashes.<br />
<br />
Nodes will generally attempt to acquire slices synced near the point where it becomes safe to discard old transactions. Other nodes are able to provide these old slices because because they can undo recent changes to the account tree and generate old slices upon request. New nodes will attempt to build an account tree at such an old point because they need to be able to create a large “[[inversion database]]” which holds instructions for undoing changes made to the account tree, which is useful for generating old slices and [[Blockchain_reorganization | handling forks]].<br />
<br />
In simple terms, new nodes will attempt to build a complete account tree around the point where old blocks can be pruned, then it will “[[fast forward]]” using transactions from the most recent blocks and at the same time build an inversion database, so that it has inversions going back to the point where inversions are no longer needed. Of course this description of the process is very much simplified and you'd have to read the source code of Cryptonite for a more detailed technical understanding of how synchronization works.<br />
<br />
Notice this process does not rely upon much examination of blocks, one trusts the blocks they have because the proof chain backs them. It's extremely easy to verify the proof chain and once that is complete the node only needs to make sure the blocks it gets match the proof chain. As the account tree is being built the only thing which matters is that it ends up having the master hash of the latest block. Once that is complete and the node is synchronized it can begin to update the account tree normally by accepting valid blocks.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Multi-signature_transactionsMulti-signature transactions2014-07-16T08:25:01Z<p>Admin: changed coin values to 10 dec places</p>
<hr />
<div>[[Cryptonite]] has full native support for multi-signature addresses and transactions, which require multiple parties to sign a transaction before it is considered valid. Multi-sig transactions are useful in many real world situations, especially for consumer protection and escrow schemes. Unfortunately there isn't yet a user friendly GUI for creating multi-sig addresses and using them, but it will get easier.<br />
<br />
Here's how to try it on the testnet (remove -testnet flags to do it for real):<br />
<br />
<pre>./cryptonited -testnet createmultisig 2 [\"cBCYJhy9Mxg85ujVpLsrvUiXQs9xh2aRmP\",<br />
\"cKyUeZowQg8jPBJg1oEcVnMkcqNxK6GWw9\",\"c6JjVRGAtLkheEHSr5ddx2Ev81cLL2h4CK\"]</pre><br />
<br />
Where the 2 is how many signatures are required to spend from the address. Can be any number > 0. Then there is an array of addresses corresponding to "authorized" senders. This command produces a mult-sig address as shown below. Anybody can send to this immediately.<br />
<br />
<pre>{<br />
"address" : "c555wVcgpmQ6f5BGJfzBspFJgXuXSnMKAm"<br />
}</pre><br />
<br />
Spending the multisig is more difficult. First you must create a raw unsigned transaction where the input is the the multisig address. Outputs can go anywhere, different multisig addresses, whatever.<br />
<br />
<pre>./cryptonited -testnet createrawtransaction "{ \"c555wVcgpmQ6f5BGJfzBspFJgXuXSnMKAm\":<br />
\"25.0010000000ep\" }", "{ \"cLTTCchBofchto7mSCcpMnyW18v59LgVwH\":\"10.0000000000ep\" , <br />
\"cQcTLJyTKQ7wJJHVNyZNJCtPdzF1VscvDg\":\"15.0000000000ep\" }"</pre><br />
<br />
This returns a really nice hex string of the transaction. Like:<br />
<br />
<pre>01000000012835a1a195f6c84a38f69d0df18568c5fe8ba948a07f049500000000000200ca<br />
9a3b00000000d0fa6ab67c8da4b8c33c3d7ae6756bef02ea304a002f685900000000fe8ec63dc8f6<br />
08f5f23ce88de8616cddca19ae7000e42b000000000000</pre><br />
<br />
Then to prepare the transaction for signing you would run:<br />
<br />
<pre>./cryptonited -testnet setuprawtransaction "01000000012835a1a195f6c84a38f69<br />
d0df18568c5fe8ba948a07f049500000000000200ca9a3b00000000d0fa6ab67c8da4b8c33c3d7ae<br />
6756bef02ea304a002f685900000000fe8ec63dc8f608f5f23ce88de8616cddca19ae7000e42b000<br />
000000000" "{\"0\":[2,[\"cBCYJhy9Mxg85ujVpLsrvUiXQs9xh2aRmP\",<br />
\"cKyUeZowQg8jPBJg1oEcVnMkcqNxK6GWw9\",\"c6JjVRGAtLkheEHSr5ddx2Ev81cLL2h4CK\"]]}"</pre><br />
<br />
This command also requires a description of the multisig address. All authorized addresses and the number 2 again signifies the number required to send. Then it will generate:<br />
<br />
<pre>01000000012835a1a195f6c84a38f69d0df18568c5fe8ba948a07f0495000000003d0035c<br />
2829b1b64802610277894a22830b4d9abfd476b6f4e8bb50c6c12ff0b28f97a7dde4960143058cb<br />
affa68c577a5c5e098e3f247e8c9d423c304860200ca9a3b00000000d0fa6ab67c8da4b8c33c3d7<br />
ae6756bef02ea304a002f685900000000fe8ec63dc8f608f5f23ce88de8616cddca19ae7000e42b<br />
000000000000</pre><br />
<br />
Life is easier from now on. Signers don't need to know the multisig construction anymore because it has been encoded in the transaction. So you pass the hex around to people with the keys to actually sign the thing by running:<br />
<br />
<pre>./cryptonited -testnet signrawtransaction 01000000012835a1a195f6c84a38f69d0d<br />
f18568c5fe8ba948a07f0495000000003d0035c2829b1b64802610277894a22830b4d9abfd476b6f4<br />
e8bb50c6c12ff0b28f97a7dde4960143058cbaffa68c577a5c5e098e3f247e8c9d423c304860200ca<br />
9a3b00000000d0fa6ab67c8da4b8c33c3d7ae6756bef02ea304a002f685900000000fe8ec63dc8f60<br />
8f5f23ce88de8616cddca19ae7000e42b000000000000 <br />
"{\"0\":\"2\"}"</pre><br />
<br />
Here the last JSON object simply describes that the first input of the transaction is a 2 required multisig. It will then spit out something like:<br />
<br />
<pre>{<br />
"hex" : "01000000012835a1a195f6c84a38f69d0df18568c5fe8ba948a07f0495000000009<br />
70204b57ae0c446cca8e16b52251dbe87ff18c6755b21c4b99cdbb7f7aa7641e00aa58751e30f576<br />
2d10598c99fe0054a73627a36948e8ce578bd9ac0bde79a3c1d35045b2ec50645b5d1c0de41b77e7<br />
001562bd234c98d168f22cabe8f65ebf25c21cc529b060a920100bde39322614d5056689e6daba4d<br />
b65d0fa2827e74628c9e95acbaffa68c577a5c5e098e3f247e8c9d423c304860200ca9a3b0000000<br />
0d0fa6ab67c8da4b8c33c3d7ae6756bef02ea304a002f685900000000fe8ec63dc8f608f5f23ce88<br />
de8616cddca19ae7000e42b000000000000",<br />
"complete" : true<br />
}</pre><br />
<br />
<br />
If complete is false, this hex must be given to the next user for further signing. If complete is true, then the multisig transactions have been sufficiently signed for submission and your ready to send it out to the network as follows: <br />
<br />
<pre>./cryptonited -testnet sendrawtransaction 01000000012835a1a195f6c84a38f69d0d<br />
f18568c5fe8ba948a07f049500000000970204b57ae0c446cca8e16b52251dbe87ff18c6755b21c4b<br />
99cdbb7f7aa7641e00aa58751e30f5762d10598c99fe0054a73627a36948e8ce578bd9ac0bde79a3c<br />
1d35045b2ec50645b5d1c0de41b77e7001562bd234c98d168f22cabe8f65ebf25c21cc529b060a920<br />
100bde39322614d5056689e6daba4db65d0fa2827e74628c9e95acbaffa68c577a5c5e098e3f247e8<br />
c9d423c304860200ca9a3b00000000d0fa6ab67c8da4b8c33c3d7ae6756bef02ea304a002f6859000<br />
00000fe8ec63dc8f608f5f23ce88de8616cddca19ae7000e42b000000000000<br />
</pre><br />
<br />
And it will spit out a txid like this if successful:<br />
<br />
<pre>8ca0108bf935f2705976f56d7fa52fc32f68fab5f20e9f7400e3ccc55b27cd81</pre></div>Adminhttp://cryptonite.info/wiki/index.php?title=Mini-blockchain_schemeMini-blockchain scheme2014-07-16T08:11:18Z<p>Admin: Added content to main page</p>
<hr />
<div>The mini-blockchain scheme is a variant of the Bitcoin protocol which aims to eliminate the need for storing a full blockchain and overcome the "blockchain bloat" problem. The [[mini-blockchain]] is essentially like any other Bitcoin-based blockchain except that old blocks can be pruned from the chain. The block headers are kept as a PoW record but all old transactions can be discarded.<br />
<br />
Address balances are managed separately in a hash tree structure called the [[account tree]] which is essentially a self-contained balance sheet designed to keep track of all non-empty addresses. New blocks act upon the entries in the account tree to perform transactions and the [[master hash]] of the account tree is embedded into the block headers to ensure consistency and agreement between nodes.<br />
<br />
Since a proof-of-work is required for each new block, the account tree is updated in relatively periodic intervals of time. Since the master hash of the account tree is embedded into the block headers, the mini-blockchain helps to protect the account tree from malicious changes. However if we're discarding old blocks the mini-blockchain is not secure unless we keep the block headers.<br />
<br />
So to secure the whole system from attackers, we use a chain of interlocking proof-of-work solutions termed the [[proof chain]]. The proof chain is simply a chain of block headers which encapsulate all the energy expended by the network on a given chain. The chain of block headers feeds into the mini-blockchain and acts to secure it and the account tree against attackers, even without old transactions.<br />
<br />
The mini-blockchain, the account tree, and the proof chain, form the [[3 core components]] of the overall scheme and work together to create a highly secure and robust P2P transaction system very much like the Bitcoin system but with a much better level of scalability, bandwidth, and speed. By optimizing each core component to perform a certain [[functions of the blockchain|function of the blockchain]] we achieve unparalleled compression with a high level of security.</div>Adminhttp://cryptonite.info/wiki/index.php?title=3_core_components3 core components2014-07-16T08:10:20Z<p>Admin: Added page to wiki</p>
<hr />
<div>The [[mini-blockchain scheme]] can be divided into 3 core components which form the foundation of the scheme and work together to provide a highly efficient and secure crypto-currency scheme. The 3 core components of the scheme are designed to satisfy the 3 [[functions of the blockchain]] in the most efficient manner possible.<br />
<br />
'''The 3 core components of the scheme:'''<br />
<br />
# The [[Mini-blockchain]] (provides 1st function of blockchain)<br />
# The [[Account tree]] (provides 2nd function of blockchain)<br />
# The [[Proof chain]] (provides 3rd function of blockchain)</div>Adminhttp://cryptonite.info/wiki/index.php?title=Mini-blockchainMini-blockchain2014-07-16T08:05:13Z<p>Admin: Fixed up stupid wording.</p>
<hr />
<div>[[File:mini-blockchain.jpg|right|thumb|350px|Figure 0-a: Mini-blockchain diagram.]]<br />
<br />
The mini-blockchain is 1 of the [[3 core components]] of the [[mini-blockchain scheme]], it performs the 1st [[functions of the blockchain|function of a blockchain]]. The mini-blockchain is essentially just a normal blockchain, except that we don't need to keep a copy of historic transactions. It isn't truly finite, because changing the max block size could increase the average size of the mini-blockchain. A mechanism for achieving a [[dynamic max block size]] is actually a part of [[Cryptonite]] but it's not a necessary part of the scheme.<br />
<br />
If we are going to keep track of the [[account tree]] with a set of node hashes and a [[master hash]], we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of [[transactions]] which are inserted into the database in periodic intervals of time. Without having the transactions solved in groups of transactions as blocks we have no viable method of maintaining the account tree. This creates an inherent need for a blockchain, but since we can discard old transactions, let's call it a “mini-blockchain”.<br />
<br />
Bitcoin requires the full blockchain because that's the only real way to determine the full balance of all the addresses. However we have the account tree to fulfill the task of managing account balances and recording the ownership of coins. We don't need the full thing, we can throw away old transactions and save an immense amount of disk space. However we do keep a few hundred or a few thousand of the newest transactions and that makes our mini-blockchain. The mini-blockchain also provides us with a level of security.<br />
<br />
Each block has the master hash embedded in the header and we can verify each block in the mini-blockchain starting from the beginning, making sure the transactions in each block always correspond to the master hash in the previous block. Since there is a proof-of-work process required for each block before it will be accepted into the mini-blockchain, it becomes extremely difficult for an attacker to generate a fake mini-blockchain. Although difficult, if we totally delete old transactions, it is far from impossible.<br />
<br />
With Bitcoin we can start at the very beginning and work our way up to the latest point because we have the full blockchain. If an attacker creates a new mini-blockchain from the oldest block available, new nodes would have trouble telling it apart from the real mini-blockchain, because before that oldest block they have no history of what happened. The attacker can spend as much time as they need building up the cumulative difficulty of their mini-blockchain because it's not an ever-growing chain they have to out-pace.<br />
<br />
The attacker could then start broadcasting the fake chain and it might propagate enough to impose a risk of becoming the main chain. The [[proof chain]] solves this by providing a mechanism which can act as a container for storing the long term proof-of-work history so that we can calculate the total cumulative difficulty of any chain. Instead of totally deleting old blocks we must maintain the block headers so that we can always trace the history of any given chain and compare the total cumulative difficulty each chain.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Master_hashMaster hash2014-07-16T06:55:15Z<p>Admin: Added page to wiki</p>
<hr />
<div>A typical hash tree structure will have a root/master hash which is derived from all the other hashes in the tree. The master hash represents the digest/fingerprint of the entire hash tree and is used to detect any changes to any part of the data in the tree and thus achieve consensus on its state.<br />
<br />
Within the [[mini-blockchain scheme]], the term master hash refers to the hash which encapsulates all other hashes within the [[account tree]]. Miners apply all the transactions in their blocks to the account tree and include the resulting master hash in the block header so that others can verify it.</div>Adminhttp://cryptonite.info/wiki/index.php?title=M7_PoWM7 PoW2014-07-16T06:49:40Z<p>Admin: small grammar fix</p>
<hr />
<div>The M7 PoW algorithm, otherwise known as the "magnificent 7" PoW algorithm, is a proof-of-work algorithm designed for the mining process in [[Cryptonite]]. The M7 PoW is not a memory hard algorithm, it's more like the algorithm used by Quark and similar alt-coins. Seven different hashing functions are used to generate the final hash which is tested against the target. The main difference is that Cryptonite doesn't use any obscure hashing functions that no one has ever heard of before. We wanted quality over quantity so we only used cryptographically secure hashing functions which are well tested. In order to avoid bias accumulation we multiply the 7 hashes together and then pass that number through the SHA-256 function one last time. The multiplication step is also harder for GPU's and ASIC's but works very efficiently on a CPU.<br />
<br />
The magnificent 7:<br />
<br />
* SHA-256<br />
* SHA-512<br />
* Keccak<br />
* RIPEMD<br />
* HAVAL<br />
* Tiger<br />
* Whirlpool<br />
<br />
The M7 PoW algorithm can be generalized as the following, where h = header:<br />
<br />
<code>SHA-256(SHA-256(h)*SHA-512(h)*Keccak(h)*Ripemd(h)*Haval(h)*Tiger(h)*Whirlpool(h))</code></div>Adminhttp://cryptonite.info/wiki/index.php?title=Inversion_databaseInversion database2014-07-16T06:42:53Z<p>Admin: Added page to wiki</p>
<hr />
<div>The inversion database contains instructions for reversing changes made to the [[account tree]]. The transactions alone are not enough to tell you exactly how to reverse changes made to the account tree because some information is lost in the process. For example when the [[Withdrawal_limits | withdrawal limit]] is updated the old withdrawal limit cannot be recovered unless you record what is was, and that's why we need inversions. One reason we might need to undo changes to the account tree is to handle [[blockchain reorganization]] events where nodes need to switch chains by unwinding and [[Fast_forward | fast forwarding]].</div>Adminhttp://cryptonite.info/wiki/index.php?title=Functions_of_the_blockchainFunctions of the blockchain2014-07-16T06:40:42Z<p>Admin: Added page to wiki</p>
<hr />
<div>The [[mini-blockchain scheme]] was developed by understanding the different purposes of the blockchain and then separating that functionality into individual mechanisms which are each optimized to serve their purpose. The blockchain has 3 main functions. The Bitcoin blockchain combines these functions into one single mechanism and as a result doesn't scale well. It requires nodes to store a lot of data which doesn't necessarily need to be stored for so long. Breaking up the functions of the blockchain is the key.<br />
<br />
'''Functions of the Blockchain:'''<br />
<br />
# to coordinate how the network processes transactions<br />
# to manage account balances; record the ownership of coins<br />
# to encapsulate the proof-of-work which secures the network<br />
<br />
The mini-blockchain scheme separates these functions into the [[3 core components]].</div>Adminhttp://cryptonite.info/wiki/index.php?title=Fast_forwardFast forward2014-07-16T06:39:35Z<p>Admin: Added page to wiki</p>
<hr />
<div>A node will "fast forward" when it has a complete [[account tree]] which is synced to some point in the past by applying all the transactions missed by the node while it was offline. If the node has been offline longer than the [[cycle time]] then fast forwarding might not be possible and the node will have to do a full resync. When a new node first [[Network_synchronization | synchronizes with the network]] it will attempt to build an old account tree which would have existed a cycle ago and then it will fast forward the tree to a state matching the latest [[master hash]].</div>Adminhttp://cryptonite.info/wiki/index.php?title=Dynamic_max_block_sizeDynamic max block size2014-07-16T06:36:43Z<p>Admin: Added page to wiki</p>
<hr />
<div>There's a lot of heated debate concerning the maximum block size within the Bitcoin community, and one new network protocol worth discussing is the idea of a dynamic max block size. The idea is to make the max block size a free floating value determined perhaps by several factors. Two methods which immediately come to my mind are 1) a mining-based voting system and 2) a system which analyzes some number of previous blocks and calculates the average block size to derive a new block size limit (eg 2*average).<br />
<br />
A voting system sounds feasible and it could allow us to manage the max block size through group consensus, but it gives groups such as mining pools a lot of power over what the max block size will be. A better solution is to simply calculate the average size of some number of recent blocks and then multiply that by some value to derive the new maximum block size, with some arbitrary lower limit. That way we don't need to store all the voting data in the blocks. This is the approach we decided to take with [[Cryptonite]].<br />
<br />
Even with our light weight scheme there does need to be a max block size because our network can only handle so much traffic before it virtually stops working. Even with a fully prunable mini-blockchain it can grow extremely quickly with large enough blocks. However in the future we may be capable of handling much larger blocks so we need a way of gradually changing it over time. A hardfork is obviously not very convenient. An automated readjustment system would be self-regulated and a much more seamless solution.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Cycle_timeCycle time2014-07-16T06:32:50Z<p>Admin: Added page to wiki</p>
<hr />
<div>The cycle time is essentially the amount of time a node must wait before old transactions can be discarded. It defines the minimum amount of block history that a node is required to keep. Blocks are said to be "in view" while they are younger than the cycle time and out of view when older. There are several important reasons that nodes must keep a reasonable amount of minimum block history: it ensures that a reasonable size [[inversion database]] can be built upon [[network synchronization]], and it helps protect against the [[Weaknesses_and_attack_vectors | secret chain attack]].<br />
<br />
The cycle time used in [[Cryptonite]] is 1 week (10080 blocks at 1 block per minute).</div>Adminhttp://cryptonite.info/wiki/index.php?title=Cryptonite_APICryptonite API2014-07-16T06:31:10Z<p>Admin: added info on recent rpc changes</p>
<hr />
<div>__TOC__<br />
<br />
The [[Cryptonite]] API is similar to the [https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list Bitcoin API], containing a few additions and subtractions, some changed arguments, and some use restrictions. Almost all commands returning anything more than a hash will return different JSON objects as compared to bitcoin. You can use the help command to get more information about any command.<br />
<br />
===New commands:===<br />
<br />
* addmultisigaddress - Generates a multisig destination address from a list of signers<br />
* getblockheader - Gets header component of block only<br />
* setlimit - set [[Withdrawal_limits | withdrawal limit]] for an address<br />
<br />
===Modified commands:===<br />
<br />
* listunspent is now listbalances<br />
* decoderawtransaction - Now has optional arguments to support successful decoding of partially signed multisignature transactions<br />
* sendtoaddress,sendmany,sendfrom - The two comment fields have been replaced by a single message field that is actually included in the transaction<br />
* signrawtransaction - Extra parameters allowed to help with signing of partially unsigned multisignature addresses<br />
* createrawtransaction - Added an optional parameter after all other arguments, used for setting message field like sendtoaddress<br />
* setaccount - Added an optional parameter after all other arguments, used to disable the automatic generation of new addresses<br />
<br />
===Restricted commands:===<br />
<br />
* getblock - May fail if block is more than 10k blocks from tip.<br />
* gettransaction/getrawtransaction - Transactions older then 10k blocks may not be locatable.<br />
<br />
===Removed commands:===<br />
<br />
* getrawchangeaddress<br />
* decodescript<br />
* lockunspent<br />
* listlockedunspent<br />
<br />
==A note about EP amounts==<br />
<br />
Since Cryptonite uses 64-bit's worth of coin units, it is not safe to treat amounts as double precision floating point values unless they are smaller than about 32 million XCN. To prevent old code designed for use with bitcoin daemon from trying to parse Cryptonite amounts, all RPC calls use strings to represent amounts. We call this encoding the extended-precision encoding, or EP for short.<br />
<br />
EP numbers are strings in JSON, and must always have 10 digits after the decimal point followed by "ep". An example of a valid RPC command using an ep number would be:<br />
<pre>./cryptonited sendtoaddress mvqH4czVQg2HdGpkV7PWVZJpRXVwLnMXpN "0.0100000000ep"</pre><br />
<br />
All amounts returned in RPC results are also EP numbers, and you must take care to parse them, do not use floating point to represent them unless you are really sure of what you are doing.</div>Adminhttp://cryptonite.info/wiki/index.php?title=CryptoniteCryptonite2014-07-16T06:28:50Z<p>Admin: added shortened name to description</p>
<hr />
<div>Cryptonite (also known as Crypton) is the first crypto-currency to implement the [[mini-blockchain scheme]] along with many other innovative features such as [[withdrawal limits]] and a [[Dynamic_max_block_size | dynamic maximum block size]]. Our goal was to create a truly scalable cryptocurrency currency which combined many of the best ideas developed within the alt-coin community and some of our own innovative ideas. The basic philosophy of Cryptonite is to follow the ideals set by Bitcoin as closely as possible but improve upon everything that could be improved.<br />
<br />
Cryptonite uses the [[M7 PoW]] algorithm which is not a memory hard algorithm but more like the algorithm used by Quark and similar coins. The difference is Cryptonite only uses cryptographically secure hashing algorithms which are well tested. We kept it old school and purposely avoided the PoS and memory hard algorithms, there were also time constraints and other good reasons, plus we want to leave the door open for interesting Cryptonite variants. One thing Cryptonite could really use is decentralized coin mixing or something similar.<br />
<br />
Cryptonite is a fork of the Bitcoin core but a vast amount of code has been altered, tens of thousands of lines of code have been altered and the result is an entirely new beast. Cryptonite is still highly experimental for that reason so you should use Cryptonite with caution and diligence until the code base has been properly reviewed and the robustness of the network has been properly established. Cryptonite was officially announced for release in the second half of July, 2014, one week after the [https://bitcointalk.org/index.php?topic=703406 pre-announcement] was posted on bitcointalk.<br />
<br />
==Coin specs==<br />
<br />
* Block time: 1 per minute<br />
* Block reward: changes every block (half life of 10 years)<br />
* Max block size: changes every block (100 block average * 2)<br />
* Difficulty adjustment: changes every block (1000 block filter)<br />
* Coin supply: [[Coinbase_account#64_bits_of_Granularity | 2^64-1 units]] (1.84 billion coins, 10 dec places)<br />
* Mining algorithm: [[M7 PoW]]<br />
* Pre-mine: none<br />
<br />
Home page: www.cryptonite.info</div>Adminhttp://cryptonite.info/wiki/index.php?title=Coinbase_accountCoinbase account2014-07-16T06:19:03Z<p>Admin: added address of coinbase account</p>
<hr />
<div>__TOC__<br />
<br />
The coinbase account is a concept new to the [[mini-blockchain scheme]] and first used by [[Cryptonite]]. The coinbase account is the first [[account]] in the [[account tree]] and acts as the input for coinbase transactions, meaning coins are subtracted from the coinbase account in order to fund block rewards. The starting balance of the coinbase account dictates the total possible coin supply. One interesting consequence of this approach is that it's easy to check the balance of the coinbase account and find out approximately how many coins are left to mine. <br />
<br />
When the balance of the coinbase account reaches 0 the block reward will be 0, however it is possible to provably destroy coins by sending them to the coinbase account. Another possible mechanism for injecting coins back into the coinbase account without inflating the money supply is to implement [[account tree pruning]] and feed the "maintenance fees" back into the coinbase account, which is helpful not only because it helps subsidize miners but also because it clears out dust in the account tree at the same time.<br />
<br />
The address of the coinbase account is CGTta3M4t3yXu8uRgkKvaWd2d8DQvDPnpL and you can check the balance of it like so:<br />
<pre>listbalances 1 [\"CGTta3M4t3yXu8uRgkKvaWd2d8DQvDPnpL\"]</pre><br />
<br />
==64 bits of Granularity==<br />
<br />
Bitcoin makes use of 2.1 quadrillion units where each coin is made up of 100 million units, resulting in a total of 21 million coins which are divisible by 8 decimal places. However, internally Bitcoin uses 64bit integers, and it could handle a much larger number of coins, so 21 million may sound like a rather arbitrary number, but in fact it is not. Many applications make extensive use of double precisions floats but doubles can only store integers up to 2^53, and that is ultimately why Bitcoin only has 2^50.9 units.<br />
<br />
However it is possible to use extended precision floats to exploit the full range of the 64bit integer. This gives the coin supply a much higher level of granularity and is based on a natural upper limit. A coin supply with 64 bits of granularity is made up of approximately 1.84 billion coins, assuming each coin is divisible by 10 decimal places. We have used extended precision floats in Cryptonite so that we're no longer held back by the limits of the double precision float, enabling a much larger coin supply.<br />
<br />
==Smart Coin Distribution==<br />
<br />
There are many ways coin distribution can be done, since Cryptonite has such a large coin supply it has a rather long mining period to ensure a fair distribution. It will take 10 years before half of the coin supply has been mined, with a repeating half life of 10 years. The block reward decreases in parallel with the coin supply, meaning it will take 10 years for the block reward to halve and it will take 10 years before half of all the coins have been mined.<br />
<br />
The block reward is adjusted every block so that it changes gradually over time. Sudden large changes in the block reward are not healthy for the network, and it's not clear why Bitcoin was designed to have such long intervals of time between changes in the block reward. By adjusting the the block reward every block the network has time to adapt to changes gradually. Cryptonite also updates the difficulty every block for similar reasons (eg to prevent instamines).</div>Adminhttp://cryptonite.info/wiki/index.php?title=Blockchain_reorganizationBlockchain reorganization2014-07-16T06:15:10Z<p>Admin: Added page to wiki</p>
<hr />
<div>Blockchain reorganization occurs whenever some type of fork occurs and some of the nodes are eventually forced to migrate over to the correct chain. This can happen simply because multiple blocks get solved at the same time, or because of a hardfork, or because of some type of attack or bug. To swap over to the correct chain the node will need to use the [[inversion database]] to unwind the [[account tree]] back to the origin point of the fork and then [[fast forward]] using [[transactions]] from the correct chain.<br />
<br />
If the origin point of the fork is older than the [[cycle time]], there's obviously a very long fork happening, and something is clearly very wrong with the network. It could even be a [[Weaknesses_and_attack_vectors | secret chain attack]] in progress. So in that situation all nodes except new nodes will just stick with the chain they already have unless specifically pointed to another chain. New nodes will essentially pick a random chain but the client will display a warning about the fork so the user knows what's happening.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Account_treeAccount tree2014-07-16T06:10:10Z<p>Admin: fixed withdrawal limits link</p>
<hr />
<div>__TOC__<br />
<br />
The account tree is 1 of the [[3 core components]] of the [[mini-blockchain scheme]]. Why should we record every single transaction and save it forever if all we need to know is the balance of all non-empty addresses? The 2nd [[Functions_of_the_blockchain|function of the blockchain]] is replaced with the account tree. The account tree is essentially what could be thought of as a decentralized "balance sheet". Each [[account]] in the account tree will hold the address and the balance of that address, along with a few other fields related to [[withdrawal limits]].<br />
<br />
When the balance of an address changes all we need to do is update numbers in the account tree instead of adding new data to it. Of course this wont provide a truly finite amount of data to work with because new non-empty addresses will be appearing all the time, but it comes as close to finite as is probably possible. It is finite in some sense because the coins will have limited divisibility, and we can't really expect the world population or the number of Internet users to continue growing forever. In any case it's scalable and manageable.<br />
<br />
Even with a population of 10 billion people where each person had 10 different non-empty addresses, we would only need to keep track of 100 billion addresses. Since we can remove empty addresses from the database and since a transaction would simply require peers to shift around numbers in this database instead of adding new data to it, the size of the account tree should always remain considerably small. By the time we reach anything close to 100 billion unique non-empty addresses our computers will be much faster.<br />
<br />
Owners of a non-empty address in the account tree would prove their ownership with their private key. Like Bitcoin, [[transactions]] are created as a signed set of data and broadcast over the network. Like Bitcoin, miners who accept the transaction then put it into their blocks and work on solving a difficult problem to get it into the [[mini-blockchain]] (see [[proof chain]] page). Nodes who accept the block would update their own copy of the account tree by shifting around coins or doing what ever was necessary.<br />
<br />
The proposed database is named the “account tree” because it should have a hash tree structure. Each [[account]] in the tree has a corresponding hash and acts as a leaf node at the bottom of the tree. Being a hash tree, we can combine the hashes of each account to build a pyramid of hashes and calculate the [[master hash]] at the top. Note that an “account” isn't a collection of addresses like a “Bitcoin account”. In this case each account refers to only one address or leaf node (obviously normal “accounts” will also exist).<br />
<br />
==Requirements of Account Tree Structure==<br />
<br />
There are a number of ways the account tree can be implemented, but the data structure must fulfill certain requirements.<br />
<br />
# All data should be able to be efficiently compacted to a deterministic hash (master hash / ledger fingerprint).<br />
# Efficient support for 4 operations: add account, modify account, remove account, lookup account.<br />
# After every modification one should be able to efficiently update the account tree master hash.<br />
# Should allow referencing of accounts by offset and address.<br />
# Should allow one to efficiently verify the correctness of a subset of the accounts without downloading the entire ledger.<br />
<br />
==Binary Radix Trie==<br />
<br />
[[File:radix_trie.png|right|thumb|300px|Figure 0-a: Patricia/Radix Trie.]]<br />
Figure 0-a shows a generic radix trie structure (from Wikipedia). In reality [[Cryptonite]] uses a type of binary radix trie combined with merkle hashing. What isn't shown in the diagram is how the nodes are hashed. All the hashes together produce the master hash/root hash at the top. The master hash will change even if just one account within the tree is altered in any way. This hash tree system provides integrity to our data because the master hash is also stored in block headers so the tree is secured by the blockchain. <br />
<br />
The advantages of using a binary radix trie structure include:<br />
<br />
# it is well suited for looking up addresses (public key hashes)<br />
# it is faster and more memory efficient than many other tree structures<br />
# small parts of the tree can be verified without the whole and completeness can be proven<br />
# inserting the same data into the trie in any order will always generate the same structure<br />
<br />
New accounts are inserted into the trie structure as leaf nodes when coins are sent to an address which does not already exist and they are removed from the trie when the address is emptied. When the address does exist the transaction will simply alter an existing account in the trie. The mini-blockchain acts to coordinate when the tree is updated. When a node receives a new block they will carry out the transactions listed within the block by altering their account tree accordingly.<br />
<br />
==Interaction with Mini-Blockchain==<br />
<br />
The proposed account tree structure allows all address balances to be summarized in a "balance sheet" format and allows old transactions to be safely discarded by all nodes. However, without a way to coordinate when and how the account tree is changed we still can't ensure consistency between nodes. That is where the mini-blockchain comes in. Each time a new block is accepted into the mini-blockchain, nodes will use that block to update their copy of the account tree in a consistent and coordinated fashion.<br />
<br />
In a distributed network it is impossible for every node to apply transactions at the moment it sees them. Transactions must be joined together and applied in bulk. Such a list of transactions grouped together form a block and together with headers form the blockchain. Nodes collect the transactions and apply them to the account tree to achieve a new account tree state. The master hash of the new tree state is included in the block header. Other nodes which receive such blocks can replay transactions themselves and check the hashes match.<br />
<br />
==Defining Allowed Modifications of Account Tree==<br />
<br />
The account tree structure defined here can be used for almost any model of underlying data. Rules which define how the tree can be modified define how it really works. Single operations on the ledger are called transactions. The [[Transaction_types | types of allowed transactions]] will define how the currency actually functions.</div>Adminhttp://cryptonite.info/wiki/index.php?title=Main_PageMain Page2014-07-13T17:52:02Z<p>Admin: fixed withdrawal limits link</p>
<hr />
<div>Welcome to the official [http://cryptonite.info/?page=mbc-project Mini-blockchain Project] wiki. This wiki is an open source community project created to document and expand on the technical details of the [[mini-blockchain scheme]] as proposed in the official [http://www.cryptonite.info/files/mbc-scheme-rev2.pdf white paper] and as implemented in the open source cryptocurrency called [[Cryptonite]] (the first alt-coin to use the mini-blockchain scheme).<br />
<br />
'''Advantages of the mini-blockchain scheme'''<br />
<br />
By replacing the full blockchain with a [[mini-blockchain]] and by using a self-contained balance sheet system (the [[account tree]]) for tracking the balance of non-empty addresses, it's possible to eliminate the need for storing long term historical transaction data and it provides an optimal level of compression, resulting in consistently fast [[network synchronization]] speeds.<br />
<br />
As a result of this, the maximum block size can be made much larger and it's possible to increase the transaction bandwidth significantly without having to worry about blockchain bloating. The increase in block space also results in lower fees and more flexibility when it comes to issues such as micro-transactions and storing custom messages in the blockchain.<br />
<br />
Although faster and more scalable, there are some [[weaknesses and attack vectors]] that we have to accept as trade-offs if we want all the advantages, but there's nothing which makes this scheme untenable in practice. This wiki will also cover some experimental ideas which are being developed, including the [[withdrawal limits]] system and the [[dynamic max block size]] mechanism.<br />
<br />
'''[[Special:AllPages | LIST OF ALL WIKI PAGES]]'''</div>MediaWiki default