Hi all. As some of you might have noticed moneypot is discontinued due to a lack of interest.

If you are interested in a service which offers a similar product you can check out blindmixer.

As always: use at your own discretion.

Would you care to eleborate your "obvious reasons"? Quite curious.

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...

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.

---

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.

---

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://bitcointalk.org/index.php?topic=5302025.msg55964303#msg55964303

Bump! Let us know if you have any unanswered questions!

Hi! Just wanted to let you know that hookedin has been rebranded into "Moneypot" and is currently live on testnet for anyone to try out:

https://wallet.moneypot.com (using: https://testnet.moneypot.dev as the custodian)

Curious to know what the current state of the other project (Scrit) is? Can't find any representation on the forum though there seems to be some stuff on github which does not immediately make clear how far they are in terms of development..?

---

To reiterate some stuff that also has been mentioned in the ANN thread:

- moneypot allows for (free) internal transactions (using internal lightning invoices, if you were wondering how to try it out), and is supposed to be completely free of any unproveable repudiation by making almost all interaction certified by signatures proving your intent, both from the custodian and the user. So (almost) every action is hashed and then signed using the keys of either the custodian, or the keys of the coins involved in the transfer if the action is coming from the user. The idea is that both parties verify this during and after the transaction to keep communications fair.

The biggest caveat currently is that it still is a centralized entity, which apart from naturally raising anguish and discomfort, makes it especially vulnerable to attacks from third-parties, insiders (us) and mistakes in the custodian code that go unspotted (though we are fully open-source).

---

With the upcoming Taproot activation, it seems like an interesting option to explore to see if we can leverage schnorr either in the form of multisigs or threshold sigs schemes to make moneypot decentralized in the sense that funds are held by multiple signers and every signer keeps their own record of all off-chain actions, and then have a master custodian relay all actions from users and initiate on-chain transfers... If there is enough interest in this whole chaumian bank idea at all.

Though the above description of ideas is intentionally vague and not so much concrete because I (at least) am not (yet) well-acquainted with said scripting (threshold sig), and the upcoming taproot update, so we will really have to look into this to see if this will even be possible to concoct in combination with stuff such as lightning.

---

That being said, we're currently in the process of gathering some feedback before deciding if we're going live on mainnet, so if you're interested in trying out the wallet, I'd say eat your heart out! We are really desperate for any criticism at all!

That error has nothing to do with tor itself, but rather the browser you're using. Tor browser (and presumably "Tails Browser" which is a derivative of the former?) does not allow sufficient access to stuff such as the indexedDB, as mentioned.

If you CTRL + SHIFT + I it will probably say the following:

We've not found any "fix" for this yet as it seems to be a feature of the browser rather than a bug, but as mentioned previously, a browser which does not retain most data is not really that great to use in combination with moneypot in the first place.

Try to refresh your connection?

While trying to replicate the issue it seems that the hosting for our wallet (Netlify) seems to deny some tor exits, but allow most. A trivial error from our side.

For example, loading the wallet with 185.220.102.248 or 185.220.101.20 seems to give this error, but 185.220.101.(3/24/204/21) work fine.


Not entirely sure if this is what you're experiencing, but I can't quite replicate the issue any other way. Will look further into this and see if netlify offers some sort of bypass like cloudflare does.

Even better! In that case you should be able to install tor by using `apt install tor` (on most distros), and set the socks5 proxy of your preferred browser to
For Firefox simply search proxy in settings -- manual configuration -- SOCKS host ... Perhaps this is a bit uncomfortable in comparison with the tor browser... Apologies, but there is not much we can do for now.

We use Bitcoin Core's `estimatesmartfee` though we have done fairly limited testing on mainnet to see how accurate these guesstimates actually are. Hard to simulate in a testnet environment. Definitely something we look to optimize further if it turns out to be necessary.

Please further detail what is not working for you, for example:

are you:
1. - unable to send a lightning payment from moneypot to an invoice at HTLC.me?
or
2. - unable to send a lightning payment from HTLC.me to an invoice generated from moneypot?

Just tested both ways and it seems to work fine....?

While we do offer the pubkey of the lightning node (go to wallet -- FAQ / GENERAL), it is not clear what you're trying to do. Opening a channel with us won't give you any balance inside your wallet.


Node

We could probably let you pass expiry time as a variable when requesting an invoice which would allow users to set the expiry time themselves, but what exactly would the use of this be? Seems to only add unnecessary complexity?

We use cloudflare to determine if you're behind tor, but it seems that this api is not correctly identifying tor exits.. I've encountered this myself, so this is something we'll need to look into, although it is very important to make users aware that they should at least use a rotating IP.

IPs are one of the few obvious things we (or other parties that are between the custodian and the user) can undetectably log to link your in and outputs together.

You're right. On our TODO list. Perhaps we should just remove the links for now.


Here's where things get tricky, and perhaps have been explained a bit poorly from our side of things..
While we absolutely recommend you to use tor, due to the level of access the wallet requires from features such as indexedDB, it seems impossible (for now at least) to use it in combination with the Tor Browser itself.

It also would not make much sense to use the Tor Browser as it does not persist most data (cookies, local storage), which for the moneypot wallet would mean that you'd have to resync your entire wallet every time you open your browser.

So a workaround would be to download the standalone tor client (if on windows), and set the socks proxy of your browser of choice to
These are the recommended fees to get confirmed within 6 blocks, and so if you were to make a "batched" transaction using moneypot, which means you only pay for a single output (32 vbytes in most instances), it would be significantly cheaper than using any other wallet (where you will always pay for the entire transaction, so roughly 561 WU against 32 * 4 WU).

Of course, you'd need to wait for an initatior that is willing to pay for an IMMEDIATE transaction, so depending on the number of people using moneypot this might take a significantly longer time than liked.

You can also send custom transactions with whichever feerate you like (1 sat/vb) while paying for the entire transaction. And, if above 0.01BTC (for now), a free transaction, but this only gets send if we find an "optimal solution" in regard to input usage (no change). which again could take longer than liked to be sent.


We will probably scrap these "consolidation fees" completely for any incoming transfer over 100k sats, as it's really not meant to be anything other than a deterrent from users sending dust to our wallets from stuff such as faucets. Our business model is not centered around collecting fees from in- and outputs in any way.

Hello everyone! Due to a number of unforeseen reasons our mainnet custodian has been offline for the last couple of months shortly after the initial launch, as have we. No user has been negatively affected by this.

We plan on coming back in the very near future in a more planned out fashion than we've done hitherto.
In the meantime we are testing out the custodian and wallet software on testnet. You can get a feel for the wallet and give us feedback if you'd like to do so.

Our project development thread can be found here.

https://bitcointalk.org/index.php?topic=5349725

We would love to hear your opinions! Anything at all, granted that you are sincere.

---

Please note:

We currently do not offer any monetary reward for reporting bugs that cause severe security issues such as exploits that cause loss of funds for the custodian operators, as was previously mentioned in the OP, however we would still love for you to report them to us.

Hi, we understand your concerns. We fully acknowledge this issue and we have done everything short of making the wallet decentralized to mitigate this issue as much as possible, mostly by ensuring that all communication between the custodian and the user (wallet), is proveable to be fair. This basically entails that either the custodian can scam everyone, or no one, as scamming individual users can be proven at all times, or so is the idea at least.

Currently for a wallet with the features of moneypot (we use blind signatures to essentially let the user blend in his inputs between all the other users) not having full access over the users onchain inputs seems impossible to merge with these said features.

Decentralization seems feasible, but not at this stage.

It seems you've reviewed our landing page. What exactly was not working? It should show everything properly now.

our wallet is located here if you wish to try that out as well:

I'm not sure I understand what you think it lacks? It's meant to give a quick impression on how moneypot differs from your regular webwallet and showcase its unique features in comparison to, say, blockchain.com.

---

The testnet custodian is back online!

That's interesting.. Had hoped that this would have been self-explanatory, but guess it needs further addressing.

So boiled down to a couple simple steps you basically do the following:

1. Take the custodian URL. 2. Visit our wallet. (https://wallet.moneypot.com)
3. Insert the custodian URL in the corresponding field, insert a wallet name, and optionally a password.
4. Click "Create Wallet".

(5. Ignore the poor spelling on the wallet landing page!)

---

Please note: we currently have some downtime on the testnet custodian. Will update once it's online again.

This thread serves as a place to give feedback on moneypot.com and its software.

If you are not familiar with moneypot, please read up on us here: ANN, or read our FAQ & overview on the website: moneypot.com

To get a starting balance, you can use any testnet faucet or lightning wallets such as HTLC.me.

You can access our testnet wallet and try out our lightning & onchain transactions at wallet.moneypot.com using as the custodian.

---

We would love to hear your feedback, questions, and criticisms.

---

There currently is no active bounty program (as was previously described in the ANN thread) but reporting severe bugs & design flaws is always extremely appreciated!

The software is still very peril so we're looking to improve it any way we can!

---

Current bugs that we are aware of:

[MEDIUM]: On-chain deposits are failed to be accredited when confirmed on rare occurence. We are investigating this further but are unsure what exactly this is caused by at this time.

No, for some reason tor did not properly restart. This is a mistake on our end and I simply didn't notice it until now.
It should work now.

Thanks, that's great to hear!


I think it should work fine with Brave + privacy mode. To be quite frank -- I don't think we know exactly why it does not work using the tor browser, just that it is probably related to the limited access to certain instances. I should investigate this further.

Please note that tor has significantly longer syncing times due to the higher latency. That might become an annoyance if you use our wallet together with something such as "Privacy Mode", as you'll have to constantly restore your wallet, as i previously pointed out above.

⭐Name: Moneypot
🔹Clearnet link: moneypot.com
🔹Tor link: We do not have a tor link for the wallet script. We do have a tor domain for our main custodian!
🔹Bitcointalk thread link: https://bitcointalk.org/index.php?topic=5302025
🔹Fees:  1000 sats for P2WPKH, 5000 sats for P2PWPKH-in-P2SH (Anti-Dusting) (+ Network fee) If the deposit is larger than 0.01BTC, the fees are respectively 100 sat and 500 sat.
🔹Minimum amount: 1000 sats if P2WPKH, else 5000.
We also support lightning!


If you need any other information, please let us know. We're more than happy to answer any and all of your questions!

We should perhaps mention that we use blind schnorr signatures, and thus we would function as the first and only centralized entity that provides "provable privacy"!

Hi, thanks for asking!We've seen this error before and I don't think we have a solution for this. I believe the standard Tor Browser does not allow sufficient access to IndexedDB, no matter the settings; hence the error.
I have to admit I'm not 100% certain on this so I might have to get back to you on this.

Please note: it is not recommended to use the tor browser or settings which make the browser behave similarly, think: Incognito mode, in combination with the moneypot wallet since everything is stored client-side*.
*Using the standard tor browser, this would mean you would have to "resync" your wallet each time you wanted to "login", that is, if the tor browser would work in the first place.

Instead, we recommend you use a browser such as firefox together with the expert bundle. Go to your proxy settings, and set 127.0.0.1:9050 as your socks5 proxy.
Let me know if you need any help with this.

See my previous answer.

Well, decentralized != non-custodial. It would just mean that we would (probably) use something like multisig for our deposit addresses and signing, and find a couple trusted forum users to hold some of the keys.

No, we use blind signatures to provably unlink your inputs and outputs within our system. Else we could just use regular schnorr signatures.


This a good question, and allows us to dive deeper into the philosophy with which we crafted moneypot.
So with any regular centralized exchange or mixer, you, the client, almost always assume that they are your "friend", whether that be in the promise of not keeping of logs, or sending transactions of the right amount to the right address.

We at moneypot have taken a different approach. We assume that anything that the custodial server CAN exploit, will exploit, and so we've attempted to protect the client from that.

And so to provably preserve your privacy we've implemented blind signatures, as mentioned above. However, the custodian cannot reasonably claim that it does not log your IP, because it is able to do so.
We don't actually log your ip!

So, to be completely "protected" from the custodian server with regards to your privacy, you will also need to mask your IP, and we cannot do this for you. Thus the warning.

Note: It doesn't really need to be through tor, you just need to make sure that the request for a hookin (deposit) is made with a different IP than the request for a transfer (withdrawal).

In conclusion, what happens if you don't use TOR? well, nothing. You just trust us and the hops between us to not log your IP and to not tie that to your requests.

---

Update: I have not heard back from this user, so I assume this issue has resolved itself. If not, or if you think certain parts could be improved  (that which supposedly caused your issues), let us know.

---

Sorry, I glanced over your post.

See the answer above.

We don't. We'd rather seen that moneypot was decentralized as well. This is definitely something we would love to do in some distant future.

However, certain features of the wallet wouldn't make much sense in a non-custodial setting.

If we had no control over your funds, implementing a blind signature scheme wouldn't make much sense. In terms of lightning and fees, there would be no way to really differentiate from already existing and established wallets.

From a user POV, moneypot works just like your regular bitcoin wallet.

You deposit bitcoin by sending it to an address only we have the keys to. Once the BTC are confirmed, you will be able to claim your "coins" (this all happens automatically).

Note: for those interested, A "coin" is nothing more than a public key that has an (unblinded) receipt (signature from the custodian) for a certain magnitude (which has an associated signing key).

For the client, this is no different than what you would normally do. You don't really notice the entire scheme, at least, that's the idea.
You can choose to pay to an address, or a lightning invoice. Upon initiating a transfer, the wallet sends the coins (up to the amount requested) to the custodian. The custodian checks the validity, and whether or not they have been spent before, and if you actually authorized the transfer of these coins.

If that all checks out, it will attempt to fullfill the requested transfer, or offer you a refund. If you had sent more coins than required, e.g you sent two coins with magnitudes 3 and 4 (2^3 and 2^4), while the transfer was meant for 20 satoshis, you will also be allowed to claim the remainder (2^3 + 2^4 - 20 = a claim to a coin of 2^2)
(A refund really is nothing more than a claim to new coins.)

That's basically it. All this is done provably-honest, meaning that you provide signatures to the custodian signing your transfers with the inputs (coins) you're using, so that you cannot claim that the custodian sent out a transfer of the wrong amount, or to the wrong address. Because only you have access to the private key belonging to the coins, and thus only you can create a valid signature. Both parties can independently verify this after and during the transaction.

Hey, this doesn't sound quite right. Moneypot is supposed to be 100% automatic both in receiving deposits and making transfers.

Could you try to
A. sync your wallet

and if that does not work B. PM me your txid, so we can work from there.

I'm a little confused though: Did you attempt to deposit funds, and have they not been credited yet; or, did you attempt to withdraw, and has the withdrawal not been sent yet?

"The bonus transaction" was done through a fake lightning invoice.

What priority did you use?

Huh, this is kind of interesting.

Either someone has found an exploit within our code and somehow turned their 0.0005BTC into 0.0025BTC, and stopped after that, (which would be weird, because they could've grabbed more bitcoin) or someone here actually controls 5+ of the accounts I gave BTC to.

That's... funny, and perhaps I should've seen it coming.  .