Building the Next Generation of Crypto-Currency (developers required)

[bitfreak!]

You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.

It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

User signs balance A using private key and another balance B.

And what would happen if the balance of the receiving account changes before the transaction is accepted into a block? What you suggest would still produce signed transactions, the data being signed is simply different, and signing the balances is not the best way to do it.

[lexxus]

It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

Correct me if I'm wrong, but what you propose looks like Ripple Ledger+PoW. I think it is also a viable approach.

[bitfreak!]

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.

Well so far it seems like BitShare is going to function as a Decentralized Exchange / Messaging System / Storage Network. It's a very different project from this project, it will require much more work and effort to build a system which is capable of providing all that functionality in one package.

This project is an attempt to bring together many new ideas, but those ideas are basically just focused on creating a more efficient and speedy crypto-currency, not to build a multi-function alt-coin designed to do all sorts of weird and wonderful things. It is designed and streamlined for one job only: to be a virtual currency.

BitShares sounds like a decent idea, but then again I think some of these systems simply work better by themselves and don't need to be integrated into one unified platform. Torrent technology and file upload services already provide all my storage needs and I wouldn't care about using BitShare for that.

Likewise, all my messaging needs are already taken care of by free email and chat services. For secure encrypted email I some times like to use Bitmessage because it provides all the functionality I need and avoid spam. If I needed to safely send a large file I'd just encrypt it and then upload it to the net.

However I will say that if a decentralized system can be designed which is capable of handling messages and large file attachments, with the ability to pay to have messages sent quickly, that would provide advantages over Bitmessage, but I'm sure there will be scalability issues and other difficulties in attempting to build such a system.

[aaaxn]

User signs his own balance A using private key and another balance B.

Validity rules for inclusion of balance sheet update in block (these replace txns):

New balance A < Old Balance A
New Balance A - Old Balance A + balance B = 0

You need to privide more details, because I see lot of ways this could go wrong. For example it won't work without txns serialization. You send money to B but while your tx wait for inclusion in block your balance changes and you end up sending other amount than requested. And also remember attacker can create valid signatures for his own accounts so he can sign something which isn't true and you can't tell if he did because old txns are lost.

[bytemaster]

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.

Well so far it seems like BitShare is going to function as a Decentralized Exchange / Messaging System / Storage Network. It's a very different project from this project, it will require much more work and effort to build a system which is capable of providing all that functionality in one package.

This project is an attempt to bring together many new ideas, but those ideas are basically just focused on creating a more efficient and speedy crypto-currency, not to build a multi-function alt-coin designed to do all sorts of weird and wonderful things. It is designed and streamlined for one job only: to be a virtual currency.

BitShares sounds like a decent idea, but then again I think some of these systems simply work better by themselves and don't need to be integrated into one unified platform. Torrent technology and file upload services already provide all my storage needs and I wouldn't care about using BitShare for that.

Likewise, all my messaging needs are already taken care of by free email and chat services. For secure encrypted email I some times like to use Bitmessage because it provides all the functionality I need and avoid spam. If I needed to safely send a large file I'd just encrypt it and then upload it to the net.

However I will say that if a decentralized system can be designed which is capable of handling messages and large file attachments, with the ability to pay to have messages sent quickly, that would provide advantages over Bitmessage, but I'm sure there will be scalability issues and other difficulties in attempting to build such a system.

Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.   

[bitfreak!]

Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.

Oh ok, well that makes a bit more sense then. Personally I think the bit postage idea is worth building first because even if you can't support massive file attachments it would still be nice to use bitpostage coins to pay for postage, or something like that, instead of having to generate the proof of work with each new message you want to send. That was the basic idea right?

[bytemaster]

Bit shares and bit postage are two different ideas and chains.  I would not dream of combining them.

Oh ok, well that makes a bit more sense then. Personally I think the bit postage idea is worth building first because even if you can't support massive file attachments it would still be nice to use bitpostage coins to pay for postage, or something like that, instead of having to generate the proof of work with each new message you want to send. That was the basic idea right?

Well I have funding for bit shares.    The bigger idea with bit postage is that you can pay for storage not just transmission.  End result is massively decentralized torrent of everything.  Clearly something that should be built.   After bitshares. 

[bytemaster]

Solution for erasing chain history:  you can delete all transactions after '2 weeks' provided you have a proof-chain difficulty that is at a all time high from the last 'trusted signature' on the block state.  If you have stayed connected, then you do not need any signatures and thus keep rolling on 1 month or even 1 week intervals.  The 'first' trusted signature is the genesis block and others can be added like the bitcoin checkpoints. 

The challenge is having the new node connect to the network.  If the difficulty is not at an all-time high then they must download all transactions back to the last 'check point with a trusted signature' or the all time difficulty high.

The complete transaction history could be stored in a distributed manner and thus new nodes could connect and verify as far back as they need to, including all the way back to the genesis block.   There would be little need to do that however because there are enough other 'checks' that you can perform to validate that you have a 'trustable' initial condition.   The primary check being, 'does your initial condition have consensus' among all of your friends, family and merchants.

Why does this work?   Because any attacker attempting to build on a false proof-chain would have to have 100% of the hashing power of the network starting at the time of the fork in order to prevent a drop in hash power on their fork.    They would then have to grow their hashing power at the same rate as the main network to create believable alternative history and thus alternative initial condition.   If they ever went 'public' with a 1 month old 'remerge' people would demand the complete transaction history before they could accept that merge and therefore all they could accomplish is a double spend.  Otherwise they would have to 'isolate' their victim.

Now lets assume the attacker first uses their hash power to increase the difficulty on the valid chain, then they switch all of their hashing power on to a new 'false chain'   The main chain and the 'false chain' would each experience a fall in difficulty and thus all nodes would store all transaction history until a new high was reached.   To effectively attack this system would require far more than a 51% attack.  It would require an attacker to 'instantly' switch on a level of hashing power equal to 101% of the entire network and even then they could only potentially 'fool' new nodes by presenting a false initial condition.   Such an attack would be very public and thus everyone would know and clients would be updated to 'reject' the bogus chain. 

Another factor that will enable users to identify the 'true chain' is to ask any merchant what the 'current chain' is.  The merchants would be running full nodes around the clock and thus could not be 'tricked' by a bogus initial condition and any client that started up would simply ask a handful of trusted merchants what the initial condition is. 

Conclusion:  you need the proof-chain all the way back to the last trusted/signed state (perhaps the genesis block) and this chain is very valuable for telling a client how far back they must validate transactions upon a new connection to the network.  Once connected to the network almost no transaction history is required provided you keep track of all unspent outputs.   The only transaction history you must maintain is enough to cover all reasonable 'chain merges' which should be 1 week to 1 month at most.   This 'stored transaction history' could be distributed and queried as necessary when a merge happens and therefore most 'light nodes' could discard transactions and let the 'full nodes' keep them in case of a merge.   

[bitfreak!]

Conclusion:  you need the proof-chain all the way back to the last trusted/signed state (perhaps the genesis block) and this chain is very valuable for telling a client how far back they must validate transactions upon a new connection to the network.  Once connected to the network almost no transaction history is required provided you keep track of all unspent outputs.   The only transaction history you must maintain is enough to cover all reasonable 'chain merges' which should be 1 week to 1 month at most.   This 'stored transaction history' could be distributed and queried as necessary when a merge happens and therefore most 'light nodes' could discard transactions and let the 'full nodes' keep them in case of a merge.

I really don't understand what you are talking about, the transactions are stored within the mini-blockchain like the normal blockchain. When a block is trimmed from the mini-blockchain the transaction data is discarded with it but the block header (or proof cell) is kept as part of the proof chain. When a new node connects to the network it doesn't rely at all on validating transactions, the new node simply attempts to obtain the proof chain with the highest cumulative difficulty and then obtains the mini-blockchain associated with that proof chain. If the new node detects two competing chains which originate from the same proof chain it will execute the contingency measures described by aaaxn. There is no point for a new node to validate transactions when synchronizing because the whole idea is to discard old transaction data and rely solely on the proof chain to prove which mini-blockchain is the right one. Once the new node is properly synchronized with the network it will then start validating new blocks as it receives them, like any normal node. There is no need to track all the unspent outputs or anything else, and in fact there is no such thing as unspent outputs in this system because it uses an account ledger.

[bytemaster]

I understand your account ledger system which is effectively just 'unspent outputs' assuming each output was a unique address.

I am dealing only with the more theoretical how does the mini-chain agree on the initial condition.

[bitfreak!]

I am dealing only with the more theoretical how does the mini-chain agree on the initial condition.

I'm not sure what you mean by "how does the mini-chain agree on the initial condition", I assume you mean how do new nodes agree on which mini-blockchain is the correct one. An attacker trying to build upon the real proof chain would need to keep up with the hash power of the real chain for a full cycle in order to pull off the attack you brought up. And the attacker would have to do it in secret for a full cycle of the mini-blockchain before broadcasting the fake chain in order for new nodes to be unable to detect it was fake. Obviously such an attack would be extremely difficult to pull off, and I doubt it would ever actually happen. But if it did then the contingency plan described by aaaxn is perfectly adequate for dealing with it. If a new node detects two competing chains which originate from the same proof chain and it cannot determine which is the real one it will simply refuse to participate in the network until the situation is resolved or until the client is updated with the latest checkpoint.

[bytemaster]

That works, so the contribution I believe I made is that by looking at the most difficult block difficulty you can determine the maximum mini-blockchain length required.... you may be able to go shorter.

[bitfreak!]

That works, so the contribution I believe I made is that by looking at the most difficult block difficulty you can determine the maximum mini-blockchain length required.... you may be able to go shorter.

So you're suggesting that the length of the mini-blockchain should be dynamic? I'm not sure if that's really a good idea because many other calculations depend on the length of the mini-blockchain. The concept as it is now is to use a statically sized mini-blockchain (as in the number of blocks is fixed) which would probably hold something like a day to a few weeks of transaction history. However nodes could have the ability to store more older blocks if they wanted. And as aaaxn mentioned, new nodes could ask for those older blocks as a way to help them detect fake chains. Although there would be no requirement for anyone to save the older blocks and things should work perfectly fine without them.

[wizzardTim]

Interested. Keeping an eye on this.

[klee]

Can someone indulge me on how is MC2 and Peercash different in handling the blockchain?

Thanks in advance!

[bitfreak!]

Can someone indulge me on how is MC2 and Peercash different in handling the blockchain?

Well when I read the MC2 white paper a few weeks ago I noticed that it does also make use of a "novel hash tree" but the use of the hash tree is much different. MC2 appears to use a polymorphic hash tree as part of the PoW mechanism, where as Peercash will use a hash tree database for storing information about non-empty addresses so that old transaction data can be discarded. As the MC2 white paper states "The principles of both LTC and PPC are extended in Memcoin2", meaning MC2 is mainly focused on making the PoW protocol more robust and memory-hard and combining that with the PoS concept.

Peercash changes things on a much deeper level. We are totally rethinking the way that crypto-currency needs to work in order to create a more scalable and speedy coin. This is achieved with new mechanisms such as the account tree and mini-blockchain. We most likely wont integrate PoS into the system but are developing concepts which will allow secure 0-confirmation transactions and a dynamic max block size. I hope this has answered your question, but you can always read the wiki or white paper if you really want to understand the idea.

[BrightAnarchist]

Awesome! I have proposed the "rolling chain" concept myself. It's the future for sure.

Do you have a code repository up yet? I absolute would like to contribute to this project.

[bitfreak!]

Do you have a code repository up yet? I absolute would like to contribute to this project.

Yes we do but it's still empty: https://github.com/peercash/peercash

We are still lacking a team of core developers but if anyone wants to start working on the code I would welcome it. It's harder than I expected it would be to get some good programmers in on this project. I think once we get started on the code things will naturally progress at a faster rate and more programmers will be attracted to the project. And it's not like the project is totally unfunded so contributions will be rewarded.

And I'm still not entirely sure whether working in Java is the best idea. Would you prefer to work in C++ or Java? It seems most of the good bitcoin programmers are better with C++ so I'm not sure that building it in Java is the best idea after all. We need to decide this carefully before writing the first line of code.

[bytemaster]

I have a team of 3-4 developers that will be working to implement BitShares in c++ over the next couple of months.  BitShares will be implementing many of the features described in this thread in an attempt to reach the same goals.   

I have significantly revamped, updated, clarified, and extended the BitShares white paper:

https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit#

It will have the following characteristics described in this thread:

1) Rolling / Minimal Possible Transaction History (mini-blockchain)
2) 'account tree' which I call 'unspent transaction outputs'
3) Merged Mining / Proof-Chain
4) Potentially the 0-confirmation (spend limit)

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 

The white paper is open to comments on google docs and I am actively looking for additional feedback and developers.  To the extent that we can pool resources the better.

[bitfreak!]

2) 'account tree' which I call 'unspent transaction outputs'

That is just really confusing. The account tree isn't a collection of unspent outputs, because all the unspent outputs are merged into a single balance for any given address. When dealing with an account tree you're probably over complicating the matter by referring to is as such.

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 

Yes I suppose that would be possible but at this point we're still going with Java and if we did fork BitShares we couldn't start coding our project simultaneously. BitShares seems like it will be fairly complicated and I doubt much of it will really be what we need for Peercash anyway. And the more sensible way to do it would be to build Peercash first and then build BitShares on top of that if we were going to work together.