Frequently asked questions

Check the error message! If there is a blank screen referencing the following error: "Your browser doesn't support big integers. Please see: https://caniuse.com/#feat=bigint", your browser and/ or device is currently unsupported. Either switch or upgrade your browser and/ or device to conform to the aforementioned standards. There is nothing else we can do to help.

For any persistent errors unrelated to this issue, contact our support with details regarding your error and any additional information you're able to gather.

blindmixer uses BIP39 for seed derivation, which makes use of mnemonic words plus an additional optional phrase. An attacker, given that the additional phrase has sufficient entropy, won't be able to do anything with the mnemonic phrase itself, as the seed would be derived from the mnemonic + additional phrase.

Please be aware that this is a two-way street; adding an additional phrase to your wallet also means that you will need that phrase to recover your wallet, as just the mnemonic phrase will not be sufficient.

blindmixer and/ or other custodians cannot help with either of the above-described issues. Please make sure you remember your custodian, mnemonic phrase and accompanying password.

Please note that for each "wallet" (unless specified otherwise by you) the wallet software generates a unique mnemonic phrase.

This is (not so!) great news. If you think you've found a severe vulnerability in either the wallet or custodian software, it would be extremely appreciated if you were to report it. You can do so by sending an email to our support. Certain bounties may be given in the form of monetary compensation or a fictitious share in the rollover profits of certain custodians.

Reporting visual bugs and/ or other nuisances is also appreciated.

Compensation is not guaranteed and depends on the severity of the reported issue.

This may seem weird, but it can happen. One of the most fundamental principles of blindmixer is that all coins (read: inputs) are blinded. As a result, blindmixer cannot determine which inputs originally belonged to you, and which didn't. It is therefore possible to receive your own inputs back.

If this is something you are bothered about, note that there is invariably a possibility that the link is not broken. This is not the or a focus of blindmixer.

Certain measures that could decrease the chances of you receiving your own inputs back could be: switching from lightning to normal transactions and vice versa; waiting a certain amount of time for your original inputs to be used by other people, or spending radically different amounts. These measures should not be confused with literal unlinkability!. Again, this is not a priority for blindmixer, nor possible, so we cannot be of help with such problems.

Please read the next FAQ for a more detailed answer.

This question is a bit of a rehash and or has a lot of common ground with the above-mentioned question, yet it is still important to make clear: NO! blindmixer does NOT offer on-chain unlinkability in the literal sense of the word.

What blindmixer does offer, (that is under the most ideal conditions) is complete unlinkability within its own ecosystem. What exactly does this mean, you ask? For that we first need to explore what exactly unlinkability is, and how it's applied in this context.

Usually in more technical settings unlinkability is defined as follows: Unlinkability of two or more items of interest (IOIs, e.g., subjects, messages, events, actions, ...) means that within the system (comprising these and possibly other items), from the attacker’s perspective, these items of interest are no more and no less related after his observation than they are related concerning his a-priori knowledge. [1S] This means that the probability of those items being related from the attacker’s perspective stays the same before (a-priori knowledge) and after the attacker’s observation (a-posteriori knowledge of the attacker). [2S]

Within the blindmixer ecosystem (whereby the custodian is the attacker), we can speak to the variables that make this possible; that is, if our software is used correctly, this environment can be created. Partly as a result thereof, it is impossible for us to speak to the (literal) unlinkability outside of our ecosystem.

For example: (strictly theorethically speaking; of course there are several practical variables (timing) which greatly influence this) for every coin of magnitude X added to the set, the chances of us guessing which blinded coin belonged to you (and thus your input) decreases rapidly ( 1 / N ) where N is the number of currently active blinded coins of said magnitude X.

Though perhaps we need to further redefine what unlinkability means. If we speak of something being unlinked as there being a statistical improbability of A (provably) being related to B, then of course it would seem highly unlikely that an on-chain input that has been reused a large number of times (but has not been unlinked in the literal sense of the word) for example: (A -> B -> C -> D -> E -> F), would necessarily trace back to you.

For example: Imagine input A with 50 BTC. It becomes aggregated input B with 100 BTC, and so on. Input C with 40 BTC. Input D with 200 BTC. Input E with 100 BTC. Now you withdraw 20 BTC, call it F. As long as you don't withdraw the exact same amount (or a close division of it), despite a linked chain, it does not at all imply that A is necessarily related to F. Not to an observer, and not to us. thus plausible deniability is achieved, and with that privacy.

blindmixer has been designed in such a way that there should be, relatively speaking, immediate settlement of funds. There might be some conditions under which these constraints break.

If you have requested a lightning payment or an immediate / custom hookout which has been acknowledged by the custodian, but not deployed and/ or settled, contact the related operator.

This is possible. It could be that the custodian neglected to either credit or send out your transaction. blindmixer has been designed in such a way that this should be trivial to prove.

If you are convinced that the custodian purposefully did not credit your hookin, you can prove it by posting the claimant (public key) belonging to your address. Using the public key, It can be tweaked by the fundingKey of the custodian and subsequently publicly verified that the address belongs to the custodian.

Given the parameters of your hookin, anyone will be able to query to see whether the custodian accredited your deposit. Once proof is provided of the address belonging to the custodian in question, it can be reasoned that the burden of proof from that point forward falls on the custodian: they should and could publish the hash of the claimable.
However, delayed accredition of deposits is usually not a sign of cheating!

If the custodian does not send out your hookout, it is trivial to share this and subsequently make it obvious they are cheating you. However, please note that delayed hookouts are usually not signs of cheating attempts!

It becomes a bit more complicated with regard to the lightning network; but there are various methods in which cheating can be proven.

In regard to lightning payments: If a custodian does not publish the preimage of the invoice within a reasonable amount of time, while offering no explanation for not doing so (a rebate!), a dialogue can and should be opened. If the custodian publishes a preimage that does not correlate with the payment hash, cheating can easily be established.

In regard to lightning invoices: This becomes a bit more tricky. A custodian could generate your invoice, relay it you and you subsequently to the payee, whom then subsequently pays the invoice. The custodian could never relay the payment status to you, the client, and instead keep the funds for himself. To prove this, you will need help from the payee of the invoice. He will need to supply you with the preimage that matches the payment hash of the generated invoice to prove the invoice was in fact paid.

More sophisticated and traditional methods of cheating include: marking your coins as spent, marking your coins as invalid.

If your custodian marks one or more of your coins as spent without providing an accompanying signature that matches the coin's spending parameters (a hash of variables such as the amount, address), it is trivial to point out that they're cheating you. The only person that can create a valid signature is the owner of the coin(s), as no one else would have access to the private key(s) belonging to the coin(s).

If the custodian provides you with your own authorization signature, but incorrect spending parameters, the signature should not verify, and cheating would be trivial to prove. If a custodian does not accept a valid receipt (unblinded blind signature), we can simply publish the (receipt) signature along with the coin's pubkey and the pubkey corresponding to the blinded magnitude for anyone to verify.

Note! Because of the fact that blindmixer is still in beta, there might be extreme edge-cases where custodians could cheat the client whereby it is impossible for the client to prove he was cheated upon. Reporting these edge-cases is genuinely appreciated and depending on the severity will most likely result in monetary compensation!

In short: Yes. Most custodians will do this. Please read more about the business model of custodians here!

Not anymore! Since Jan 1st 2022 we have a new business model which you can read more about here

Unfortunately, yes. Various aspects come into play: While the wallet software is open-source, there might be unspotted bugs that can lead to a loss of funds. There is no guarantee in regards to the stability of any of our software. Please read our TOS before using our services.

The design of the communication between the wallet client and the custodian is supposed to be 100% provably fair, but this A. does not mean that this is guaranteed: there might be certain exploits which allow for unprovable communications. And B: communications cannot be enforced, merely proven. Custodians can run off with your funds at any given time. Custodians who claim otherwise should provide mathematical proof of their inability to do so.

Consequently: Please do not use or store more funds in custodians than you're willing to lose.

Do not use the blindmixer wallet as your primary or long storage wallet, but instead, recognize it as a wallet that can be used for day-to-day operations and/ or similar.

A custodian that has gone offline is not instantaneously reason for concern, as there can be various causes ranging from DDOS-attacks to maintenance.

Regarding data-loss and/ or other time sensitive issues, there will always be a signature required for actions that involve coins. custodians cannot, without it being unprovable that is, go offline and take your money or anything of that nature.

Please note however that it might be possible for a custodian to go down, broadcast your requested transaction, and not post an acknowledgement back. Be wary of accidently double-spending this way.

It is impossible to get your money back without communications from the custodian.

Custodians can potentially create extremely accurate profiles of their clients, and might do so when and where required. It is therefore extremely important that you are aware of what can be logged. This includes but is not limited to: IP addresses, User agents and or metadata ( + anything you might send to the custodian). Note: We only take into consideration what can be logged in an unnoticeable manner.

There are certain ways custodians could, up to an acceptable level of certainty, link your inputs and outputs together. This would for example be possible when you immediately after hooking in sweep your blinded coins out again.

Another huge vector you should keep in mind is resyncing and or restoring your wallet. Depending on the size of the custodian, and certain mitigations you may or may not take, it can be trivial for a custodian to fully deanonymize you.

Let's make up a small scenario: We are recovering a wallet: Imagine you've hooked in Z satoshi's between n hookins (a hookin is nothing more than a regular bitcoin deposit!). First, you (the client) will scan his addresses until he has found any transactions, or the gap limit.. (up until we have n hookins) Then, given that a transaction has been found, the client constructs a hookin and asks the custodian to add it. The custodian now learns someone is asking for these hookins. It'll respond with an acknowledgement of the hookin, or the just the queried hookin itself if it has seen the transaction before.

Now, the wallet does not know whether he has already claimed these coins, so he will query for this (statuses of the hookin) as well. the client now learns whether or not he already received coins (in the case of a recovery), and will otherwise try to claim the hookin, (given that the hookin was accepted). From this action, the custodian learns very little new information; He can only reinforce which claimables might belong to you, as you are requesting the statuses from the same set of claimables that have just been requested before.

However, now that you've relearned or claimed your n set of (unnested) coins, you will need to check which ones have already been used and or spent with. The most efficient way to learn this as the client is to simply query all of your unblinded coins to the custodian (one by one) and see what the custodian returns. This however almost completely deanonymizes you depending on how much traffic the custodian is receiving. Why you ask? The custodian has previously learned your claimables, and it's accompanying blinded coins. Through simple heuristics, the custodian can approximate the coins belonging to the previously synced claimables, especially if they approximate to around the same magnitude.

The consequences of this are enormous, as a malicious custodian could sell and or blackmail you with this data. It's highly likely that with this data in the majority of cases a blockchain analysis company such as chainanalysis[1] could track where exactly the bitcoins were coming from and where you sent them in a matter of seconds.

blindmixer has recognized this issue, and we've implemented some slight improvements to combat this issue. In settings, you'll need to enable Add a random delay when synchronizing, Add ghost coins when synchronizing. The idea of these measures is to somewhat thwart the custodian. Depending on the size of the custodian, it becomes increasingly hard to correctly group inputs and outputs when multiple people are syncing, or when the magnitudes of the unblinded coins do not add up to the magnitudes of the blinded coins.

However, if you're extremely privacy-oriented, these mitigations probably won't be sufficient.

Additional steps you can take: Use a new seed for every N set of transactions, (for example by self-transferring all of your coins), so that when you need to resync, only a small portion of claimables is potentially affected.

Additional note: the above scenario assumes you're using a (rotating) TOR IP address. If you are using a residential IP or uncommon proxy, the custodian can use this to link your inputs, outputs or both of them together, the same applies to browser metadata, (uncommon headers and so forth).

Yes. blindmixer has an electron implementation of the web wallet. In short: we load the webpack script (wallet) into electron which offers additional privacy and security in comparison to using the wallet in a browser. you can read more here.

Luckily for you, we've kept this in mind. Head over to our wallet, right click, and save the HTML page. From now on, you can load the HTML file instead of https://mixer.blindmixer.com.
Using F12, you can see that the local HTML file loads a (the!) webpack script, as long as the checksum matches. If the checksum does not match (a malicious actor has changed the contents of the webpack file!), the wallet will not load.

Note: You will still need to manually update!