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

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.

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.

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.

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.   

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. 

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?

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

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.

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.

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

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.

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

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

Due to this modification, every single deduction in the balance sheet would be signed by the balance's private key owner.

Similar to bitcoin and unlike the miniblockchain, txns could not be forged only deleted.
Similar to the miniblockchain and unlike bitcoin, you would not need to preserve records of all history. Instead you could preserve snapshots.

I'm not sure if the snapshots can be telescoping or not yet (I can't figure out how they could be, but feel like someone else probably could).

I'm also still puzzling over the details of attaching PoW to snapshots and interweaving this with PoW attached to current balance sheet updates.

[I can do this later. I have been on two economy night flights within a 48 hours span. I feel like one of those hangovers where you wake up drunk.]

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.

So you work with bitfreak for this? Or you follow your own designs (seen them in other threads).
Just to add something, I think that in the long term any coin should adopt P2P exchange infrastructures and be like Ripple (coin+platform).

In time...

The bloat may not be a problem for you, but I am building a blockchain with built in exchange which means having as much data as possible in Ram to match bids / orders.  It also means an order of magnitude more transactions.  If you end up paging things out to disk that will be a problem.   I will also have clients that want to be on multiple parallel chains at the same time and thus what isn't a problem for one chain can become a problem when you start multiplying the problem.

Supercoin

EDIT: PeerCash is great!

This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

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.

I think it is possible to overcome this "problem". You need to introduce POW that depends on historical superblocks, but not recent history. I am not going to specify the details because I don't have a clear enough understanding of the problem yet. You should be more hesitant to declare things impossible.

Useless to solve perhaps, but impossible, no, I strongly suspect you are wrong.