LuaPod Proof Of Origin Accounting (AKA: POO)

http://luapod-web.cloudapp.net/index.lua

Rules of LuaPod Moneys:

Code:

     Must have an origin verifiable by the wallets. 
     Every transaction inside the system must contain:
          oTxid -> Origin Transaction Identification
          CID -> Coin Identification
          AMT -> Amount spent from the transaction.
               --> The first transactions to use the unspent amounts are the only ones acknowledged. Others will be ignored/flagged for review.
     A transactions moneys is considered spent after it has left the system (withdraw)

Steps of Withdraw:

Code:

     Add up all user account balances and check against total wallets (Including cache from the cold 
storage) [This will prevent us from going insolvent in any scenario except a full wallet breach.]
     Follow through the account transactions and verify every origin for each moneys via the Transaction 
Signatures. [Will verify the validity of every transaction by mapping their whole history]

Why This Structure?

Code:

	The following system structure can be beneficial by allowing us to continue working in cases where
 certain blocks orphan or invalidate. We may continue working because the system is capable of isolating any
 leaks where money has become in-existent while it is in or has already left the system. In a case where it has
 already left the system; The system will be able to instantly notify an administrator the involved accounts and
 transactions with a proposed solution if one is available. An example of such solution would be the origin 
account where the deposit occurred has extra of the same currency we can simply make the system respond 
for a scenario like this by reassigning the signature on the account chain to have the origin of the available 
moneys. If our user and company agreement allows it we could also convert one of the origin accounts other 
available currencies automatically and reassign the debt to the converted total. In any case where the system 
can not solve the insolvency it would halt and wait for administrative assistance after reporting the origin of the
 insolvency and the users involved.

Rules for Continuing Operation:

Code:

	No servers must have posted halt in the protected database.
	System MUST NEVER be insolvent.

-----Network Information-----

   Network Rules:
      1. Webserver:

Code:

			[The webserver must only be capable of reading information and relaying commands 
without having any direct access or direct command of the wallets. Any transactions believed to be taking place
 on the website are in fact not. The users input is checked and their balances 
verified; Then the system puts forth a structured request that is then processed by the Wallets server.]

2. Wallets:

Code:

			[The wallets must not communicate with any servers but the mysql. They must not take
 any direct user information and assemble their work basedon the information inside the mysql database. Any 
tables being used that are related to the funds of a user must not be written by any server other than the 
wallet server. That means READ only to every server but one. Some information may not even be visible to 
other systems. Any information being read or interpretted by the server MUST HAVE BEEN GENERATED BY THE
 SERVER. The wallets server CAN NEVER BELIEVE any information displayed within the requests table as already 
sanitized or approved. It then checks the users balance AGAIN to ensure the transaction may indeed take
 place.]

3. SQL:

Code:

			
			[The SQL server must not be exposed in anyway to direct net. Any communication done is
 done in a Local network or through a managed Virtual network.All servers within the virtual network MUST be
 assigned specific permissions and roles. The front-end may have read only access to almost all tables; 
INCLUDING ALL OF the accounting tables which are any tables dealing with currency. Within the virtual network servers ARE NOT capable of 
communicating with any other but the SQL or the Hub of the network.]

[This is the current behavior of the LuaPod main and sub-systems]

Any opinions?

I believe a system structure of this nature could have protected many exchanges and perhaps in real world scenarios where finance companies through a fluke were losing millions and not even knowing.