Proposed New Bitcoin System (Without the hashing)

[daviestobialex]

Introduction
The proposed solution removes hashing (mining) completely thus no excessive CPU power is used in generating coins and confirming transactions. Instead machine storage capabilities are used here in confirming and generating of crypto currencies; renting is the new process designed that would once again revolutionize the digital economy.
There are two sides to this solution that would be working hand in hand in other to over haul the mining procedure:
⦁   The first part in what was described as Virtual Decentralized Distributed Banking (VDDB)
⦁   The second part is what is termed as the double verification transaction state
In other for renting to be a success, the above must be carried out synchronously. In the previous system, the coins generated or spent were all in form of digital signatures, hashed into transactions, so there was no real storage entity in which user coins could be saved and everything had to be in the form of transactional signatures. In other to combat fraud hashing was incorporated; thus the proof of work.
   In other to prove ownership to a set of coins you wish to spend, you have to show a proof of existing transactions to which you gained the coins and there is no way in which you could implement this without using the hashing technique to make up for the lack of a complete storage process otherwise the bank, so imagine a real life situation where there was no banking system for us to store and protect our money, we would have to somehow prove how we got the money and somehow have to make sure that the money is not fraud money and that’s what Satoshi Nakamoto did with the bitcoins.
   That’s why in other to remove the hashing, you have to introduce a banking system, which is similar to a real life banking system. VDDB is more or less like a bank on very node that lives on the network and all those banks have to be at sync in other to combat fraud or any form of attack.

Virtual Decentralized Distributed Banking Explained
   
   In a real life setting, the banking entity is always a single unit that holds, controls and protects the money of users and because of how transactions are carried out in real life that banking strategy is ideal, but if you look at a peer to peer system in a digital world, in which it is a security flaw to have one banking system and place it at a single location then that bank could be controlled by an attacker or a certified third party but the whole idea of digital currency is to have a money that is not controlled by any central authority. The only way out of this situation is to distribute the bank on every node in the network i.e. every node has a copy of the latest bank details of very other node on the network, details include:
⦁   The node address
⦁   The current balance 
Example of the bank detail list
 
The list would be compressed, decompressed and edited as and when needed by individual nodes in the process of the double verification transaction state, making a roll back of events very plausible and possible. In case of any changes to one particular nodes’ bank, a constant bank state check is carried out across the network and if it is determined that one node or a few nodes does not correspond to the bank state of majority of the other nodes, a bank state override would be carried out on the few false nodes or that one single false node.
   The VDDB is a guarantee of the number of coins a node possesses instead of a chain of transactional signatures, therefore the number of coins possessed are more concrete than foundational.
The double verification transaction state
   
   The transaction process is similar to that of the bitcoin process, with just a little tweak to it. It is so in other to accommodate and blend with the VDDB though both threads are running separately and independent of the other.
   During transaction, transaction details between Alice and Bob, i.e. if Alice was to send a few bitcoins to Bob. The transaction process would be as follows: Alice would send transaction details to Bob and also to the network. The coins are deducted from his account in the VDDB in other to nullify the double spending attack, so when Bob receives the transaction, Bob would also make an announcement to the network saying it has received the transaction, the nodes on the network which are holding the first transactional details from Alice would be expecting a second state transactional detail from the recipient Bob, if the second state is not received on most or all of the nodes, a roll back is requested on the VDDB on every node on the network.
   If the situation is reverse where by nodes on the network receive the second state transaction, then transactions within a time T would be hashed and confirmed, Bobs’ account would be credited and then the transaction block is added to the main transaction block chain, the hashing that would take place in this process would just be a security measure and would occur within a time frame of seconds. This would mean that the number of leading zeros expected would be reduced to a maximum of ten, 210 would mean trying 1024 times in other to achieve its goal of about 5 to 10 zero prefixes.


   This cryptocurrency process is less expensive than its predecessor, its CPU and energy consumption is very minimal though its storage capacity could be in question but any device with at maximum storage capacity of 2GB would be able to participate in confirming transactions because storage is the key part of this new process and nodes participating are paid with an incentive for their use in storage, this is what is called Renting. Obeying Moore’s law, if the space occupied by the VDDB and transaction block chain per node device is about 1MB with a growth of 500kb per 4 months, then Moore’s law would accommodate for the growth of data on the nodes storage devices.

Figure 3 the New Architecture Diagram


Expected Drawbacks and vulnerabilities
   Well, this new architecture provided in other to level the playing field of cryptocurrencies is only theoretical, as to whether this theoretical solution would hold is up to the original creators of the Bitcoin and top engineers of the Bitcoin society.   
   The only vulnerabilities I foresee is yet only theoretical where by an attacker manages to control more than half of the nodes existing on the network, control in terms of VDDB, thus causing the rest of the VDDB accounts to be changed on the other nodes. This is similar to the 51% attack and very much unlikely to happen because the attacker would have to change all VDDB’s on the nodes at once or else a bank state override will immediately occur on all the false nodes. It’s easy to participate in making sure that the network is safe and secure and that most of the nodes in operation are all honest nodes because the cost of participating is very much cheaper than that of its predecessor so inevitably more than 75% of the network would be participating in moving coins from place to place in other to get a form of incentive in return for their slight hard work.
The double spending attack has been totally removed, and slightly impossible to pull off, and I say slightly because in the computer world nothing is 100% secure.
The 51% attack is not a physical threat to the network only a theoretical threat as explained above.
The race attack also cannot thrive on this kind of system, because immediately a transaction is started it is deducted, it does not wait for the transaction to be complete before the coins are deducted; peradventure the transaction is not complete a roll would occur.

This is just a proposed theoretical solution i came up with in my research on bitcoins but i have a quick question though, when Bitcoin was first launched and every node that came on board had no coins how was the first transaction made? though my answer to this was that the first users or new comers are given some amount of coins on joining the network or on start up but i have no backing on this answer.

Finally this solution might not be absolute or even make sense but just think of it carefully.

[ffe]

How is the VDDB immune to a malicious user that runs 10000000 threads pretending to be 10000000 users with a consensus that is false? He could easily drown out the valid copies of the VDDB.

[daviestobialex]

Valid question by ffe, I also thought of this and I felt it was also a threat to the network, so the best solution I could think of to this problem of the VDDB is to make it a protocol or a security layer in the network (Hope this makes sense) which would hold its own bank state and perform all the bank state checks.

[redsn0w]

Valid question by ffe, I also thought of this and I felt it was also a threat to the network, so the best solution I could think of to this problem of the VDDB is to make it a protocol or a security layer in the network (Hope this makes sense) which would hold its own bank state and perform all the bank state checks.

No one has still proposed a new better (than bitcoin) and functionally 'concept' and I think it is nore really easiest. In my honest opinion the 'worst' thing in the actual bitcoin is only the question of the distribution (halving related) and the asic power.

[daviestobialex]

So the theoretical solution above is null and void? or could it be improved upon?

[monsterer]

The race attack also cannot thrive on this kind of system, because immediately a transaction is started it is deducted, it does not wait for the transaction to be complete before the coins are deducted; peradventure the transaction is not complete a roll would occur.

This needs explaining in more detail. 'Deducted' how? Why can't an attacker just broadcast two transactions and not do the deduction at all?

[daviestobialex]

The race attack is basically sending out two conflicting transactions and having the fraudulent transaction committed first, keep in mind the VDDB and that every node has a valid VDDB account, so if an attacker makes a transaction or two transactions or somehow sends two transactions into the network, the state of the transaction i.e. the amount that is being sent and if that Client(attacker) has enough coins on the VDDB (which is not just carried on that single node but across the network). so for a transaction to be sent, all nodes on the network would have to confirm if that client can make that transaction and if so the sent coins are deducted from the clients(attackers) account. With this the attacker can't spend a coin twice and fraudulent transactions sent into the network are checked with the VDDB except of course the attacker controls or has access to every other nodes VDDB (Though the VDDB would have its own security measure attached to it to make an attackers job very difficult).

[monsterer]

so for a transaction to be sent, all nodes on the network would have to confirm if that client can make that transaction and if so the sent coins are deducted from the clients(attackers) account.

Ok, so the attacker sends transaction A from london and double spends A in transaction B from melbourne. Both transactions are valid at the time they are sent.

[daviestobialex]

First of all, with time stamps they would not be able to do that(Using a Global Clock from the start of the system); secondly once transaction A is rolled out, it would have a time stamp and all processes in accordance to the VDDB would take place as explained in the above, meaning transaction A is either rolled back or committed therefore transaction B would be a new transaction and not a subset of transaction A.

[monsterer]

First of all, with time stamps they would not be able to do that(Using a Global Clock from the start of the system); secondly once transaction A is rolled out, it would have a time stamp and all processes in accordance to the VDDB would take place as explained in the above, meaning transaction A is either rolled back or committed therefore transaction B would be a new transaction and not a subset of transaction A.

Explain how timestamps prevent two identical wallets located in different parts of the world spending the same transaction to different a destination?

[daviestobialex]

I would propose instead of using the time stamps of various time zones/locations the system would have its own Global Clock starting from the genesis of the system.

[bitcreditscc]

I would propose instead of using the time stamps of various time zones/locations the system would have its own Global Clock starting from the genesis of the system.

https://bitcointalk.org/index.php?topic=896133.0

[monsterer]

I would propose instead of using the time stamps of various time zones/locations the system would have its own Global Clock starting from the genesis of the system.

That doesn't help to explain how this prevents double spends.

[daviestobialex]

for example Alice has 10 BTC in her VDDB, and its constant on the very node that she has 10 BTC, immediately she spends 4 BTC from her 10 BTC (Lets say she sends it to Bob), in the VDDB across the network 4 BTC is deducted from her account and she is left with 6 BTC. As to if Bob got the transaction or not, the 4 BTC has been deducted from her 10 BTC so until a roll back (i.e. to say Bob didn't receive the transaction) then she get her 4 BTC back and she can spend it again but once Bob got the transaction or even if it was pending, across the network Alice is left with 6 BTC to her name and if she spends another 4 BTC it would be deducted from her 6 BTC.

[RaginglikeaBoss]

I like the enthusiasm, but you seem to be lacking a grasp on how the blockchain operates.

And sadly your example proves exactly why time stamps don't work, regarding the previous poster's question.

[daviestobialex]

So the time stamping is a glitch in the proposed process, how do you suggest this ideological system can fit into the bitcoin time stamping in other to combat the race attack or double spending attack?