Topic: Building the Next Generation of Crypto-Currency (developers required) (Read 23571 times)
July 12, 2014, 11:09:16 AM
track
January 30, 2014, 02:36:35 PM
We're looking to implement this (or a reasonably similar system).
December 06, 2013, 12:41:05 AM
Is this project still under development? No updates since August 27, 2013 
I gave up on trying to form a team of developers and instead set up a bounty:
[BOUNTY] $20,000 Mini-Blockchain Implementation
I heard rumors that some people were working on an implementation but the bounty is still unclaimed so far.
Thanks for the update! I'm glad to see you made a bounty for this, how selfless of you. I hope someone comes through and claims this bounty. Block chain bloat is something I think will become a problem in the future.
December 06, 2013, 12:27:13 AM
Is this project still under development? No updates since August 27, 2013
I gave up on trying to form a team of developers and instead set up a bounty:
[BOUNTY] $20,000 Mini-Blockchain Implementation
I heard rumors that some people were working on an implementation but the bounty is still unclaimed so far.
December 06, 2013, 12:07:35 AM
Is this project still under development? No updates since August 27, 2013
October 15, 2013, 08:19:42 AM
Some thoughts on the merits of an account tree approach:
1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.
2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth. If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network. This network would be generating 10 GB / month or 120 GB / year in transactions. Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.
Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.
B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account. This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.
C) The resulting database size would be 200 GB without any indexes or other data structures.
D) To create a sha256 merkle tree on these accounts would require 64 GB
E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB
Conclusion: The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.
The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.
Clearly the bandwidth is the bottle neck of scalability and not the data storage. If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.
A decentralized blockchain is transaction rate limited, not storage limited. If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem. And you would be left with the same scalability problems as the account-tree based approach.
What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.
The main thing that you are not taking into consideration is the fact that we wont reach 1 billion accounts in the account tree for an extremely long time, and by then it wont be unreasonable to expect people to deal with those sorts of large data sets (presumably). Now calculate how long it would take for the bitcoin blockchain to reach 300GB at the current rate of growth. Not too long I'm willing to bet, even with good pruning.1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.
2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth. If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network. This network would be generating 10 GB / month or 120 GB / year in transactions. Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.
Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.
B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account. This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.
C) The resulting database size would be 200 GB without any indexes or other data structures.
D) To create a sha256 merkle tree on these accounts would require 64 GB
E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB
Conclusion: The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.
The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.
Clearly the bandwidth is the bottle neck of scalability and not the data storage. If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.
A decentralized blockchain is transaction rate limited, not storage limited. If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem. And you would be left with the same scalability problems as the account-tree based approach.
What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.
Furthermore, each account will be much smaller than 200 bytes, it will be closer to the 54 byte example you gave on the last page. No higher than 80 bytes in the worste case. If we assume 60 bytes instead of 200 bytes per account you'll find that it's only 55 gigabytes required. Also, the mini-blockchain will probably keep 1 weeks history or less, a full month is far too long if we need to account for very large transaction rates.
EDIT: But I do agree the system is not perfect and has its limitations, like any decentralized system. The answer is multiple competing crypto-currencies as you mentioned in your last post. But I don't think we would need thousands or even hundreds of coins, if we were to use the mini-blockchain / account tree scheme for those crypto-currencies, a few dozen or so could handle the entire worlds transaction needs I believe.
USA is way behind rest of the world, e.g. Hong Kong residents can get 0.5 Gbps for $25 monthly. This is due to telcom monopolies. Google is installing 1 gigabit where it can:
http://www.huffingtonpost.com/2013/07/24/us-internet-speed_n_3645927.html
So the USA crashes and burns in a heap of socialism debris. Bitcoin moves to Asia where the future is.
Also as we make our way through this global financial implosion, the mainstream are going to herd with the socialism and not adopt the new technology. It is only AFTER the destruction of their financial system, after the reset they make their way to the new thing. So mostly you will see the adoption of the digital coins limited to the astute who want to jump off the Titantic:
https://bitcointalksearch.org/topic/m.3340053
We shouldn't have the scaling problems, because by the time the mainstream comes on board after 2033 (when mining ceases in Bitcoin), the relevant places of growth in the reset economy will have more than 1 gigabit connections.
September 27, 2013, 05:03:06 PM
Hi,
If any leftover job is here, i am ready to contribute.
If any leftover job is here, i am ready to contribute.
August 27, 2013, 05:13:55 AM
Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.Sorry for not keeping you posted. I've strated working on bitcoinj code but it's moving slowly. My first goal is to bring up network connectivity and basic block mining functionality.
If you have any questions about how something should be done, feel free to ask. Most of the uncertainties are documented in the wiki so I would recommend going through the project wiki if you haven't done so already. I recently disabled account creation for the wiki because there was so many spam accounts being created, but if you want an account so that you can edit things then I will create one for you manually.
August 27, 2013, 03:51:59 AM
Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.Sorry for not keeping you posted. I've strated working on bitcoinj code but it's moving slowly. My first goal is to bring up network connectivity and basic block mining functionality.
August 26, 2013, 06:57:01 AM
Quote
Is there continued movement on this project?
I don't think there's really much happening with this project at the moment. lexxus said he would do some work on it this month but I don't know whether he has or hasn't. I've been pretty focused on other projects recently but the project funds are still sitting there waiting for anyone who wants to work on this project.Quote
That's a wordy way of saying I think this project is on the right track and I hope there will be continued progress. Just don't forget about the importance of remining lost coins and consider a smaller time frame, perhaps 10 years. It should be a problem for most as long as the coins are first-in / first-out and perhaps a system of notification could be built into the client.
I very much agree with your sentiments concerning the re-mining of lost coins, but the reason why I don't want to put a lot of focus on re-mining is because 1) there are more important things that need to be done first and 2) it's a very controversial issue. I made a thread a while ago about the possibility of implementing re-mining lost coins into bitcoin and I found that many people strongly disagreed with the idea because it impinges on there ability to store coins in the same address for very long periods of time. The reason it needs to be at least 100 years is because then people feel safer about the idea and if they lose their coins they can't exactly say they weren't given enough time to move them. 
August 25, 2013, 09:14:33 PM
Is there continued movement on this project? I just read the white paper a couple days ago. For the most part it's too complex for my tiny brain but it did touch on something aside from the unending block chain growth of Bitcoin which has bothered me for some time, the long term deflation. In the paper you had mentioned possibly expunging unused accounts after 100 years and considering the coins lost and to be recirculated. Personally I think the time should be far less than that but even 100 years would be an improvement.
I'd hate to see something as punitive as Freicoin but a system which encourages the use of the currency or at least the shuffling at some small cost seems like a good one to me. A successful long term Bitcoin economy would clearly be one in which wealthy people amass huge sums and with deflation just spend nearly endless fractions of coins in the future. It's a recipe for plutocracy far worse than we have today.
Forcing people to occasionally spend or move coins solves several problems: Lost coins can be remind and moved ensures there will be enough tx fees to keep miners happy. Both ensure a constant and fairly distributed money supply on a network which is well secured. The even money supply would also give a much better impression of the health of the network.
That's a wordy way of saying I think this project is on the right track and I hope there will be continued progress. Just don't forget about the importance of remining lost coins and consider a smaller time frame, perhaps 10 years. It should be a problem for most as long as the coins are first-in / first-out and perhaps a system of notification could be built into the client.
That's my ramble. I'd be happy to know your thoughts on this.
I'd hate to see something as punitive as Freicoin but a system which encourages the use of the currency or at least the shuffling at some small cost seems like a good one to me. A successful long term Bitcoin economy would clearly be one in which wealthy people amass huge sums and with deflation just spend nearly endless fractions of coins in the future. It's a recipe for plutocracy far worse than we have today.
Forcing people to occasionally spend or move coins solves several problems: Lost coins can be remind and moved ensures there will be enough tx fees to keep miners happy. Both ensure a constant and fairly distributed money supply on a network which is well secured. The even money supply would also give a much better impression of the health of the network.
That's a wordy way of saying I think this project is on the right track and I hope there will be continued progress. Just don't forget about the importance of remining lost coins and consider a smaller time frame, perhaps 10 years. It should be a problem for most as long as the coins are first-in / first-out and perhaps a system of notification could be built into the client.
That's my ramble. I'd be happy to know your thoughts on this.
July 28, 2013, 05:51:50 PM
Is this project going to support colored coins and multi-sig ?
Both are important to my own project.
Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer.Both are important to my own project.
Colored coins allow you to use the blockchain for issuing real-world assets. Like issuing "gold ounce" units that are tracked on the blockchain.
In OT, this is useful for divorcing the issuer from the transaction server. (It works in combination with multi-sig.)
July 28, 2013, 05:46:32 AM
Is this project going to support colored coins and multi-sig ?
Both are important to my own project.
Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer. Both are important to my own project.
July 28, 2013, 12:27:35 AM
Is this project going to support colored coins and multi-sig ?
Both are important to my own project.
Both are important to my own project.
July 27, 2013, 08:00:52 PM
What other help is needed on this project. I believe in what you are doing, and would like to help, but I am not a programmer.
Is some development occurring?
Is some development occurring?
July 20, 2013, 04:06:19 PM
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.
Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.
[/quote] I just meant using python as a glue and accelerator, but you seem right, Java would be a cleaner and wiser choice.
July 20, 2013, 02:24:43 PM
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.
Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.
July 20, 2013, 01:49:37 PM
Hi BitFreak!
Nice idea and scheme, actually had an open eye on this thread for about a month. But since I didn't know how I can help, didn't jump in before.
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Still if the problem is about finding developers to implement it, then why don't you try to use the Python framework (as the head and glue) to define and construct the building codes and then write integrate the parts into it by using other proper languages like c or java or whatever. In that case, I may also be able to contribute a part to the development.
Nice idea and scheme, actually had an open eye on this thread for about a month. But since I didn't know how I can help, didn't jump in before.
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Still if the problem is about finding developers to implement it, then why don't you try to use the Python framework (as the head and glue) to define and construct the building codes and then write integrate the parts into it by using other proper languages like c or java or whatever. In that case, I may also be able to contribute a part to the development.
July 15, 2013, 03:35:49 PM
The market can balance the # of chains vs the trx fees vs the demand for decentralization. You would only have 1000 chains if there was high demand for decentralization.
There is another technique that is probably just as effective as account trees and that is the use of smart compression of both the transaction data transmitted and the database.
In the current block chain there is a ton of redundant info: same address in multiple transactions, trx id referenced once for each input is stored multiple times if a trx has many outputs. These are all 32 byte numbers that could be reduced to 4 to 8 bytes and yield a 50% savings for the second use and 75% for each subsequent use. With a proper protocol for agreeing on what these identifiers are (say first bits... ) I estimate you could double the transaction volume for equal bandwidth and half the data storage requirements.
Combine this with a financial incentive to generate transactions that have more inputs than outputs and a one year maximum chain size and a DHT for storing 'pruned' transactions and you would have a solution that would probably be about the same size as the account tree.
There is another technique that is probably just as effective as account trees and that is the use of smart compression of both the transaction data transmitted and the database.
In the current block chain there is a ton of redundant info: same address in multiple transactions, trx id referenced once for each input is stored multiple times if a trx has many outputs. These are all 32 byte numbers that could be reduced to 4 to 8 bytes and yield a 50% savings for the second use and 75% for each subsequent use. With a proper protocol for agreeing on what these identifiers are (say first bits... ) I estimate you could double the transaction volume for equal bandwidth and half the data storage requirements.
Combine this with a financial incentive to generate transactions that have more inputs than outputs and a one year maximum chain size and a DHT for storing 'pruned' transactions and you would have a solution that would probably be about the same size as the account tree.
July 15, 2013, 09:58:41 AM
The solution to scalability must be parallel chains each supporting perhaps 500K users max. Unfortunately, this would mean that there would be 1000's of crypto currencies and markets for trading between them as they would not be fungible. You would need a crypto-currency that had some other properties that drive its value so that it is effectively pegged against some outside unit of value while still remaining 100% trust-free. As a result it wouldn't matter which 'alt-chain' you were on, your unit of account would be dominated in 'silver'.
I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.
I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network. Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.
The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system. There are significant space requirements for large merkle trees that only update a small fraction of the tree. If you opt to save space on your merkle tree, you quickly become CPU bound. Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.
*edit* One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support. This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.
I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.
I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network. Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.
The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system. There are significant space requirements for large merkle trees that only update a small fraction of the tree. If you opt to save space on your merkle tree, you quickly become CPU bound. Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.
*edit* One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support. This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.
Hm i think off chain transactions for small to medium sided transactions and the blockchain for large transactions and as a clearing house to be used by the firms that provide the off chain accounting is a better solution than 1000 blockchains.
Jump to: