Mini-blockchain - Revision history

Admin: Fixed up stupid wording.

2014-11-04T22:56:12Z

Fixed up stupid wording.

← Older revision		Revision as of 22:56, 4 November 2014
Line 1:		Line 1:
	[[File:mini-blockchain.jpg\|right\|thumb\|350px\|Figure 0-a: Mini-blockchain diagram.]]		[[File:mini-blockchain.jpg\|right\|thumb\|350px\|Figure 0-a: Mini-blockchain diagram.]]

	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 ~~blocks~~. 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.		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.

	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 ~~blocks~~ let's call it a “mini-blockchain”.		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”.

	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 ~~blocks~~ and save an immense amount of disk space. However we do keep a few hundred or a few thousand of the newest ~~blocks~~ and that makes our mini-blockchain. The mini-blockchain also provides us with a level of security.		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.

	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 ~~blocks~~, it is far from impossible.		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.

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

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

Admin: resized and relocated image

2014-07-16T08:16:50Z

resized and relocated image

← Older revision		Revision as of 08:16, 16 July 2014
Line 1:		Line 1:
			[[File:mini-blockchain.jpg\|right\|thumb\|350px\|Figure 0-a: Mini-blockchain diagram.]]

	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 blocks. 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.		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 blocks. 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.

	~~[[File:mini-blockchain.jpg\|right\|thumb\|500px\|Figure 0-a: Mini-blockchain diagram.]]~~

	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 blocks let's call it a “mini-blockchain”.		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 blocks let's call it a “mini-blockchain”.

Admin: fixed image

2014-07-16T08:06:56Z

fixed image

← Older revision		Revision as of 08:06, 16 July 2014
Line 1:		Line 1:
	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 blocks. 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.		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 blocks. 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.

	[[File:~~min~~-blockchain.~~png~~\|right\|thumb\|~~300px~~\|Figure 0-a: Mini-blockchain diagram.]]		[[File:mini-blockchain.jpg\|right\|thumb\|500px\|Figure 0-a: Mini-blockchain diagram.]]

	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 blocks let's call it a “mini-blockchain”.		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 blocks let's call it a “mini-blockchain”.

Admin: Added page to wiki

2014-07-16T08:05:13Z

Added page to wiki

New page

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 blocks. 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.

[[File:min-blockchain.png|right|thumb|300px|Figure 0-a: Mini-blockchain diagram.]]

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 blocks let's call it a “mini-blockchain”.

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 blocks and save an immense amount of disk space. However we do keep a few hundred or a few thousand of the newest blocks and that makes our mini-blockchain. The mini-blockchain also provides us with a level of security.

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 blocks, it is far from impossible.

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.

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.