Marmara Connector Software Specifications Document
OS: Operating System
MBC: Marmara Blockchain
UI: User Interface
Issuer: The person who first creates a credit in a credit loop. It is the person who forms the first node in the credit loop. The credit may be collateralized 100% or with even zero-collateralization until maturity date of a credit.
Bearer (Holder): The last node in a credit loop is always called bearer (holder). When someone transfers a credit in a loop, that node becomes immediately an endorser.
Endorser: All other nodes that fall between the issuer, which is the first node in the credit loop, and the last node, and transfer the credit to the next node.
Maturity: The time a credit expires. It is measured as blocks in estimation. The block per day is 1440 (60 blocks an hour times 24 hours a day). Suppose a credit is for 100 days, the maturity is 1440x100, i.e. 144,000 blocks.
Settlement: When a credit matures, settlement is made to the holder, the last node in a loop. Settlement may be automatic or manual.
Escrow: Trust based parties for Protocol 2. If EscrowOn is false, then 100% collateralization is used and settlement is automatic. There is no need for escrows in protocol 1 which works as complete trustless version.
Avalist: Avalists support issuer or endorsers with MCL as additional colletarization and can earn with 3x staking with those support. In case of non-redemption, their funds are utilized. Avalists are available only in Protocol 2. The parameter avalcount is always zero for protocol 1.
BlockageAmount: This is a term for protocol 2. An issuer may be asked to put some collateralization by a holder. In that case, the issuer gets benefit of 3x staking in protocol 2.
Dispute Expiry: It is grace period for solving non-redemption problem in credit loops in protocol 2. An issuer may have this time as blocks when creating a credit under protocol 2 without or insufficient collateralization. Before this period expires, an escrow should do all actions according to aggrement with the issuer to solve non-redemption. Otherwise, the escrow is penalized in the system.
- This software is a desktop based GUI application that has distributions for Windows and Linux OS.
- The software is developed in Python using PyQt library as well as Qt Designer for GUI design.
- Bugs, new features, improvements are handled through github issues on Marmara Connector github page.
- Distribution packages are provided under Releases page with details.
- Wiki is constructed for building Connector from source code as well as for guiding developers to contribute to the open source code base.
- Contributions to the code base are welcomed through pull requests.
- The software is based on Marmara Protocol 1.
- Marmara Connector enables connection to Marmara blockchain running on a local or remote machine/platform.
- The local platform is either Linux, Windows or MacOS based OS.
- The remote platform is Linux based OS.
- The desktop application is used to handle Marmara Credit loop operations as well as wallet operations.
The following parameters are to be handled in the following way at the code base as per decided in Marmara Protocol 1.
-
autosettlement: AutoSettlement is set to true due to 100% collateralization in Protocol 1.
-
autoinsurance: Autoinsurance is set to true due to 100% collateralization in Protocol 1.
-
disputeexpires: Dispute expiry is set to 0 due to 100 collateralization in Protocol 1.
-
EscrowOn: EscrowOn is set to false due to 100% collateralization in Protocol 1.
-
BlockageAmount: Blockage amount is set to 0 due to 100 collateralization in Protocol 1.
- The users described in this document may be the holder, the issuer or the endorser unless it is explicitly described.
- Block heights that represent maturity block must be converted to datetime data and vice versa.
- For the datetime fields, the earliest date should not be before the commencement of the MBC. The latest datetime should not be further than current datetime.
- For datetime fields, a calender view should be presented in the ui for easy selection of date.
- Every word on the ui must be translatable except for the messages directly received from the MBC.
- Actions and calls made to the MBC and received from the MBC must be logged to a log file wherever applicable and should be reachable by the user.
- The user should be able to create a server record having fields of server name, server user name, ip address and server password.
- The fields server name, server user name and ip address saved by the user should be stored in a file readable, writable by the application. The password must not be stored.
- The user should be able to see (read) all his/her server details from the list and able to update them.
- The user should be able to delete a server from the list.
- In the server page; the server name, server user name, ip address and server password must be required fields and any of them cannot be left blank.
- In case the user wishes to update any of the saved server fields, a message should be popped to warn the user if he/she is sure of the relevant update.
- In case the user wishes to delete a server, a message should be popped to warn the user if he/she is sure of the deletion.
- The server details should be stored in a file even when the user shuts down the GUI application.
- The data directory that contains the server details should stay even if the application is uninstalled or upgraded in the respective host.
- The user should be able to create a contact having name, wallet address and pubkey fields.
- The name, wallet address and pubkey fields saved by the user should be stored in a file readable, writable by the application.
- The user should be able to see(read) all his/her contacts from the list and able to update them.
- The user should be able to delete a contact from the list.
- The contacts should be stored in a file even when the user shuts down the GUI application.
- The user should be able to see the name of the person he/she added to the contacts list while making credit loop transactions wherever applicable.
- In the contacts page; the name, wallet address and pubkey fields must be required fields and cannot be left blank.
- In case the user updates any of the contacts’ fields, a message should be popped to warn the user if he/she is sure of the relevant update.
- In case the user wishes to delete a contact, a message should be popped to warn the user if he/she is sure of the deletion.
- The program needs to check if MBC is installed.
- The user should be able to install MBC to the platform (local or remote) if it doesn’t exist.
- In case MBC is installed beforehand, the user may be asked to provide a path to the src folder.
- During installation, a bootstrap option needs to be provided for downloading bootstrap along with information box displaying the relevant info (Bootstrapping is not recommended).
- During the installation, the user needs to be informed about the process and the progress. (Indexing progress etc.)
- The UI should implement two methods for creating a wallet: The user should be able to create a wallet address from his/her own seeds or through the use of getnewaddress command in the UI.
- The user should be able to create a pubkey from the UI (launch MBC with normal launch parameters and execute getnewaddress and validateaddress commands). The errors produced at the backend should be made available to the user at the UI.
- The UI should enable inputting 12 seed words to create private key from one’s own seeds (convertpassphrase). Warning should be displayed such that the user doesn’t include special characters in those words. The UI should return the agamapassphrase, address, pubkey and wif.
- The user should be able to add a private key to the wallet (importprivkey). The resulting wallet address and the pubkey (after validateaddress command) should be displayed to the user.
- The user should be able to reveal the private key corresponding to an address in his/her wallet.
- The user should be able to run the MBC node with a specific pubkey. From a list of wallet addresses and pubkeys belonging to the user, the user should be able to set a pubkey and start the MBC with it. Once the MBC node is started with a selected pubkey, an information could be displayed to the user.
- The user should be provided with an option to start the chain with reindexing.
- The user should be able to start the MBC node with a rescan option.
- The user should be able to stop the MBC node. An information could be displayed to the user informing him/her.
- The user should be able to see and refresh his/her node's Marmarachain status, sync status, current difficult, current block height, longest chain, connections and the latest refresh time from the interface.
- The user should be able to see the pubkey and wallet balances (the normal amount, the activated amount, total normal amount and total activated amount) for his/her node.
- The user should be able to see the total normal amount and total activated amount available in his/her wallet.
- The UI should not allow setting a pubkey that is short in character length. (The software should not create a means for the user to set a wrong pubkey while starting the MBC.)
- Reindexing option should be defaulted to False.
- Rescanning option should be defaulted to False.
- The user should be able to activate (lock) and deactivate(unlock) coins from the UI. Rule: The user should be asked for a confirmation of the relevant operation.
- The user should be able to send coins directly to an address by inputting the address.
- The user should be able to send coins by selecting from his/her contact list.
- The user should be able to generate the QR Code of his/her own wallet address to make a coin receive request.
- A warning may be provided such that the user doesn't send coins to an Activated Address. The user should be noted that this action burns coins.
- The user may be informed that a transaction fee is deducted for the transaction being made from one's Normal Amount.
- There are two modes of the MBC node, namely staking and mining.
- The UI should display the current mode of the node (getgenerate).
- The user should be able to change the mode of the MBC node.
- If the user wishes to change the mode of the node to staking, an information could be displayed that warns the user that there should be an activated amount in the wallet for staking.
- If the user wishes to change the mode of the node to mining, the UI should ask the user to input the number of cores to be used for mining. There should be an option to choose the max number of threads.
- The user should be able to review and confirm the incoming credit loop requests for a given day-time. Rule: The default could be the last 24 hours. If default is not selected, the user shall be able to select a datetime from the calender.
- The user should be able to review the credit loop transfer requests.
- The txid, amount, maturity, receiver pubkey fields should be available for reviewing the incoming loops requests as well as loop transfer requests.
- The user should be asked for confirming the respective transaction. The respective result should be presented in the ui. (txid for confirmation or transaction abort message in case of dismissal).
- The holder (the one selling the product/service) should be able to request for a credit from the issuer (the one paying the product/service) by entering the amount, sender pubkey, maturity in datetime. The holder shall be able to select the sender pubkey (issuer's pubkey) from his/her list of contacts or insert the pubkey manually.
- A confirmation message should be returned to the holder for confirming the credit loop. The resulting txid should be returned to the holder in case he/she approves the transaction. Otherwise, a message needs to be displayed for the transaction that has been aborted.
- The user shall be able to see his/her own transactions (txid) on the explorer site between his/her choice of selected datetime fields.
- The user should be able query the whole MBC for the active loops he/she has and view the loop address, amount in that loop address, amount in active loops, amount in closed loops, number of pending and number of closed loops.
- The user should be able to query a txid to display the details of a credit loop between the issuer and the holder (the amount with currency, the batonid, the maturity datetime, the issuer pubkey).