MultiBit

[jim618]

Hi Kazimir,

The big risk with Java is that you can in theory download and execute code. In practice nobody likes to do this any more as it is too tempting a vector for malware.

All the UI code and all the network code (bitcoinj) is Java code so it would not be practical to rework it. It would be a complete rewrite.

In MultiBit (and I am pretty sure it is the same with bitcoinj) there is no ad hoc code downloading of code or patches or anything. Only the code in the installed jar is used. In the future I will harden this so that it is both digitally signed by a key just owned by me and also sealed, which means it will not load other code from outside the jar.

Also, there is no auto update (and almost certainly never will be) as that is another vector for malware to get onto your machine.

Regards,

Jim

[1713873482]

1713873482

[1713873482]

1713873482

[Kazimir]

Thanks Jim, that gives me some peace of mind.

[PTseller]

Hi Jim618


I have install new version of multibit and i open my wallet from hard disk from which i have generated new BTC address but nothing happen also done reset blockchain and transaction i am not getting my BTC back

please help me out

[jim618]

Hi Jim618


I have install new version of multibit and i open my wallet from hard disk from which i have generated new BTC address but nothing happen also done reset blockchain and transaction i am not getting my BTC back

please help me out

Hi PTSeller,

1) Does the wallet have the address that you (or anyone else) has sent BTC to ?
If not, then you need to find the wallet that has the address (and hence the private key) in. You need this before you can recover your bitcoin. You have multiple backups (from your previous post) so it should just be a matter of finding the right one.

The most important thing is to find your private keys (for the addresses that have bitcoin on). If you can find these then there are a couple of ways to get your bitcoin back. Without them you cannot.

2) Once you have found the wallet that contains the address/ private key then you can get the bitcoin transactions to appear in that wallet. This is what the 'reset blockchain and transactions' does. Work out the date of the first transaction that sent you bitcoin and then use the day before that date in the 'Reset blockchain and transactions' to replay the blocks. The MultiBit help gives a screenshot of the 'reset blockchain and transactions' so that might be useful if it is not clear how to pick a date.

3)  You should be able to use the 'reset blockchain and transactions' to get your bitcoin back. However if you want another way to get your bitcoin back then export your private keys using the 'Tools | Export Private Keys' and import them into a blockchain.info wallet. You need to export the keys UNENCRYPTED and paste them into the Import Keys screen in blockchain.info so that blockchain.info can understand them.

Regards,

Jim

[jim618]

I am working on a pull request to get the MultiBit encrypted wallet work into bitcoinj. It is penciled in for the next version (bitcoinj v0.7) as long as it passes all the code review and QA.

If/once it gets into bitcoinj I will produce a release candidate MultiBit using bitcoinj-0.7 with encrypted wallets for testing. Then if people are happy with it, it will go on the website. Back to one version of MultiBit to look after !


Also, I have added that when you do a private key import it now immediately exports an encrypted copy of the new private keys into the same directory as your wallet with a timestamp. Screenshot from "Tools | Import Private Keys":



It only applies to encrypted wallets (as you need a password to encrypt the key export file).

This means that when you perform any "key sensitive" operation with an encrypted wallet it creates a timestamped, encrypted private key backup file. This is all of:
+ Add password
+ Change password
+ Create new receiving addresses (ie new private keys)
+ Import private keys.

These timestamped files are never deleted by MultiBit.

[Kazimir]

By the way Jim, there is still one more issue with using Java that I'd like to address. I'm rather paranoid about random software making outgoing connections (especially on a system where I store bitcoins). So I have a firewall installed, which blocks outgoing traffic, except for certain selected programs (and in some cases only to selected servers and/or ports).

Now the problem with Java is: you cannot allow some Java programs to connect, while blocking others. It's always JavaW.exe that connects. I want to allow MultiBit to make outgoing connections, but I want to block most other Java software (including Java itself, I don't need it to send random statistics to Oracle or whatever).

With privacy and online security becoming more and more of an issue lately, I think this is an important point to consider.

Anyway, I understand you cannot make the switch at this stage and replace Java with some alternative, without essentially rewriting the entire software. Just wanted to point this out, in case you ever decide to build a new client or something

[Mike Hearn]

I must disagree about auto update.

Yes, it has risks. But not having it also has risks - if there is a vulnerability, old versions will persist for a long time and users will get exploited. And if there are important features or bugfixes that could cause wallet problems, same thing. And if there are new features that could tip the scale for some users from "neat but useless" to "I need this in my life", they may never find out about them.

Having some kind of notification and a one click "update now" button in the UI is good as long as the updates are semi-rare and the notifications are well written. We know from practical experience with browsers that many users habitually ignore update notifications, even when they're really important, because you only see them when you're in the middle of something else. Downloading and verifying an update in the background then saying "Click to restart, it'll take 5 seconds" can help.

Users will continue to report problems long since fixed until an easy auto update is implemented. It doesn't need to wait for some pure p2p update mechanism. Just polling a website or Twitter is enough. There are probably frameworks that can be easily adapted for it already.

Re: Java. Jim is right that there's no risk with Java given the way it's currently used in MultiBit. However, perceptions matter and unfortunately Java is firmly linked in peoples minds with insecurity (ironic given its original design goals). Using a product like Excelsior Jet to compile it down to a native app may be a good idea and simplify deployment in some cases.

[jim618]

Hi Kazimir,

I totally appreciate that you want to control your connections. These days it is essential.
Mainly to support Tor I plan to put in SOCKS5 proxy support into MultiBit which might help.

That would enable you to set MultiBit to use your localhost proxy and only allow connections via your proxy. It would still be a javaw process though but other Java programs would not be set up to use the proxy.

I had a look previously but it is not easy to change the Java process name.

Other connections out from MultiBit are:
1) the Bitcoin connections to Satoshi nodes. These would go through the proxy
2) if you use 'regular' node discovery that uses DNS. Not sure if they would go through a SOCKS5 proxy - needs testing. You can hardwire a single node to connect to to avoid the lookup.
3) the MultiBit help is on the multibit.org website and accessed via HTTP. I will move this into the install as it will be quicker and less network calls.

[jim618]

@Mike,
Re: auto-update.

Yes I agree it is a tricky balance. You definitely want notifications of updates but I think you want the users to be in control of updating their software. But again you are right people do not update.

The reason I don't like auto update for Bitcoin software is that it is a great attack vector. If you can update a lot of code within, say, 48 hours and you can get a Trojan released you can skim quite a lot of cash in a weekend. If, as I estimate, people update once a month or so you are not going to get much cash before the news of the Trojan is on Reddit/ bitcointalk/ Twitter etc.
.
The reproduction rate of the Trojan has to be less than the reproduction rate of the news of the Trojan !


Encrypted wallets will help as a Trojan cannot get the cash out of them until the user types their password.

I think I will put in notifications first as that at least keeps users informed.

[Mike Hearn]

Absolutely agree. I think any auto update service would need to use threshold signatures. BlueMatts gitian-updater work did that. It means finding several people you trust to help sign off on releases. Even without auto update it's a good idea, but I doubt many people manually check signatures.

[Kazimir]

Thanks again for the comprehensive reply Jim.

And sorry to bother you yet again, but yesterday I updated to 0.4.14 and it seems I can't connect anymore. It says "connecting..." in the bottom, when I hover my mouse there it says 0 connections. I've tried restarting MultiBit several times and let it wait for over an hour, but nothing seems to happen. In retrospect to my previous post: I did configure my firewall to allow any connection for Java

Any suggestions? Would it help if I PM you my debug logs?

[jim618]

Hi Kazimir,

One thing you could check is whether you have the inbound port 8333 traffic going anywhere. If you have set up a rule up in your firewall for this port (say to go to a bitcoind instance) multibit never connects as it never gets any traffic back from the bitcoinds it is trying to connect to. Of course it will need port 8333 outgoing as well.

Temporarily turning off your firewall to see if it connects would be a good test to see if it is something to do with your firewall or not.

If you don't allow DNS requests out it could be that too. If you have a look in the log files there will most likely be an error (or 0 peers found) to do with the MultiBitDNSDiscovery.

Failing that, then yes send me the two logs (multibit_debug.log and multibit_console.log) and I will take a look.

If it is something to do with your firewall post what you find as it will be useful for other people in the future.

[jim618]

Absolutely agree. I think any auto update service would need to use threshold signatures. BlueMatts gitian-updater work did that. It means finding several people you trust to help sign off on releases. Even without auto update it's a good idea, but I doubt many people manually check signatures.

Good idea. Maybe I should move to a "stable" and "working" release with the stable on the website and have that signed off by others and have a working release where it is just on github and only signed by me (=appears more frequently / latest features/ but more bugs).

The stable release could then be the one the user is recommended to update to using your suggestions. That would cover most eventualities except for urgent, critical bugfixes which hopefully will be rare.

[Kazimir]

Failing that, then yes send me the two logs (multibit_debug.log and multibit_console.log) and I will take a look.

I tried without any firewalling whatsoever, unfortunately still the same problem. I've sent the log files, please see PM.

Thanks a lot for your help man!

[jim618]

@Kazimir

It looks like it might be this issue:
http://www.java.net/node/703177

This looks like it could be an IPv6 v IPv4 issue when using a VPN or similar.
It looks like it is a bug just on Java 7 and not Java 6.

The solution on that page is to use:
-Djava.net.preferIPv4Stack=true

as a command line option when starting MultiBit.
Unfortunately on Windows MultiBit is wrapped up into an exe file and you cannot specify command line options with it so you cannot set this option yourself.

(With the Mac and Linux the installer installs a file called multibit-exe.jar. You can run this from the command line and pass parameters.)

When I wrap the jar to an exe I can set these parameters so I think you will have to wait until I make the change and build it.
Can you confirm you are on a Windows machine ? If you are then I will build you an exe with the parameter in and get you to try it out.

[Kazimir]

@Jim,

Awesome! Yes, I'm on a Windows 7 machine. I dunno if more people experience this problem, perhaps you may want to include this feature in MultiBit's preferences. E.g. a checkbox "Force Java to use IPv4 (if you have connection problems, enable this and restart MultiBit)" or something.

Thx in advance.

[Mike Hearn]

If the issue is actually some kind of broken IPv6 configuration that only impacts JDK7/Windows7 and results in a unique exception, we can put a workaround into bitcoinj itself. If we see a permission denied error on connect, the code can set that property and then try again. As long as the property value isn't being cached anywhere that should work.

[jim618]

The stacktrace look pretty specific:

Code:

16:52:00.157 [Peer group thread] WARN  com.google.bitcoin.core.Peer - com.google.bitcoin.core.Peer$PeerHandler@1cfceb7 -  org.jboss.netty.channel.ChannelException: Failed to create a selector.
	at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.register(NioClientSocketPipelineSink.java:198) ~[temp80.jar:na]
	at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.connect(NioClientSocketPipelineSink.java:155) ~[temp80.jar:na]
	at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:105) ~[temp80.jar:na]
	at com.google.bitcoin.core.TCPNetworkConnection$NetworkHandler.handleDownstream(TCPNetworkConnection.java:227) ~[temp80.jar:na]
	at com.google.bitcoin.core.Peer$PeerHandler.connectRequested(Peer.java:169) ~[temp80.jar:na]
	at org.jboss.netty.channel.Channels.connect(Channels.java:535) [temp80.jar:na]
	at org.jboss.netty.channel.AbstractChannel.connect(AbstractChannel.java:204) [temp80.jar:na]
	at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:230) [temp80.jar:na]
	at org.jboss.netty.bootstrap.ClientBootstrap.connect(ClientBootstrap.java:183) [temp80.jar:na]
	at com.google.bitcoin.core.PeerGroup.connectTo(PeerGroup.java:575) [temp80.jar:na]
	at com.google.bitcoin.core.PeerGroup$PeerGroupThread.tryNextPeer(PeerGroup.java:550) [temp80.jar:na]
	at com.google.bitcoin.core.PeerGroup$PeerGroupThread.run(PeerGroup.java:477) [temp80.jar:na]
Caused by: java.io.IOException: Unable to establish loopback connection
	at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source) ~[na:1.7.0_09]
	at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_09]
	at sun.nio.ch.PipeImpl.<init>(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source) ~[na:1.7.0_09]
	at java.nio.channels.Pipe.open(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.WindowsSelectorImpl.<init>(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.WindowsSelectorProvider.openSelector(Unknown Source) ~[na:1.7.0_09]
	at java.nio.channels.Selector.open(Unknown Source) ~[na:1.7.0_09]
	at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.register(NioClientSocketPipelineSink.java:196) ~[temp80.jar:na]
	... 11 common frames omitted
Caused by: java.net.SocketException: Permission denied: listen
	at sun.nio.ch.Net.listen(Native Method) ~[na:1.7.0_09]
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source) ~[na:1.7.0_09]
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source) ~[na:1.7.0_09]
	... 21 common frames omitted

I will build a version of MultiBit with the parameter set for Kazimir to try out today. If that works I will raise an issue in bitcoinj with the fix mentioned. Bitcoinj is the place for it definitely.

[Kazimir]

If the issue is actually some kind of broken IPv6 configuration that only impacts JDK7/Windows7 and results in a unique exception, we can put a workaround into bitcoinj itself. If we see a permission denied error on connect, the code can set that property and then try again. As long as the property value isn't being cached anywhere that should work.

Oh, right, well if that's possible without restarting MultiBit, that'd be even better as the user wouldn't even notice there was a problem!

[jim618]

@Kazimir,

I have produced a multibit exe file with that property set so that IPv4 addresses are used.
It is here:
https://github.com/jim618/multibit/downloads

The multibit-for-kazimir.exe file

Can you please try it out and let me know if you can connect ?

To use it download it and save it in your MultiBit installation directory. (You can look at the properties of the shortcut that you use to start multibit to find the directory).
Save the download in the same directory and double-click the multibit-for-kazimir.exe file directly.

It is not QAed or anything - I have just built it in the last 15 mins or so.