SCAM ARTIST JUSTIN FROM OPENEX, ICEYSCRYPT AND BITBAY
USE AT YOUR OWN RISK. ACTUALLY JUST DONT USE IT
I also suspect he ran Mt.Gox
Topic: LuaPod Proof Of Origin Accounting (AKA: POO) (Read 1293 times)
http://luapod-web.cloudapp.net/index.lua
Rules of LuaPod Moneys:
Why This Structure?
Rules for Continuing Operation:
-----Network Information-----
Network Rules:
1. Webserver:
[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.
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: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)
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]
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.
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.
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: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.]
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: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.]
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.
Jump to: