Hi everyone, the purpose of this topic is to request someone to develop a Self-hosted Grin payment processor Wordpress Plugin!
If someone is willing to develop it, they’ll be more than welcome to test it on my Wordpress website (No-code Strategy game-platform; think Roblox, but more niche).
It’s still in active development and I expect the Working MVP to be done in approx. 2 months from now.
I’m also willing to find someone on Upwork to develop it too, but had a question.
Do I have someone work on a working MVP and be reimbursed after or
will I be reimbursed every week depending on how many hours billed by the developer?
Selfishly this would be very useful to myself and also the community I’m sure.
Simply, my website’s main proposition is for people to Make Levels & Earn Money.
Level Creators earn approx. ~70% revenue-split when players spend BOOM Bux on/in the level(s) they make. I pay out in USD currently, but hope to expand it to GRIN.
BOOM Bux is the primary currency by both the community and staff (me). All paid items within the shop are sold using this currency, including user-created content such as: levels, skins, and unlockable areas in levels.
If it really has to be fully self-hosted, not external listener of any kind, it would require to have a built in (nimble?) node as well as all the ツ-related machinery (producing signatures for transactions etc) implemented in PHP. You would need a very often triggered cron process to re-sync the last N blocks with your Wordpress db. I am not sure how easy it is to interact with a p2p network via PHP.
I am currently (in secret! ) developing toolset for processing ツ transactions and blocks. It is being implemented in Python and is heavily based on grin++ source code. My library is meant to be translated into JS and PHP and will allow to build wallets and nodes in those languages. I also had in mind building a wallet as plugin for Wordpress/Woocommerce/Magento. I am willing to provide access to my source-code for those of you who are interested in taking a look / contributing.
I have some pro experience with online stores (as developer) and I like your initiative a lot, I offer some free of charge consulting help for the person willing to take the task before my library is released.
What about creating a PHP extension that exposes wallet functions to PHP? This is may be the easiest way to re-use grin(++) code. Implementing Grin in PHP seems like a hell of a task to me.
The biggest unaddressed issue for Grin for e-commerce payment that I see is that the private key for signing incoming transactions is needed. This makes any online shop that uses Grin an attractive target for attackers, since the entire wallet value ready to be grabbed. With Bitcoin, no private key needs to be held on the server. With Monero a view key is enough to verify incoming transactions.
It seems to me, like this is the biggest blocker for exchanges and e-commerce with Grin. Either you introduce additional waiting time for someone to sign transactions manually and securely (for example with Ledger), or you hold the private key insecurely on the server. Additional waiting time would be a major disadvantage for Grin, but introducing risk of total loss is too.
The risk could be dampened by emptying the wallet often, but there is some remaining risk.
An ideal solution would be if Grin had a mode where different keys would be required for receiving and sending coins, so that the key on the server could only be used for receiving coins. Then the key on the server would be useless for an attacker, while the server can sign invoices for any given amount.
We could translate grinmw wallet API wrapper by @xiaojay from Python to PHP. That would do exactly what you mean. Such solution would qualify as “self-hosted” but it would be nothing like what most Wordpress users are used to setup. It would require an actual server that can run processes (not just a hosting service) and ability to setup wallet as daemon with V2 API listener always on.
That is true, storing plaintext private key feels very uncomfortable. The only thing that can be done to address this issue is to ensure the plaintext private key is stored in the same way as other sensitive data such as a database credentials etc.
That would also allow more advanced scripting in which transaction is secured on the chain (receiving key known) but outputs are not spendable until certain condition is met (which would reveal the spending key). That would also allow coin burning which is also a useful feature.
I also brought this up many times, unfortunately it is not possible using pure mimble wimble. The closest thing would be to use something like Mingle Jingle:
Unfortunately that would require a consensus change and is also not without its disadvantages.
Therefore I would argue the safest solution is to just auto empty the wallet at fixed times, e.g. weekly or after receiving a fixed number of transactions, e.g. 60. This fits with theRFC for HD wallets and one time use addresses which should make this more easy and standardized:
It is a proven fact to my understanding (I discussed this like 10 times before).
The only solution is to use some on-chain encrypted kind of privatekey-public-key-address), something similar to stealth addresses (Diffie-Hellman key exchange). Once you do this you end up with either the proposal of David or Gene for non-interactive transactions, so basically Mingle Jingle.There are still quite some downside to non-interactive transaction which you can find in the discussion on the forum Mingle jingle (see link above).
To avoid repeating that discussion again, I think it is best to focus now on the one-time use addresses, and payment processors that empty the payment processing account on a regular basis, to semi-cold storage wallet (so a wallet that only comes online now and then).
Using one-time use addresses should also greatly improve the security risks for payment processors.
I think besides of providing lower security for shop owners, this also creates more overhead (emptying wallets regularly). So definitely not ideal from a business standpoint.
@grn Actually, it is not big hurdle when you think about it.
In the RFC I proposed that wallets automatically close a channel and send funds to a permanent account after a fixed number of transactions, e.g. 60.
This means the shop-owner needs to have a node running somewhere, e.g. a strawberry-pi at home , or an exchange wallet, which involves no extra work for the shop owner.
So basically the wallet will just regularly empty temporary use-address accounts on its own, the shop owner does not need to take any action for this nor does the owner need any technical knowledge or understanding.
I am not sure if that really solves anything or if this just shifts the problem to another computer. The funds would be transferred from the shop to another wallet, so they are safe when the shop gets hacked. But since they would be transferred automatically to another Grin wallet, this other wallet still needs to be a hot wallet (so it can sign the incoming TX), so the coins are still not stored securely. Secure would be if the shop owner would put them manually into cold storage (for example with Ledger wallet), but that would require manual interaction, which is a hurdle and I think the requirement to have a second wallet is a hurdle as well.
I am sorry for derailing the thread a bit, but I really wonder what are the incentives that make it worthwile for an e-commerce shop to use Grin. With traditional crypto, the shop just needs to watch a wallet (public or with view key). It doesn’t even need special software, as it could just call an API for that. Incoming TX means, invoice was paid, so release the goods. With Grin the shop needs to implement interactive transactions with hot keys on the server and on top of that needs to be quicker than an attacker to put received coins into cold storage. What is the business argument that convinces an e-commerce owner to still use Grin under these circumstances?
In that case the shop owner receives the transaction and still would require to sign the transaction manually using his ledger, e.g. do this once in the weekend, that should be manageable.
I think in pracitice this will not be an hurdle since most people do have exchange wallets any-how, and they do accept the manageable risks that come with it.
With Grin it is not that different, e.g. both traditional crypto and Grin need to be connected to see if a transaction worked out. So the main difference is the hot-keys which is indeed a trade-off.
Traditional crypto is easier to use than Grin, but only marginally so. Grin on the other hand offers also quite some benefits, such as 1) improved privacy, 2) low transaction costs for a privacy coin, 3) being able to run a raspberry Pi or phone as a full node since you require so little storage for the full chain, which is a great security benefit.
There are many ways to deal with the risk of hotkeys that reduce risks for shop owners.
E.g. 1) In a physical store, air-gaping, the payments are done through QR code, there is not internet talk between the wallets and as such lower security risk. 2) using a hard-ware wallet to sign emptying of temporary usage accounts, secure but would require an action from the shop-owner.
Using an another wallet (online, off-line or with hardware-wallet) to deposit regularly also means that someone will have a hard time and very low reward for hacking you.
In summary, I do not think interactive versus non-interactive transactions are that important of a difference. In the end it is how the ecosystem is shaped and how easy it is to use that determines if people will actually use it. Therefore, I think that is where we should put our effort. Work towards grin hardware wallet, work towards payment processors that are as easy to use as any other crypto.
Many shops still accept and send Bitcoin through insecure channels, leaking the IP of where the wallet is stored and transaction value. These are bigger risks in my opinion than those that come with Grin.
At least with Grin, only the buyer and shop owner know the amount and IP’s are hidden.
For shops that now accept Bitcoin lightning-payments with cheaper transaction cost and better privacy, they have the exact same difficulties as Grin, requiring interactivity. Still many shop manage to accept lightning payments, meaning it is somewhat manageable.
What is possible is for a hot wallet to prepare a set of presigned transactions tx_i: H_i → C_i, where H_i is a hot wallet output and C_i a corresponding cold wallet output (neither of which exist yet). Then whenever the cold wallet has accumulated enough grin to exceed one of the unused H_i, it can transfer the appropriate amount into H_i and aggregate with the presigned transaction to send it to the cold wallet.
Nice! This solution is pure mimble wimble.
If this pre-signed transaction functionality would be added and combined with one-time use addresses, I would argue there is no objection for any shop to accept Grin, actually there are many benefits (inherent to grin) as discussed above compared to other cryptocurrencies.
Thanks, much better than the presigned transactions customer → shop that we discussed last time when this topic came up.
With customer → shop (in a real world scenario) we cannot predict the values of invoices, but with shop → shop owner, we can plan for fixed-sized chunks. If the presigned transactions are small enough, it could happen immediately after every payment.
It is still not great to require hot wallets, but if the risk can be reduced to negligible levels, then it can become viable for business.
Just to follow up on that, I have started a little GitHub organisation dedicated to it. Please see the link below:
I have defined a little roadmap which includes plans for a PHP implementation that would allow development of such tools as mentioned in this thread. There is also Telegram channel linked in the README where you can follow the updates on my progress. Go go angry MW lightbulb!!!
) developing toolset for processing ツ transactions and blocks. It is being implemented in Python and is heavily based on 