Topic: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain - page 9. (Read 24145 times)

If I recall correctly maximum information density is achievable at numeral system based on number e (2.718). So triple hash tree could be better than binary one.

I would advise to update address structure proposed in this paper. I think binary hash tree would be better. Your proposal would require to constantly make hashes over vast amounts of data (all sector hashes) so this data would need to be kept in memory. Moreover with accounts packed in 1000 blocks there is also a lot of data to hash and as transactions would be randomly distributed to all sectors large portions of tree would need to be recalculated in every block. With binary tree you would always need to update just 2 * LOG(N) hashes per transaction and all hashes would be made over fixed length strings. N is number of accounts in tree. This way only small subset of tree would need to be kept in memory.

If it would be longer than main chain nodes would switch to it and start extending it so it would definitely propagate.

I think simplest solution is to forbid nodes to switch to other chain if its divergence from current chain happened before range of mini blockchain. How many previous blocks node stores could be customizable parameter. Professional machines could keep longer history if they wish while client nodes could store just default length ( month or so ).

I think new nodes in this situation (it should be extremely rare or never) should just query nodes for blockchain all the way to block in which competing chains diverged and if no one around has this long history node should just refuse to operate and wait until thing settle. Or it can be advised to download updated client which should in this situation contain hardcoded checkpoint provided by community pointing to right chain.

With the solution I described in my last post, the attacker would only succeed if he convinced enough new nodes to accept his fake chain and together they could supply more hashing power to the fake chain than the older nodes to the real chain. While that seems virtually impossible it may be some what possible if the attacker continues to contribute hashing power even after tricking new nodes to accept the chain. Because obviously this attacker must have an ungodly amount of hashing power to outpace the real mini-blockchain for a full cycle.

One way to really drill the final nail into the coffin of this attack might be this: if a new node detects two full mini-blockchain's which both originate from the same proof chain it can simply resort to a peer vote system by asking older nodes which chain is the valid one. Legitimate older nodes who noticed the fake chain appear out of thin air would reply to the new node telling them not to trust the one which appeared to come out of no where. Now the attacker would have an extremely hard time getting enough slaves in on his little scheme.

Even if the attacker had a huge botnet at his disposal at least 80 to 90 percent of existing and new nodes would reject the fake chain and continue working on the real chain. Soon enough the attacker wouldn't be able to afford continuing the attack and he would give up. The real mini-blockchain would quickly overtake the fake chain once the attacker stopped contributing his hashing power to it. With these mechanisms in place the attacker has no hope of convincing more than half the network to use his fake chain.

Hmmm... I think I see what you are getting at here. The attacker generates a fake chain in the background using the real proof chain but a fake account tree. He outpaces the real mini-blockchain for a full cycle until there's no evidence left to indicate his account tree is fake and releases the fake chain.

That would be one hell of an attack to pull off and even after pulling it off there's a low chance the fake account tree would propagate enough to become the main account tree. But this just goes to show the mini-blockchain does need to hold at least maybe a week or more worth of transaction history.

Although I think one possible way to dramatically minimize the threat of this attack is to make it so a node who has been connected to the network for a while will only accept a different chain with more power if they know where the chain came from, that it didn't just pop out of thin air.

For example a node who has been validating blocks longer than the cycle of the mini-blockchain can simply ignore a new chain if it appears to that node as if the chain popped out of no where. This will still allow the normal process of block orphaning to occur because the chains do not pop out of no where in that case.

hmm.. keep the balances on other chain.. would we get the same result, if the protocol forces that all inputs of a certain address is used if any of them is used? This way, the latest output is *allways* the balance of that address.

Edit; of course not. If a payment comes to that address later.. but maybe the new transaction might include the destination address as an input to that payment, even without sercet key?

+1

It looks like algorithm presented in this paper is only as secure as mini blockchain is secure and if attacker could sustain 51% hashing power for as long as mini blockchain cycle completes it could cause much more severe problems than in bitcoin, because attacker could rewrite entire account balances database and not just make some double spends.

I don't understand your point. Whole point of idea in this paper is that you do not keep track of old transactions. It is not loosless compression. You don'0t have access to old transactions and you cannot recreate account balances at any point in time. All yo get is current account balances and a little history that lead to it. I don't see how lossy compression would violate Shannon's theorem.

Imagine that u have only some data and there are no other peers in the whole universe. I doubt it's possible to compress HUGE transaction history into a couple of GB. U must have HUGE data volume or HUGE computing power to check validity of the data.

I was suspicious from the beginning about idea of creating proof chain from just two hashes and it looks I was right. Proof chain is useless if you do not include block header with it.
First indirect proof. Suppose we have original blockchain of length N and there is a fork and nodes split up in half and start generating their own independent chains from block N+1. After both network generate sufficient amount of blocks to cause blockN header to be discarded you would have two different blockchains claiming to be secured by the same proofchain. Of course it means neither is really secured.

Now attack scenario. Suppose there is attacker with more than 50% of hashing power. He takes hash of current best block N and tries generating a next one but instead of using real account database he just create new one in which he holds all coins. If he is able to keep this chain in front of original one for as long as original network looses block N contents he can reveal his chain and it would look perfectly valid for all nodes because they lost track of how account database looked on block N.

Forgive my ignorance, but wouldn't it be enough to ask a bunch of peers for a hash of the older transactions? Some peers would keep the full chain, others would keep chains with partly hashed chunks, they can keep validating these hashed chunks against their peers all the time to purge anyone that managed to create a chunk with the same hash.

U have to trust a 3rd party in this case, don't u? If I'm wrong then Shannon's source coding theorem should be wrong too.

I think idea is that you don't need to have whole transaction history. Having information about current balances of all accounts is sufficient.

The very 1st impression was "Hm, looks like proof chain is just block headers chain". Then I started to apply different theorems trying to find contradictions. Here is a short list:

1. CAP theorem
2. Space-time tradeoff
3. Shannon's source coding theorem

Unfortunatelly, I didn't get ur idea completely even after 2 readings. If u tried to apply mentioned theorems to ur approach, it would be easier to comprehend the whitepaper. The main thing I'm daunted with is that ur approach lets to validate the whole transaction history without trusting to 3rd parties. I can't prove that but I believe that it's impossible without trusting to some "outer" source of information.

-----deleted-----

judged to quickly.

My body is ready! (for making money).. 

come on FFS coders have a look at this, i want to know if this is viable myself.

(picturing them hard at work making LTC copies to pump and dump lol jks)

 

Ive never seen that, but again i'm not lurking around many PPC topics, PPC principal has be incorporated into other designs , i wouldn't say that is thankless, he has stamped his self in history.

**edit - didn't really know what i was talking about re code related to PPC *** removed this line -

By the way CFB, what did you did think of the proof chain concept? Can you see any flaws in that idea? Honestly though it may be better to just start by using the block header system and then maybe try creating a proof chain system to see how it works at a later stage.