Thank you for your comment. So I take it you state the following: a) it is not possible to make sure a user edits a certificate for his benefit; b) even while a certificate is not edited, doublespending could be achieved by using old certificates; and c) a person might run a great number of nodes in order to help themselves validate cheatful transactions.

So I attempt to refute.

a) Whether you are talking about the certified user or the certifier user, it is true that both will have rights to edit the file as per their filesystem. However, if a certified user edits his certificate, he will only be able to corrupt it, since it will be encrypted by the certifier user and hence not readable by the certified user. This is, given a strong enough method of encryption is used, and of course: that the users are not associated in any way (see c).

b) Certificates will have, encrypted within the wallet data, a wallet transaction counter. This will help nodes tell, from a number of certificates required for the transaction, if there is a certificate which is older and therefore not valid. (Every new transaction the counter is updated.) This needs not to be punished, since a node that takes a nap will perhaps miss a transaction and in consequence ignore that a certificate it gave is old.

c) It is true: two nodes in fact may correspond to the same user, or correspond to associated users trying to cheat the system. This is why the system must rely on two specific backup conditions: 1) an honest majority of users and 2) the validation of a transaction by specific nodes. While the first point may be quite obvious and understood, since every cryptocoin until now seems to rely on an honest majority, the second may not be as transparent, and here I explain it: if you own a node, you want the system to be healthy, and so you can hand pick several other nodes that must validate a wallet before the wallet can be involved in a transaction with any of your wallets. This way, even if a majority backs up a corrupt transaction, your hand-picked nodes will be able to deny the transaction. The probability that a corrupt node will know which nodes you trust and hand-picked will be extremely low in a big network.

I have come up with an idea to replace the blockchain, but I need you to find flaws in it or join efforts with me! Read on https://docs.google.com/file/d/0B-Sl27NCyKZOY1JuVlR5R3NnNTA/edit

To moderators: Please read this post and consider moving it to a more appropriate section, since this is not a newbie question but a proposal to solve a problem in Bitcoin, and it may be worthy of a proper discussion. Leave that to your judgement, if you will. Thank you for your attention.

Introduction

If Bitcoin is to be the next generation monetary system, it should consider or suppose that one day it will be the only means of transaction, and so every single transaction in the planet will be a Bitcoin transaction. Just imagine the transaction rate, and thus the blockchain growth rate. The growth of the block chain will become impractical to store--if it already isn't, which in my opinion is.

So the problem is: How to get rid of the dependency on the historical block chain?

My candidate solution

I am posting this here so you can find a flaw (or flaws) in this system. If you do, please post an answer and explain the flaw, and if possible, its solution too! (So long as it doesn't involve depending on the historical blockchain.)

What I think is key in finding the solution is the following consideration:


Now, from the above premise, I have designed a system which I now will submit to critique. What I submit below is an array of ideas organized as best as I could so the reader is suggested ideas and then explained whatever is not clear about them.

Please read patiently and keep note of whatever remains unclear as you read. If you have a list by the end of your reading of these ideas, please comment so and I will clarify for you with pleasure.

• The system depends solely on a network of nodes.
• A node has two capabilities in the network: participate in a transaction or witness one.
• A transaction can only occur between two wallets.
• Only a node can have wallets.
• A node can have any number of wallets.
• For a transaction to occur, the participating nodes must trust said transaction.
• A node trusts a transaction when a minimum number of witness nodes it trusts have signed it.
• The trust of a node is expressed with its signature.
• A node can select to trust any number of other nodes.
• A node signs a transaction when it trusts it.
• Only a node can sign.
• A node can only sign a transaction, or a wallet.
• A node can only sign a transaction when it is not involved in it.
• A node can only sign a wallet if it does not belong to the said node.
• "Signing a wallet" is an action alias for the action of the signing of the state of a wallet.
• When a node signs a wallet, the signing node sends the wallet owner node a certificate which attests that the signer node signed the wallet.
• "State of a wallet" is an alias for the wallet's balance.
• A node can only sign a wallet when the wallet is involved in a transaction, or when it is new.
• A wallet is new when its balance is 0 and it hasn't undergone any transactions.
• When a node creates a new wallet, it broadcasts a request for nodes to sign the new wallet.
• When a node broadcasts a message, every node connected to it listens to the message.
• A node cannot refuse to sign a new wallet.
• "Signing of a transaction" is an action alias for the action of signing the final state of the two wallets involved in a transaction.
• A transaction has two states:
•    The state before the transaction.
•    The state after the transaction.
• When a node participates in a transaction, it broadcasts a request for nodes to sign it.
• When a node requests one of its none new wallets to be signed by other nodes, it makes the wallet's certificates available to the latter nodes.
• The signing of a transaction is considered by a node only upon a request.
• A node signs a transaction when it trusts the initial state of both wallets involved in the said transaction.
• A node signs a wallet only if a minimum number of the nodes it trusts have signed it.
• A node only agrees to participate in a transaction when it agrees with the final state of the wallet(s) owned by it.
• A node can only agree with the final state of one of its wallets when the user in control of the node commands it.
• A user commands a node via any of its user interfaces, e.g. GUI and CLI.
• A node can request its user for a command.
• A node asks another for participation in a transaction only when the user of the first node commands so.
• A node can cancel a transaction participation request if the requested node has not agreed.
• When a transaction is completed, the participating nodes automatically discard all old certificates.
• A certificate is old when it no longer certifies the latest transaction of a wallet.

I would expect myself to have left ideas behind (and thus concepts unclear,) for this is a long list. Please comment now if you see that there are unclear concepts.

Of course, this is just an outline of the system. I have intended to define the most essential aspects of it. The system shares some traits with the current Bitcoin system, like it is to be expected.