Multibit turned out to be a scam

[jubalix]

The first thing do when you use any wallet is you export all private keys and store them, before you use the wallet.

Of course there will be bugs. Its new tech. Control your private key and all is well.

[Jay_Pal]

If multibit were to be a scam, the addresses would belong to someone and not show in multibit's user wallet.
It's just pure amateurism as many services surrounding bitcoin - but that doesn't turn the bitcoin itself into a scam.
Some of those who claim bitcoin is a scam or a ponzi are either those who scam, those who run the ponzi schemes or those who don't stop for 1 minute to seriously think about what's being offered by others or to take security measures.
I've been testing multibit for weeks, the addresses in those wallets were used just for receiving but later today, I'll be exporting all my private keys and importing them in bitcoin-qt to prevent any surprise, until all of this bug has been sorted out.
It's only 7 bitcent worth, but it is something.
By the way, I haven't quite understood not even found information about the "change back".
Could anyone be kind enough to explain it to me or at least, point me in the right direction, as I've never experienced it on any transaction I've made on bitcoin-qt?
Thank you!

[zolace]

Dark Wallet is designed to be simpler then Bitcoin wallets  and encourage people who are not tech savvy to store and use the virtual currency.
http://www.dailymail.co.uk/sciencetech/article-2532720/People-probably-use-Bitcoin-buy-drugs-admits-founder-new-app-lets-users-spend-currency-privately.html

[freddyfarnsworth]

Read more the answers are there (mulitbit thread).
And HD wallets are dangerous also, read about it, to much to explain.

The author of Multibit has a old thread on here, that explains why this happens to some and why.

[fryarminer]

So, what's the scam here?

Developing unreliable software, claing to be secure and the fastest wallet, that's being used by millions of people.

Then turns out the wallet actually loses your coins

Thats a scam in itself

And ask urself (especially if ur a delusional bitcoin nutter) is it any different from what mtgox did?

No

WTF are you doing in this forum?

cosmofly is trying to save us from making bad decisions;
Perhaps his name should be "Nanny State." 

Is it just me or has anyone else noticed quite a few trollish accounts and even older accounts morphing into trolls

I've noticed that too. It blows my mind how a "hero member" can be so negative about bitcoin, as I've seen over and over again lately. Why are they still around? That's fine. Everyone who doesn't want to be stolen from should stop using currency. Or let's count the ways that people steal dollars from us.

[fryarminer]

Do anyone know about "Dark Wallet"

I read a bit about it but not enough to understand what it's value is.

[dreamspark]

The loss was not that much

Abit harsh, that could have been all the guys money that he had...

[Mike Hearn]

For what it's worth, I offered to analyze his logs and wallets a couple of days ago, and still didn't hear anything. So this is perhaps not quite as time critical as has been made out to be.

MultiBit has had about 1.5 million downloads and has about quarter of a million seven day actives. Additionally, it's based on bitcoinj, which has another ~half million users via the mobile wallet app (I think, trying to remember the last figures). So there's a fairly large user base.

What wetseals is claiming (that a key was generated with no private part at all?) has, as far as I know, never been reported before. So either:

1) He has encountered a very rare bug, or some combination of hardware failure and bug, which is not previously known.

2) His explanation of what happened is garbled in some way and he encountered some other problem.

3) Unfortunately, given that he appears to be involved with gambling sites, there is a third possibility which is that there is no bug in reality and he is trying to pressure Jim/Gary into "making him whole" or re-earn money he lost via donations.

I hate to suggest the third one because it seems low, but sadly there have been a few support cases in the past that got escalated to me where events were generally very suspicious e.g. users who claimed the wallet ate their money and demanded developers reimburse them, and when they were pressured to send logs and wallets for analysis they mysteriously found the money they claimed had been lost (probably they didn't realise there were logs that might give the game away). It's unfortunately true that developers who care about their reputation might be tempted to try and pay people off to make them go away. In this case wetseals has trashed MultiBit all over reddit but provided no data that could be used to investigate what has happened.

Anyway, HD wallets are much safer in general against all kinds of failures, and they're being worked on now.

[Jay_Pal]

Mike, mine has been working fine, for now. Never the less, I've backed up the private keys. It's always an advisable security measure.
Could you please shed me some light on the "Change Back" question?
Thank you and keep the good work.

[smoothie]

So Bitcoinland is a kind of binary universe where everything is either 100% perfect or 100% scam.

With that logic then everything is a scam because nothing is 100% perfect when it comes to software.

[solex]

So Bitcoinland is a kind of binary universe where everything is either 100% perfect or 100% scam.

With that logic then everything is a scam because nothing is 100% perfect when it comes to software.

That's my point.
The guy who lost money had 550 addresses. Now that is probably not common, and so he encountered a bug in the code. The answer is what the Multibit devs are working on anyway which is HD implementation.

[apsvinet]

So, what's the scam here?

Developing unreliable software, claiming to be secure and the fastest wallet, that's being used by millions of people.

Then turns out the wallet actually loses your coins

Thats a scam in itself

And ask urself (especially if ur a delusional bitcoin nutter) is it any different from what mtgox did?

No

Psch, it's everyone's own responsibility to choose their own wallet and make sure they choose something that fits them and they feel they can rely on. If you trust anyone saying "THIS IS SAFE" you're an idiot, and I can't feel sorry for you losing your money.

[R2D221]

For what it's worth, I haven't lost any money using MultiBit, so I can't support your claims about it being a scam.

[apsvinet]

For what it's worth, I haven't lost any money using MultiBit, so I can't support your claims about it being a scam.

Me neither. It's just the ramblings of some random guy.

[Mike Hearn]

Hey guys,

Just a quick update on my investigation into this.

I asked wetseals to send me his wallet and logs, which eventually he did. This revealed that the bad key/address was actually imported from blockchain.info not generated by MultiBit. This contradicts his original description of what happened. The private key has been corrupted in some way that I didn't figure out yet (all imported keys are prefixed with two bytes 0080) and therefore doesn't match the address. Even removing the initial bytes in various combinations does not fix the key. This is something I have never seen before.

The blockchain.info import code was written by Ben Reeves (creator of blockchain.info) to help people recover their backups if the site goes down. It does not do any kind of consistency checking on imported keys to verify the private part matches the public part, unfortunately. Doubly unfortunate, wetseals says he deleted/lost his JSON backup files from blockchain.info and he has also stopped replying to my questions, so there's no way to try and figure out where the corruption was introduced.

Over time Jim has been trying to simplify Multibit down to the basic core. Key import lies at the root of most wallet failures and thefts I have investigated. As a result Jim plans to simply delete this code and remove the blockchain.info import function entirely.

[solex]

Thanks for clarifying. Good to know this detail.

[freddyfarnsworth]

From what little I have seen/read about, blockchain.info is both unreliable, and buggy.
Shows alot of activity that never occured, (block thru different pools) ect.

Be about the last place I would be trusting to repair anything.
They are also unresponsive to leaders in bitcoin questions/advice.

Mbit works just fine for me so far

[apsvinet]

Alright, good to know there's nothing wrong with the Client itself.

[jim618]

A follow up note on Mike's posts above.

For the next release (which should be out early next week) we've removed the ability to import blockchain.info exports.  We've written a blog article to explain why but basically there's little need for it now and it's just another thing to go wrong.

To help the users who have imported private keys from blockchain.info we've written a utility that checks the integrity of the private keys. It recalculates the address from scratch from the private key and cross checks against the address in the receiving addresses.
It will appear in "Tools | Check Private Keys" and will basically be:

+ specify wallet password (for encrypted wallets)
+ click button.

Also going into this release are also the usual bug fixes and a bump to bitcoinj 0.11.2 which was out this week. (This is also mainly bug fixes).

[prof7bit]

To help the users who have imported private keys from blockchain.info we've written a utility that checks the integrity of the private keys. It recalculates the address from scratch from the private key and cross checks against the address in the receiving addresses.
It will appear in "Tools | Check Private Keys" and will basically be:

This will not help all cases because the old import code was outright broken:

snippet from old BCI import code

Code:

    public static ECKey decodeBase58PK(String base58Priv) throws Exception {
        byte[] privBytes = Base58.decode(base58Priv);

        // Prepend a zero byte to make the biginteger unsigned
        byte[] appendZeroByte = concat(new byte[1], privBytes);

        ECKey ecKey = new ECKey(new BigInteger(appendZeroByte));

        return ecKey;
    }

The above only works if the key was meant to produce an uncompressed key. If it was meant to be a compressed key (note that blockchain.info does not use the satoshi dumped wallet key format, they use the naked private key base58 encoded lacking the compressed/uncompressed flag) this will always produce an uncompressed key!

and on top of that it will always produce a valid uncompressed ECKey (always matching private and public because it does not use that other constructor that also sets the public key).

This means the people who have had compressed keys in BCI and imported them now have the correct private keys but the wrong bitcoin addresses.

---

This is how my own import tool currently handles it (it also takes into account the address from the json):

Xtend code:

Code:

    /**
     * Try to produce an ECKey Object from the given arguments.
     * BCI has a very uncommon way of encoding the private key, its not the
     * usual dumped private key format of the Satoshi client, its just base58 of
     * the key bytes. Most importantly it is also lacking the information whether
     * it is meant to produce a compressed or uncompressed public key. For this
     * we try both and compare with the supplied bitcoin address, if none of
     * them match (which should never happen) then this will throw an exception.
     *
     * @param base58Priv String containing the BCI encoded private key
     * @param addr String containing the bitcoin address
     * @return a new ECKey object representing this key
     * @throws Exception if the input can not be interpreted in any meaningful way
     */
    private def ECKey decodeBase58PK(String base58Priv, String addr) throws Exception {
        val privBytes = Base58.decode(base58Priv);
        var ecKey = new ECKey(new BigInteger(1, privBytes), null, false);
        if (ecKey.toAddress(new MainNetParams).toString.equals(addr)){
            log.debug("{} has uncompressed key", addr)
            return ecKey;
        } else {
            ecKey = new ECKey(new BigInteger(1, privBytes), null, true);
            if (ecKey.toAddress(new MainNetParams).toString.equals(addr)){
                log.debug("{} has compressed key", addr)
                return ecKey;
            } else {
                val err = addr + " and private key don't match, neither compressed nor uncompressed"
                log.error(err)
                throw new Exception(err)
            }
        }
    }