[white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain

[bitfreak!]

I've been working on this idea for a few months now but I couldn't get past the problem of making the scheme satisfactorily secure. I finally solved that part of the puzzle about a week ago and immediately decided that I needed to write a white paper and formalize the concept some what.

I also want to give an acknowledgment to member aaaxn for helping me fine tune some of the concepts in the paper, his knowledge was very helpful. Until now no one else has read this white paper so I'm hoping for a lot more great feedback from other members.

NOTE: the white paper is now fairly out-dated. Check the project wiki for more up-to-date information concerning the mini-blockchain proposal.

Purely P2P Crypto-Currency With Finite Mini-Blockchain (PDF)

ABSTRACT

Almost all P2P crypto-currencies prevent double spending and similar such attacks
with a bulky “blockchain” scheme, and the ones which do not typically use some sort
of pseudo-centralized solution to manage the transactions. Here I propose a purely
P2P crypto-currency scheme with a finite blockchain, dubbed the “mini-blockchain”.
Each time a new block is solved the oldest block is trimmed from the end of the mini-
blockchain so that it always has the same number of blocks. It is argued that the loss
of security this trimming process incurs can be solved with a small “proof chain” and
the loss of coin ownership data is solved with a database which holds the balance of
all non-empty addresses, dubbed the “account tree”. The proof chain secures the mini-
blockchain and the mini-blockchain secures the account tree. This paper will describe
the way in which these three mechanisms can work together to form a system which
provides a high level of integrity and security, yet is much slimmer than all other purely
P2P currencies. It also offers other potential benefits such as faster transactions and
lower fees, quicker network synchronization, support for high levels of traffic, more
block space for custom messages, and increased anonymity.

Project development thread: https://bitcointalk.org/index.php?topic=215936.0

[1714947847]

1714947847

[1714947847]

1714947847

[digitalindustry]

reading right now, mostly becasue its such a great idea !

[bitfreak!]

reading right now, mostly becasue its such a great idea !

Well it's not that hard to come up with a great idea.
The hard part is making the idea work.
Thanks for taking a look.

[digitalindustry]

reading right now, mostly becasue its such a great idea !

Well it's not that hard to come up with a great idea.
The hard part is making the idea work.
Thanks for taking a look.

yeah agreed, I just read it , truly i'm also no coder, but i see the design of the proof chain as very ingenious, would this not also lead to much faster trans times?

but obviously a larger and more complex client,  my head hurts at how much work would go into coding that , but its the first time i've seen this problem addressed in a way that makes sense, and seems to provide security.

I guess my question would be in relation to the Proof chain stamp (i see it like the stamp of a film sprocket, the film runs but the stamp records what happened) having only two #'s does that provide a security flaw early in the life of the currency?

awesome work, lets see what the hard core guys say.

[bitfreak!]

but obviously a larger and more complex client,  my head hurts at how much work would go into coding that

I don't see why the client would be larger or more complex. Nothing described in the paper should really be too difficult to implement, it's really just taking the bitcoin scheme and modifying certain aspects of it to remove the need for a full blockchain.

having only two #'s does that provide a security flaw early in the life of the currency?

I don't believe so. If it did we could just use the block headers instead of a proof chain... I mean there's really no need to create a whole new proof chain system when we can use the block headers. But the proof chain mechanism probably would have certain advantages assuming it provided the same level of security as the block header system.

[Come-from-Beyond]

U should publish an address for donation. It's very unlikely someone will code the implementation for free.

[mr_random]

U should publish an address for donation. It's very unlikely someone will code the implementation for free.

This. Look at all the hard work Sunny has done for PPCoin for free and yet he gets constant trolling for it. It's a thankless task!

[bitfreak!]

[removed]

[bitfreak!]

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.

[digitalindustry]

U should publish an address for donation. It's very unlikely someone will code the implementation for free.

This. Look at all the hard work Sunny has done for PPCoin for free and yet he gets constant trolling for it. It's a thankless task!

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 -

[digitalindustry]

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)

 

[Caesar V]

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

[xorxor]

-----deleted-----

judged to quickly.

[Come-from-Beyond]

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.

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.

[aaaxn]

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.

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

[Come-from-Beyond]

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.

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

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.

[bitdwarf]

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.

[aaaxn]

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.

[Come-from-Beyond]

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.

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.

[aaaxn]

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