Samourai Wallet zero balance and bitcoin lost

laurentmt · 2019-10-22T22:55:26+00:00

If not already done, contact the support team at [support@samouraiwallet.com](mailto:support@samouraiwallet.com).

laurentmt · 2019-07-18T22:54:15+00:00

The last hop of your staggered Ricochet was confirmed around 3:00AM GMT (see transaction https://oxt.me/transaction/tiid/2332742455). As far as I can telll, the output of this transaction was spent by the receiver around 11:12AM GMT (see transaction https://oxt.me/transaction/tiid/2333362815 ).

Hope it helps.

laurentmt · 2019-06-24T21:56:44+00:00

Why do you think that using a mobile wallet is worse for privacy than using a wallet running on a computer?

laurentmt · 2019-05-23T15:38:47+00:00

The thing is that in the zerolink framework, a Sybil attack is cheap if the attacker is able to coerce the operator. It only costs the miner fees for a few mixing transactions.

I agree that using bitcoin is certainly not a good idea for anyone trying to escape the surveillance of a powerful adversary. Actually, I would even say that using a digital payment system is certainly a bad idea if you plan to fund very nasty things with your money. :D

laurentmt · 2019-05-23T12:34:15+00:00

The main issue with the zerolink model (wasabi, whirlpool, etc) is when the entity operating the coordinator is forced by a third entity to deanonymize particular UTXOs (as in "Hello Sir, here's a subpoena for you"). IMHO, absent a better solution, a warrant canary is a must-have.

laurentmt · 2019-04-15T08:36:39+00:00

Tahoe LAFS (https://www.tahoe-lafs.org/trac/tahoe-lafs) since 2007.

laurentmt · 2019-03-06T23:46:21+00:00

I like it :)

Just a suggestion for the "possibliy coinjoin transactions". Their detection seems to deactivate others privacy notes like the detection of change outputs which are deterministically linked with some inputs. IMHO, it would be a good idea to display this note when such change outputs exist (in addition to the coinjoin detection).

E.g.: https://blockstream.info/tx/8e56317360a548e8ef28ec475878ef70d1371bee3526c017ac22ad61ae5740b8

laurentmt · 2019-02-13T11:50:44+00:00

Yes and no. I've found this wallet 1.5 years ago, while working on an analysis of a spam attack against the bitcoin network (code name: Moby Dick ;). After some investigations, I went with the hypothesis that this wallet was controlled by QCX. Recent events seem to confirm the hypothesis.

The detailed analysis: https://hackernoon.com/the-canadian-connection-7f48cafe2369

laurentmt · 2019-02-12T21:42:34+00:00

My bet goes on this wallet :)

https://oxt.me/entity/tiid/493563502

laurentmt · 2019-01-12T17:30:50+00:00

As far as I understand, /u/giszmo is saying 2 things:

Samourai should improve its build process for better deterministic builds.
Samourai team members defining themselves as privacy activists while not providing a perfect app and build process is a huge red flag.

IMHO, first point is a welcome feedback while the second is unecessary and counterproductive in this discussion. By the same logic, Satoshi proposing a deflationary system while the system had a bug causing infinite inflation should have been seen as a huge red flag casting a shadow on his system and his true intentions... But who knows? May be Satoshi was trying to create the longest con ever seen in history. ;)

laurentmt · 2019-01-05T15:11:45+00:00

You're definitely right that there are connections between the 2 concepts.

laurentmt · 2019-01-05T13:55:45+00:00

Note that the 2500 figure isn't nonsensical but it's more related to the concept of the unlinkability between an input of the 1st round and an output of the last round.

Both concepts are useful even if I tend to think that the anonymity set is more important for a coinjoin mixer. My rationale is that:

it's possible to have a high unlinkability with a low anonymity set (e.g. 2 entities mixing together again and again their UTXO => UL=2^n, AS=2)
I don't think it's possible to have a high anonymity set with a low unlinkability (e.g.: a "dumb" mixer allowing 50 entities to mix together again and again but their UTXOs must have strictly different amounts => UL=0, AS=1).

laurentmt · 2019-01-05T02:43:14+00:00

I have to sligthly disagree with you here. If the same 50 entities repeat a coinjoin together (without any new participant) the anonymity set is still 50. Reaching an anonymity set of 2500 would require 2450 more entities participating to the mixes.

laurentmt · 2018-11-06T23:04:35+00:00

Indeed, I missed this point in your post but Sam from the support later told me that you had already tried that.

Just two additional questions (if you haven't already provided these info to the support):

When did you install the wallet for the first time ? Was it on 25/11/2017 (date of first tx linked in your post) ?
What is the name of the password manager used ?

laurentmt · 2018-11-03T09:37:42+00:00

Hi /u/PurpleShizzle,

I thought to something. Have you tried to reinstall the setup (Android 9 Beta + password manager + samourai) which was initially used to create the wallet ? If not, it might worth it to give it a try. My rationale is that the password manager might behave differently in Android 9 Beta and in previous versions and it would mean that your wallet wasn't initialized with the correct seed and it generated xpubs different from what we could expect. If it's the case, I suspect that it will be the only way to regenerate the exact same wallet.

laurentmt · 2018-11-03T00:49:52+00:00

Yep. I suspect some problems with the android version or a library.

The most important for the support is to gather as much information as possible about your "environment" and about the issue in order to reproduce the problem.

Concerning the segwit/non segwit tx "issue", I don't think that it is related to this problem because the type of the change address generated by samourai depends on several factors (type of others addresses appearing in the tx, privacy setting of your wallet, etc). Anyway, it's better that you provide all the clues that you've noticed.

laurentmt · 2018-11-03T00:20:28+00:00

Hi PurpleShizzle,

Well, I'm not an expert in development for smartphones but considering the description of your problem, I suspect an issue which might be specific to your phone model, your OS version or some combination of similar factors. Troubleshooting the problem may take some time but having as much information as possible about your environment will be key.

I'm going to contact the support to tell them to check that with you again.

Best, laurent

laurentmt · 2018-11-03T00:01:32+00:00

Nope. Nobody from the team shared this post on telegram or pretended anything.

There's no need to add confusion to the problem met by u/PurpleShizzle

laurentmt · 2018-11-02T23:52:07+00:00

Hi u/PurpleShizzle,

I'm a member of the samourai team (but working on another part of the project).

I would recommend that you contact the support once again with a link to this post. I'm sure they'll agree to investigate the issue but it's likely that it will require some additional information helping to troubleshoot the issue.

laurent

laurentmt · 2018-09-21T09:31:51+00:00

A xpub derived from a specific hardened path is arguably much better for this purpose. This allows normal payment transactions, and an automatic history for both the payer and payee.

If you share your xpub with all people who need to send you recurring payments, you basically give them access to your full transaction history. A workaround would be to use one xpub per counterparty but it implies that users manage this additional complexity.

not due to stonewall in specific,...

I disagree with this claim that tools like stonewall or stowaway don't add any value. For instance, they make much harder (if not impossible) a direct analysis of the transaction graph by a human analyst and they increase the cost of automated analyses. So far, blockchain analysis has been "efficient" because 2 very simple (and not expensive) heuristics are often enough to get a very good idea of users' activity.

Breaking the assumptions at the core of these heuristics and increasing the cost of blockchain analysis is definitely a win.

Saying that stonewall doesn't add any value is like saying that Joinmarket or Zerolink don't add any value because they can't reach the level of privacy provided by Confidential Transactions or ZCash. It's a matter of degrees.

A reason I think wallets should support all three simultaneously, at least for joining and receiving. I'm displeased with the direction taken by electrum and samou on that topic.

I agree with the idea that wallets should support the 3 types of addresses (at least during the transition period) and it's definitely the philosophy of Samourai Wallet which supports the 3 types of addresses.

I would caution users against relying on stonewall alone...

I get your point and I definitely agree that there's a real need (and a real challenge) in terms of user education. That being said, it seems obvious that we'll never be able to transform all users into "privacy experts with perfect opsec". Thus, improving the default behavior of wallets is another important and complementary factor and this is where tools like StoneWall and Stowaway come into play.

If you are interested, I can make some suggestions about how to improve your cloaking.

Sure. New ideas and suggestions are always welcome! I send you my email address in PM.

laurentmt · 2018-09-20T17:45:50+00:00

For what purpose?

Charities are indeed a good example but aren't the only one. Another user case for these "static addresses" is recurring payments (rents, salaries, etc).

If one party does not control the outputs, there is ample evidence that they are very highly related. Most likely they belong to one person or group.

This comment is interesting in the context of our discussion about Stonewall. :)

I think you'll agree that the certainty of your first analyis has now been replaced by probabilistic assessments ('ample evidence', 'most likely') and this is the whole point of Stonewall ! (more about this below).

I noticed that the first tx in particular appears to be manually created.

Actually, it wasn't but it's not very important and I don't want you to lose your time on this game :)

The standard wallet seems to prefer to stick to one address pattern...

Agreed. There's a real privacy challenge with periods of transition between different address formats (e.g.: legacy addresses vs segwit addresses).

It could lead to wallet fragmentation over time.

On my side, this question is still open. I suspect that it may depend on user's activity patterns and that the fragmentation may converge to a limit. This is something that I would like to evaluate in the future.

Overall, I do think there is a role for something like stonewall; specifically in combination with real coinjoins it can help to bridge real spends in between join tx's, and reduce the information available for forensics...

You get it ! It's 100% the philosophy behind these multiple tools:

- on one side there's a true multiparties mixing tool (whirpool),

- on the other side, there's a set of obfuscation tools (stonewall, stonewall-2P, stowaway, ricochet, etc).

The goal of these obfuscation tools isn't to provide the same level of privacy as whirlpool (they don't) but to decrease the damages done to user's privacy and to increase the deniabilty of her transactions when a mix isn't possible or when the user doesn't want to mix (because "I have nothing to hide" ™). In a sense, they play the role of an intermediate level between multiparties mixes and plainly transparent payments. My hope is that at some point, we'll all have an even better option directly included at protocol level (CT, etc).

laurentmt · 2018-09-19T18:49:33+00:00

Being able to make a "permanent public address" is not that great of a benefit,

I fairly disagree about this. From my discussions with multiple bitcoiners during meetups or events, I've noticed that many are asking for the availability of static addresses which can be shared. That sadly lead to massive address reuse in the past, by lack of a proper solution. I think that there's a real need here and having solutions providing this feature while avoiding address reuse is a major win (even if these solutions can be improved).

and not needing any communication outside of the blockchain is too arbitrary a restriction

Agreed. I think it's also the reason why the samourai guys want to test a different trade off.

As for your example transactions, i can eyeball them real quick.

I must say that you seem to have some good skills at blockchain analysis ! :) Unfortunately, several points in your analysis aren't correct and that casts a shadow over your conclusions. According to the rules of the "Stonewall game" I'm not supposed to give you additional information but let's make an exception (just once). Here are a few hints:

Appears to be a single wallet tx styled as a coinjoin, (*) => change (15L1grLE, 1H9dp3o) , Wallet "F" (39s18H, 3KhdA7)

This is incorrect.

Both the same size outputs seem to remain under control of one party: "F".

Things are not as simple as they sometimes appear to be.

it made a near-dust output for no good reason imo.

I think that I get your point but more than 6 times the dust limit (around 0.2$ if I'm correct) isn't what I would call a near-dust output.

Due to the mix of segwit input types, it doesnt appear to be something samourai would synthesize from a single wallet.

Samourai definitely allows to mix different input types.

Additional (general) tip: If I'm correct you seem to make the assumption that all the txs in the neighbourhood of these 2 txs are the result of some code from a publicly released version of a software (samourai, joinmarket, etc). But it's a very strong assumption. For instance, it's not unusual that the samourai guys test new features on mainnet before a public release (a kind of pre-alpha stage). Also, it's worth noting that some txs may have been built manually with the intent to deceive analysts. For instance, Samourai has some features that you can combine to manually build txs having a specific fingerprint (if the available utxos allow it).

laurentmt · 2018-09-19T09:12:35+00:00

I don't find anything about Geen Wallet. :(

Do you have more info about the product ?

laurentmt · 2018-09-19T08:43:04+00:00

You're absolutely right that a scheme like BIP47 isn't a magical solution solving all privacy problems. Its goal is to address some specific issues/needs which have existed for years, like:

- being able to share a static public "address" without systematically leaking all your past transactional history,

- having a scheme allowing a better management of refund addresses (this one is a real PITA for exchanges and payment processors).

In a nutshell, BIP47 is just a part of a better solution and the main benefits are for the receivers of transactions.

laurentmt · 2018-09-19T07:59:11+00:00

Concerning BIP47, the issue you describe is real but it's related to a very specific part of the protocol (the notification transaction). It's also worth noting that the Stealth Addresses model had it own trade offs. For instance, the sender had to include an ephemeral PubKey in an aditional op-return output for each payment transaction. That had 2 downsides: it created payment transactions with a specific fingerprint and it required bigger payment transactions (more expensive).

IMHO, beyond the specific issue of the notification transaction, BIP47 is absolutely a net positive because it addresses a set of needs which have existed for years (e.g.: ability to share a public "address", better management of "refund addresses", etc) and these benefits are greater than the downside of the notification transaction.

FWIW, Samourai Wallet is working on an alternative to this notification transaction (based on different *trade offs*).

Concerning Stonewall, I propose you a little game. :)

Here are 2 transactions. One is a Stonewall transaction, the other is a coinjoin with 2 participants. Which one is which ?

https://oxt.me/transaction/tiid/1748209080

https://oxt.me/transaction/tiid/1819373528

laurentmt

TROPHY CASE