Pages:
Author

Topic: MultiBit - page 45. (Read 336316 times)

legendary
Activity: 1708
Merit: 1066
November 10, 2012, 03:48:50 PM
That is a pity.
Yes - send me the logs and I will have another look.
legendary
Activity: 1176
Merit: 1011
November 10, 2012, 03:46:32 PM
Jim, thanks a lot for building the test version! Unfortunately, the problem still occurs. Again I tried with no firewalling going on whatsoever, but alas, to no avail. It keeps saying 'connecting...' in red, and it remains at 0 connections. I will PM you the new debug logs.
legendary
Activity: 1708
Merit: 1066
November 10, 2012, 02:58:20 PM
Whilst sat in Debenhams cafe today, I wrote up the changes required for the next chunk of user interface work - currency conversions.

I have written the changes up as a google doc. If you are interested, please have a read and add comments:

https://docs.google.com/document/d/1mAfK1dqvQ1-3fCaE-BzcC_nb_eBxNe_NgZVo0KYt7Js/edit

The doc will not win any awards for art work but most of the changes should be pretty self evident.
I will probably start work on these changes next week (whilst waiting for the encrypted wallet changes to get reviewed by the bitcoinj mailing list).
legendary
Activity: 1708
Merit: 1066
November 09, 2012, 04:24:16 PM
With it being Bitcoin Friday I got to idly wondering what bitcoin I had in which wallets.
There is a very handy smart folder option in Mac OSX where you can set up a search and all the results end up in a folder.

Anyhow, the total number of wallet files I have on my machine since I started work on MultiBit.

637

Bloody Hell. They've bred like rabbits.


My favourite wallet names out of the lot:

처음 지갑.wallet (trying out Korean)

Névtelen.wallet (not sure what I was doing there)

multibit-20120624113805-20120624125502-20120624125935-20120624131155.wallet (must have been checking the wallet backup naming algorithm)


Ok, having more than one wallet is useful but I would try and keep it to fewer than I have managed. :-)
legendary
Activity: 1708
Merit: 1066
November 09, 2012, 12:16:03 PM
@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.
legendary
Activity: 1176
Merit: 1011
November 09, 2012, 06:23:32 AM
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!
legendary
Activity: 1708
Merit: 1066
November 09, 2012, 06:18:37 AM
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.(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.(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.
legendary
Activity: 1526
Merit: 1134
November 09, 2012, 05:36:22 AM
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.
legendary
Activity: 1176
Merit: 1011
November 09, 2012, 04:32:21 AM
@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.
legendary
Activity: 1708
Merit: 1066
November 08, 2012, 01:44:44 PM
@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.
legendary
Activity: 1176
Merit: 1011
November 08, 2012, 11:06:09 AM
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!
legendary
Activity: 1708
Merit: 1066
November 08, 2012, 07:23:10 AM
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.
legendary
Activity: 1708
Merit: 1066
November 08, 2012, 07:10:29 AM
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.
legendary
Activity: 1176
Merit: 1011
November 08, 2012, 06:17:49 AM
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 Smiley

Any suggestions? Would it help if I PM you my debug logs?
legendary
Activity: 1526
Merit: 1134
November 08, 2012, 06:09:09 AM
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.
legendary
Activity: 1708
Merit: 1066
November 08, 2012, 05:27:29 AM
@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.
legendary
Activity: 1708
Merit: 1066
November 08, 2012, 05:11:54 AM
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.
legendary
Activity: 1526
Merit: 1134
November 08, 2012, 05:00:25 AM
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.
legendary
Activity: 1176
Merit: 1011
November 08, 2012, 04:51:49 AM
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 Smiley
legendary
Activity: 1708
Merit: 1066
November 06, 2012, 12:18:50 PM
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.
Pages:
Jump to: