I was not trying to prove anything, just posted information that you purchased domain recently, and I would hardly call your service new, when it's totally cloned word to word from old dead moneypot wallet website.
Is there any other mixer offering what we are offering? I'd say we are pretty new both in terms of the actual age of our product (not sure why that would matter anyway) and technical advances.
For any mixer to be functional it needs to have good liquidity and I am sure your blindmixer (including ex moneypot) never had any liquidity, but you are free to prove me wrong.
I'm not so sure what you want me to answer; moneypot was barely live (< 3 weeks) and we barely launched yesterday. It seems obvious that it will indeed take some time for people to actually use us (if indeed they will use us at all) and understand what we're about.
And yes, I'd say that you're mostly wrong. For simply mixing your funds: You can deposit funds on-chain and withdraw them off-chain, or do a combination of both (use reverse submarine swaps**) which works as follows: you use our lightning capabilities to pay an invoice with any reverse swap provider to get your on-chain funds back.
If there is an actual interest in this we can open additional channels to facilitate these swaps.
Anyway, voila your coins should be mixed.
** see sites such as boltz.exchange
You can check how much our lightning capabilities are before depositing, so you can roughly estimate how much you can mix in a single session. Now of course we need to loop those funds back in sooner or later to get our outbound liquidity back. A smart observer might take notice of that though I presume that observing that relationship is a very hard problem given that this is actually unlinked + we can vary amounts + we can vary timing (and you can vary swap providers + the aforementioned)
For even less dependence on our outbound liquidity you can also swap in with provider A (so you generate a lightning invoice with us, pass it to provider A and pay him on-chain), then reverse swap out using provider B. (or A). That wouldn't require us to have any liquidity at all. Now if you're the only user doing this it might at some point become apparent, but given that there's at least one other user also doing this you should be fine.
Now you'll probably say that you don't need us to do this, which is true. you can also just pay an invoice at reverse swap provider B using swap provider A, assuming that they won't communicate with each other about your swaps. That assumption is probably fine if you're not under too much scrutiny.
Or you know, open a channel yourself, loop the initial balance out, and use that to swap.
Maybe, but I would argue that risk is much higher using your website that is still in beta, than some proven mixers that exist for years.
I get your reasoning, though personally I don't think it is at all fair to 1-1 compare us to other mixers given that we offer (or so we think) a radically new and different product. We are not just distinguishable by some formula "the amount of time not exit scammed * mixed * spent on the community" (=reputation) (like any other centralized mixer) else we obviously wouldn't have launched this service. There wouldn't be much way for us to compete.
Fearful of what? Surely not about some dead blind project... Roll Eyes
I said or at least very obviously meant (given the context of the sentence) that I think in general (and with blindmixer) it's good to be fearful of the intentions of new services so not so sure why you're trying to zing me over an argument I never made.
I don't think many people will want to use a wallet that takes all their money every few months! Even though you announce it up front, this will likely end in terrible disappointment for some of your customers.
You're right, though I think we can partly attribute it to people thinking of us being a "wallet" wallet, which is not really the case. Poor marketing from our side but it should become extremely clear that we're not at all a wallet in the traditional sense of the word, and more of an intermediary. say like a giftcard (provider). Those expire.. well sometimes at least
Also it would become very attractive for us to exit-scam as it is just a given that there's funds that will be left by some % of users. Perhaps if we offer the community a share in this it might become more acceptable? (the rollover profits that is)
It's also great to have these kind of cut-off points so that when a breach happens, there's not years worth of deposits lost, but instead it is contained for some period. As once we're breached, an attacker could sign for any voucher, basically invalidating all outstanding ones.
I was hoping for an easy implementation of "theymos' Blinded Bearer Certificates".
I think this is exactly what we are, plus additional features. You have the client component which is the wallet (which can be loaded into Electron (works on most OS!), or any browser with storage capabilities), and then you have the custodian, aka "server".
Note that the wallet is completely open-source, you can build it yourself if you'd like. Not sure if the build is deterministic though.
I see that the scheme described by theymos also has a pretty decent flaw: repudiation. there's no way to check if the server is acting honestly, as that requires additional signatures to everything (and or some tricks to deriving the signing address), which is exactly what we did.
For example in his basic implementation the server can spend party C's unblinded vouchers as soon as it becomes aware of it and it can never be cryptographically proven by party C that they didn't initiate the transfer.
I think it's very hard to simplify it further without diminishing UX and security. It's impossible to do this without Javascript/some storage capacity, so really, how could we make it more accessible and more "traditional-mixer"-yy? I get it, most people want just a landing page without JS that's accessible through the tor browser, but this is just not possible / secure.
This would be the bare minimum scheme:
I. say we do the above (noJS, noIDB) and you deposit. the deposit address is already generated server-side without some form of acknowledgement (so you lose honest communications, at least in blindmixer's implementation), as asking for an ack needs some random key E that you'll need to generate, and a signature you need to store (in case the custodian refuses to credit you).
**
II. Now you have a claim to some C bitcoin in certs that is unbounded so it does not require any sort of key E, so the custodian can steal your certs the moment he becomes aware of them
, by simply saying "Oh, someone else already claimed these".
III. How would you claim this? You still need to engage in a signing session for some of the servers public keys BS[10$, 25$, 50$]. that requires some nonce and some operations using that nonce. (that's just the unavoidable nature of the scheme) So should we in this case just display the nonces so you can copy them in a third-party tool to compute the challenge, copy that back to receive your blinded vouchers, which you can then copy and unblind using the same third-party tool to finally claim your funds?
It's not user-friendly at all, especially if you're not that technical.
But hey, what if instead of this third party tool, you use our "tool" which we call a "wallet"?
Above is explained a bit uglier than I would've liked, TLDR: Not sure how to simplify our implementation further.
I really want to simplify using us as much as possible. I'll look into if it's possible to load parts of the wallet's DB in memory so it can be used with the tor browser, though it's probably a lot of effort (not worth it really).
OP hasn't been on Bitcointalk for almost half a year.
