{...}
What a shame that the only thing seemingly worthy of discussion is whether or not we have a prefabricated, copy-pasted TOS Privacy-policy, while the actual product is completely ignored...
You are handling money and still couldn't get a privacy policy etc. online.. this is highly unprofessional.
Currently there is only a live testnet environment. And yes, we do agree that it is unprofessional to have any sorts of links that 404, but is this really the most pressing issue you encountered while using our service? Have you even tried the wallet?
Seems like we're just discussing semantics here while there are so many other and more interesting topics to discuss relating to our service, though of course, we are happy to resolve this issue.
Criticisms are always duly noted. For now instead of removing the links we've added a placeholder privacy-policy, cookie-policy, and TOS, at least for the time being.
Old Moneypot user here, and actually even used it when they were bought over by MonsterByte (IIRC).
Hi, thanks for your comment! Just want to quickly reiterate that we are not the old moneypot entity, nor do we offer the same kind of product.
the current moneypot wallet is a centralized wallet designed for the individual bitcoin user of which the predominant characteristic is the usage of blind schnorr signatures, while the old product was more centered around bankrolling? casinos.
Of course, the "current" moneypot wallet also allows users to send instant internal transfers to other users of the same custodian.
It's purpose is best described as a hot-wallet of which the intent is that you use it for day-to-day purchases where you would like to have a decent amount of privacy, and where all your deposited funds should be immediately voided in the back of your mind, as you do not control the keys to your exact inputs any longer. (Only an undisputable cryptographic claim to those inputs) that is to say: do not use moneypot for long-term storage of funds or for storage of a large amount of funds. We are completely open about this, and so to immediately discard us under the "Not your keys not your bitcoin" argument really is too short-sighted in our opinion.
They did have one pretty good use case back then (a free/instant transfer in between all dapps connected to the network). Wonder if you might look into doing that as well, encourage sites/services to use your wallet and all users can transfer between apps. Might even help with privacy, though I do see Lightning could absorb a lot of that advantage.
There was a little bit of discussion about something similar to this in the other thread, but this would require the service provider to place a lot of trust in us, as opposed to current processing services such as for example the bitpay servers, which are not custodial.
So there would be two options for what you're suggesting?:
1. Service providers can fully trust us (trust, but verify) and derive customer deposit addresses directly from our fundingkey generate invoices just like regular users of our wallet would, and internally accredit users accordingly.
the users of these services can then request to pay to addresses/invoices to the service providers, and they in turn request the moneypot custodian to make that payment. If the lightning invoice is internal (another service provider or user also utilizing the same moneypot custodian), an internal (free) transfer can be made.
Now two, three problems here: Users need to trust their service provider, and the service provider needs to trust moneypot, whereby the only real benefit to this entire construction is somewhat lower costs in some cases, and no real privacy improvement for end-users. Of course, the third problem being that a correct implementation of this will definitely take a good amount of effort.
So is it worth it? Definitely?probably not. Alternatively instead of the service provider internally accrediting its users it could instead allow them to do this themselves to improve privacy in a meaningful way, but then what was the point of using the service provider in the first place apart from not having to use the original moneypot wallet?
2. Service providers can run their own custodian and users deposit to their own version of the moneypot wallet, which can probably be integrated into any sort of modern shopping environment if the will to do so is there. They get awarded "blinded" coins (in the end nothing more than a balance like in any normal shopping environment) and spend them as allowed by the website/custodian (only on internal products). You could then integrate lightning invoices as a way to easily hook out all these coins to another moneypot product over the lightning network if there would be an interest in doing so.
This way the end-user benefits from a tremendous amount of privacy while shopping. (if the wallet is implemented correctly)
Though again, this would probably take an enormous amount of effort compared to the little benefits that the implementers of such a scheme would reap, not to mention that stuff such as customer support and maintenance becomes very tedious if not impossible. As such it seems highly doubtful that there will be much if any interest in these kinds of implementations specifically for merchants..
This has been more or less discussed here:
https://bt.irlbtc.com/view/5302025.msg55964303#msg55964303