whotooktwarden
commented
9 years ago It may be better to just allow Version 1.1 to be completed for the MySQL database requirements, HTML5coin wallet addresses export scripts, and the storage of these keys in either JSON or CSV format. There are additions to the database that must be implemented. The concept of using multiple shell scripts running in conjunction with cron means several points of failure, so instead, these are the new proposed features for Version 1.2.
We can develop a method of using the database we set up in Version 1.1's release to determine if a user has already added their ripple and email addresses to the database. If the data cannot be found, then we insert it into the database and associate a destination tag to their user data. We then allow for users to deposit HTML5coin to the address that is associated with their account in the database by sending this address via email to the user. The operator receives a notification via email from the user using the Deposit form that they are going to initiate a deposit for a certain amount of HTML5coin. This email will contain the user's Ripple address, email address, currency, the sent amount, the service fee, amount of IOUs to be issued, and the HTML5coin address to be funded. The operator will then manually confirm that this amount has been received. In Version 1.2.1, we can implement a feature which automatically notifies the operator if a validate transaction using the HTML5coin wallet software by posting the amount and ripple address to the payments end-point of ripple-REST, and then issue HTML5coin IOUs to the user. If this update is implemented using this methodology, it allows for the Deposit form to register a user, serve that user its destination tag plus HTML5coin address, and provide a transaction notification for the operator.
As for the withdrawal feature, the code from the Deposit script can be replicated to work with the withdrawal actions. It first queries the database to see if this ripple address and email address are present in the database, if not, then the information is inserted and we fetch new crypto address(es) to associate to this user. We then email the user with this information along with the user's Ripple address, email address, currency, the service fee, amount of IOUs to be redeemed, and finally the Issuing Account's Ripple Address plus destination tag associated with this user's account. The withdrawal script will send this information to the Gateway Operator's email to inform him/her of a transaction notification. The gatewayd software is now unsupported but in August there is a new product called Ripple Connect which will become available for developers to assist with handling deposits and withdrawals; Version 1.2.1 will require this software to assist with processing withdrawals.
The HTML5coin wallet is to be packaged with the QGK to provide a basis for a developer to modify this open source web-kit to accept just about any cryptocurrency forked from the Bitcoin or Litecoin source code. The goals with the future version 1.2 release will include the deposit feature which requires the HTML5coin wallet.
The release of Version 1.1 allows for the data fed from index.php (the default deposit action) into the database. The HTML5coin public addresses will be associated to each deposit transaction through the users table. The deposit script will search the database for the ripple address fed by index.php. If this ripple address is not found, this user's email address and ripple address are added to the database and associated to a public key, this key is then emailed to the user so they may complete the deposit to the Gateway.
The HTML5coin wallet will receive notification of the deposit and at a number of confirmations, default 2 confirmations, will credit the user's account. The usage of rippled to process deposits is out of scope for this version, this will be done in a Version 1.2.1 release.
Instead, the Gateway Operator will receive notification via email with the usage of a new script, default_deposit_confirmations.sh, which is ran by a cronjob.
First, this script will require an addition to the MySQL database: default_deposit.
The default_deposit table will have a PK of default_deposit_id int auto increment not_null. The FK is user_id to associate the user with this deposit action. The deposit script will require modification to allow for an insert statement to be run on default_deposit table where the user_id is called from the database once a ripple address has been inserted to the users table or was successfully retrieved from the database, this is determined by using an IF statement before running these processes in the according likelihoods they would occur.
This approach is modular, allowing for the xd.php and yd.php scripts to have corresponding x_deposit and y_deposit tables with the same attributes mentioned above. This same code for the deposit.php script can be ported to xd.php and yd.php as well.
The features of default_deposit_confirmations.sh will include:
Run a HTML5coin command to check for any incoming transactions for confirmations less than the number of allowable confirmations: max_confirmations int default 2.
We need to send an email to the Gateway Operator 0, 1, 2, or possibly more confirmations. This is determined using an IF statement by using the max_confirmations variable as the delimiter: IF confirmations less than max_confirmations (default 2), then perform these actions:
Using an echo "CONTENT" | mail -s "UNCONFIRMED DEFAULT DEPOSIT" OPERATOR@GATEWAY.COM statement we need to send the following information to the Gateway Operator: default asset amount, the sending address, the receiving address, and perform a SQL query on the default_deposit table to determine the user_id for this transaction; we then include this value in the email. Finally, include a SQL statement which fetches the ripple address associated with this user_id.
Elseif this is the max_confirmations limit, so we send this information using the same process above but change the subject to CONFIRMED DEFAULT DEPOSIT. This script can then be replicated as x_confirmations.sh and y_confirmations.sh respectively and modified as required by the developer.
@ripple We are probably looking at a couple to a few months to work on these proposed designs so the scope of this web-kit can become much greater than initially planned for. I am curious as how to proceed further with the funding available on Bountysource. It is probably too early to ask because I would appreciate a critique on these proposed additions in their current state. I know that these proposed changes could be drastically different in reality, I may have submitted this proposal in vain due to something I may have overlooked research-wise, but I would like to know how much should the bounty associated with these base enhancements be worth for a complete solution?