Topic: Building the Next Generation of Crypto-Currency (developers required) - page 11. (Read 23560 times)

Well unfortunately math is not my strongest talent so you kind of lost me with that, but it seems like you may be onto something. What you are saying seems some what similar to the other rolling chain solution I mentioned in my paper. I hope it actually is possible to implement something like this on top of bitcoin, that will give me much more faith in the long term future of bitcoin.

Counter-party risk is depending upon someone else to be willing and able to honor a promise to pay.

Trading goods on the market is not counter-party-risk.  It is instead 'exchange risk' which is different.

Creating market forces that push two goods toward parity value can minimize exchange risk without introducing counter-party-risk.

Ok, I can summarize my solution as such:

Given the bitcoin blockchain C define a deterministic function F(C) that generates an output index  I

I = F(C)

Then include SHA256(I) in the merkel tree when you generate block B.

To validate block B + 1 the 'brute force' way you would calculate  SHA256(F(C+B)) and verify it exists in the the merkel tree.

To do it the 'easy way', you would remove all outputs from I that are consumed by inputs in B and then add all outputs in B to I.  This would be 'cheap' and then you can do SHA256(I+ delta from B) and then validate the result exists in the merkel tree.

Bitcoin already operates based upon an index of outputs.  The problem is that these outputs are tied to a transaction which has to be kept around to lookup the output.  The transaction (being the smallest prunable unit) includes other spent outputs + inputs and input scripts most of which is not relevant.  A transaction cannot be pruned until all of its outputs are spent.

I would design F(C) to generate the following table

TRX_HASH,  OUTPUT_NUM,  SPEND_SCRIPT, BLOCK_NUM, AMOUNT

Then sort it by TRX_HASH + OUTPUT_NUM to get a deterministic (and log(n) searchable) index.

The effort to create F(C) is probably 8 man hours (max).   The effort to create a method to implement I+B such that I+B = F(C+B) would probably be less than 4 man hours.

Including the resulting SHA256(I) in the merkel tree perhaps 4 hours.
Validating the merkel tree... 4 hours.

Thus I suspect the total implementation time required to enable pruning of all transaction history is less than 1 week for the backend / miners.   Then individual clients could pick when they want to start trusting I vs the long tail of C.  I suspect that 10,000 blocks is enough for just about anyone.  

You cannot hack nor replace outputs even with a 51% attack and thus it is entirely secure.    

The level of compression offered by your approach would be *slightly* better because it would collapse all outputs with an identical SPEND_SCRIPT into a single entry and I could not do that because transaction inputs must reference a valid output.   However, I suspect your system requires maintaining much more complex hash chains, merkel account trees, and other data structures that take up space.  Breaking backward compatibility would also be a downside.

Based on this statement I'm not convinced that you understand counterparty risk.

Well I'm not sure what you just said is any less complex, it certainly confused me. But if what you are saying is valid, you are claiming that a small change to the existing Bitcoin protocol can basically provide something similar to a finite mini-blockchain? I'm certainly very skeptical about that, I don't think my system is overly complex, I believe it has the minimum components required to make the mini-blockchain scheme secure and robust.

Not to derail your design, but it is very complex (perhaps more-so than necessary).

Given the current bitcoin block chain, you can deterministically generate the min set of all 'outputs' that are still valid.  This will generate a very small list (compared to the block chain).  This list would include the hash of the transaction + the output index + script + balance + block num.   It would drop all of the inputs to the transaction and all spent outputs.  Furthermore, outputs with 'identical scripts' could in theory be compressed into a deterministic lookup table.

The hash of this list could then be included in the merkle tree of the existing block chain.  Because all nodes can deterministically calculate the same list they can all validate the hash of the list as part of the block-chain validation.

Anyone can then fetch this list and have just as much confidence in the validity of the outputs as anyone who had the full block chain.   All that would be required is to store the block-headers for the full chain + the output summary list of your 'origin' + however many blocks with full transactions you feel you need.

Thus a light-weight client could constantly prune transaction history and just keep 120 blocks, while full up banks could hold the entire chain for all of history.  

I believe this solution would be cheaper, easier, and more flexible than your solution.  It requires no significant changes to bitcoin other than generating a deterministic output summary and hashing it and then including that hash in the merkel tree.  The table could be trusted by all because otherwise the block would have been rejected by other nodes.

Such a change to bitcoin would be so 'small' that it could probably be implemented with a well-planned hard-fork.  The hard fork being validating the 'summary hash' as part of block verification.  That said, it could be a soft-fork that only miners need to be aware of because blocks could still be generated that would be accepted by old and new clients and miners supporting the new feature could only accept blocks with valid 'summary hashes' or blocks with 'no summary hashes' and then new clients could trim the block chain at any block that includes a valid summary hash.  This would only require proof that 90% of the past 10000 blocks contain valid summary hashes to be sure that no block with an invalid summary hash could possibly make it into the longest chain without sustained 51% attack.  Once 90% of miners are including valid summary hashes, they can start rejecting blocks (and miners) that do not include it.

I will probably implement this as part of BitShare currency rather than your proposed approach... that is unless you can show me something I am missing.

I actually took a look at your thread a few hours ago and your idea seems fairly complex. I would recommend writing a white paper or something. While I agree it may be beneficial to mix together as many good ideas as possible it's still problematic. At this point my goal is simply to just implement this mini-blockchain scheme to see if it actually works. The job is already difficult enough and I don't want to go including all these other untested ideas, it will just make the process longer and harder. As I said, the goal of this project is really just to stay as close to the bitcoin protocol as possible and just play it safe. I would recommend the same thing with your project as well, first just build it as you imagine it and see if it actually performs as you believe it will. When you try to start off with too much on your plate it can often lead you to troubles. At some later point maybe we can have a mini-blockchain + PoS + your exchange model (although I'm still skeptical of the PoS stuff and I'd need to understand your proposal better for actually backing it), but right now that isn't the best course of action to take in my opinion.

There is potentially synergy between this blockchains features an my economic model for offering a crypto-USD, crypto-GOLD, etc that maintains near parity without having any counter party risk.   If a new chain were to be created I believe it should include as many 'good ideas' as possible because we will be stuck with it for a while if it works.

I will investigate your proposal and would appreciate if you would investigate my p2p bank/exchange system.

This idea sounds great, would love to be part of it as the designer!

What is this project all about?

The goal of this project is to implement a new crypto-currency protocol designed to solve the "blockchain bloat" problem once and for all by replacing the full blockchain with a finite "mini-blockchain". Such a system would offer many benefits including consistently fast synchronization times, much more block space, faster transactions, and lower fees. Certainly not an easy problem to solve, but if it could be solved we are looking at truly new and unique improvements over the Bitcoin protocol.

We now believe that this problem finally has been cracked. The concept and technical details of the proposal can be found in the white paper (a little outdated now) and the project wiki. This new scheme has been analyzed by many intelligent people and we haven't found any major flaws. After a considerable amount of feedback, myself and several others are convinced the scheme is viable and we want to attempt an implementation.

Our objectives and approach

The main objective of this project is to bring together many new ideas and concepts while staying as true to Bitcoin as possible. This project will attempt to minimize and exclude any controversial proposals and ideas but remain open to new and experimental proposals which we believe could enhance the final system. We aim to take the safe and trusted route ever possible and avoid over-complicating the scheme by bringing together too many different ideas.

The main focus of this project is to implement the mini-blockchain protocol and show that it works before we do anything else. If or when that goal is achieved we will start looking at incorporating several other experimental concepts which have the potential to provide an array of new features and benefits. Some examples of such concepts include secure 0-confirmation transactions based on a withdrawal limit system and a dynamic max block size.

Since we are trying to avoid any controversial and unnecessary complications, that means no pre-mine and probably no PoS integration. The PoS system is controversial in a way because it appears to make the rich richer over time and the benefits of such a system really aren't observable for a long time anyway. Not to mention the mini-blockchain proposal is already complicated enough as it is, keeping things simple is the key here.

The next generation of crypto-currency

What is the next generation of crypto-currency and what separates this project from any other alt coin? Most of you will agree that 95% of the alt coins out there are essentially pump and dump scams which offer nothing new or useful. I would personally say there are less than half a dozen alt coins which shouldn't be labeled scam coins; Namecoin, Devcoin, PPCoin, Novacoin, and Litecoin, and perhaps 1 or 2 other alt coins. I'm not so sure about PPCoin and Novacoin but they do offer new PoS features.

Litecoin doesn't really offer much beyond faster block confirmation speeds and scrypt-based mining, but since it was one of the first alt coins to offer these new features it has gained a genuine foothold in the crypto-currency market. Not only does this project offer a new coin with unseen features, but those new features are not small or trivial. Imagine always being able to download the blockchain within seconds or minutes as well as significantly faster transaction speeds.

Why am I making such a big deal of this? Well consider threads like this:
WARNING! Bitcoin will soon block small transaction outputs
New video: Why the blocksize limit keeps Bitcoin free and decentralized

All this concern over max block sizes, the SD "spam dust", the transaction capacity reaching its limit, all of this is nicely solved with a mini-blockchain + account tree implementation. Now I'm not saying Bitcoin is obsolete or outdated or that this new scheme will replace it, Bitcoin still has certain advantages over the mini-blockchain scheme and vice versa. However if this scheme turns out to work it does have the potential to seriously compete with bitcoin.

It was only a matter of time before someone was able to improve on the Bitcoin protocol and offer a new coin with highly desirable advantages over the original protocol, but I don't think that will mean the original will ever die out. Just because this scheme can offer more scalability and speed doesn't make it better as a tool for storing wealth. It does sort of make it better as a currency though, which is really what we should be aiming for I believe.

So how will the project be organized?

See: [BOUNTY] $20,000 Mini-Blockchain Implementation

---

Project Address: 1AZjrg6h9nfvFt16kaszLTJkQi13kMwZz2