MultiBit

[Mushroomized]

While I use this client from time to time, the biggest issue I have with it is that it sometimes doesn't let me send my money, and I have to reset the blockchain and it just dies on me.

[1713274907]

1713274907

[jim618]

Apparently I am just going to become a bother....

So after getting it to it will not connect  I left if for over an hour and a half

log: http://pastie.org/5025538

In your paste I can see that it had a list of 14 peers (i.e. Satoshi clients) that it would subsequently try to connect to. What it should do is try all of these and, if all of them are stale it waits a while and then trys again. This code is relatively new so it could be that it is not recreating a whole new list again. I will have a look into this.

Try just closing down MultiBit and restarting it again and it will reinitialise the list of all the peers etc.

[jim618]

While I use this client from time to time, the biggest issue I have with it is that it sometimes doesn't let me send my money, and I have to reset the blockchain and it just dies on me.

This is all good feedback Mushroomized. Is the 'it sometimes doesn't let me send my money" the thing about unconfirmed change ? If so, then yeah we have a plan for that. If it is something else please give some more detail.

The 'it just dies on me' I would like to know more about. What platform are you running on ? I have seen that very occasionally on the Linux VM I use for testing. It is a difficult one to get to the bottom of so any information you have would be useful.

[jim618]

I have updated the MultiBit layout for when it is displaying right-to-left languages like Arabic, Farsi, Hebrew.
It is not perfect but I think it is now usable.
Screenshot in Farsi:



This will appear in the next live version 0.4.12 which should be this week.

[ErebusBat]

Still not connecting

Here is a complete log of the session: https://dl.dropbox.com/u/86939820/tmp/multibit_debug.log

[jim618]

I notice in that log that the HTTP gets that the currency ticker does are also failing.
This can be if the MtGox server is busy (it just drops requests) but it can obviously also be caused by network problems.

Also in the log the number of peers it finds is always 14. Normally in the two seconds it spends looking up network peers I get 80+ and the number varies.  My network is a laggy 3G connection.

Can you describe what your network setup is please ?

I have recently changed how it looks up the Bitcoin network peers so that it does a DNS lookup of all the seed nodes in parallel (on different threads). I think I will have to adjust the algorithm a bit as I suspect that is what is causing you problems.

If you still have an old copy of multiBit 0.4.10 that would be a good test to see if that connnects ok. I made the peer lookup change in 0.4.11.

Sorry that you are an unvolunteered tester.

[ErebusBat]

I notice in that log that the HTTP gets that the currency ticker does are also failing.
This can be if the MtGox server is busy (it just drops requests) but it can obviously also be caused by network problems.

Also in the log the number of peers it finds is always 14. Normally in the two seconds it spends looking up network peers I get 80+ and the number varies.  My network is a laggy 3G connection.

Can you describe what your network setup is please ?

Fairly standard corporate connection.  Here is a traceroute to google:

Code:

$ traceroute www.google.com                                                                                                          1 ↵
traceroute: Warning: www.google.com has multiple addresses; using 74.125.239.19
traceroute to www.google.com (74.125.239.19), 64 hops max, 52 byte packets
 1  192.168.85.1 (192.168.85.1)  0.571 ms  1.016 ms  0.433 ms
 2  cpr-cbc-ws2-rtr.mwtn.net (66.62.70.33)  32.355 ms  23.231 ms  50.089 ms
 3  unused.mwtn.net (66.119.55.89)  33.394 ms  37.770 ms  14.982 ms
 4  cbc-cbc9-lnk.mwtn.net (66.62.71.73)  54.910 ms  23.515 ms  33.466 ms
 5  cbc-gsr.mwtn.net (66.119.48.150)  34.954 ms  28.013 ms  19.874 ms
 6  66.62.160.93 (66.62.160.93)  50.172 ms  28.976 ms  25.075 ms
 7  den1-core-01-ae1.360.net (66.62.2.193)  29.738 ms  39.243 ms  36.213 ms
 8  lax1-core-02-xe-3-0-0.360.net (66.62.2.174)  68.732 ms  59.549 ms  69.827 ms
 9  google.com.any2ix.coresite.com (206.223.143.41)  110.151 ms  63.516 ms  64.764 ms
10  64.233.174.31 (64.233.174.31)  65.213 ms  182.785 ms  80.082 ms
11  216.239.43.148 (216.239.43.148)  54.831 ms  78.751 ms  54.192 ms
12  lax04s09-in-f19.1e100.net (74.125.239.19)  60.131 ms  76.823 ms  119.900 ms

I have recently changed how it looks up the Bitcoin network peers so that it does a DNS lookup of all the seed nodes in parallel (on different threads). I think I will have to adjust the algorithm a bit as I suspect that is what is causing you problems.

If you still have an old copy of multiBit 0.4.10 that would be a good test to see if that connnects ok. I made the peer lookup change in 0.4.11.

I did, and it exhibits the same (broken?) behavior  so it doesn't look like it was peer lookup change.  The logs looks pretty much the same so I didn't include it.

Sorry that you are an unvolunteered tester.

No worries, I don't mind.  Thank you for the support.

EDIT:  here is what I am getting for DNS results:

Code:

$ dig +short bitseed.xf2.org                                                                                                       130 ↵
212.7.0.70
46.19.139.106
62.75.216.13
69.64.34.118
69.64.46.74
69.164.196.4
87.139.154.234
91.121.66.59
91.121.120.119
177.71.186.54
184.174.133.70
204.9.55.71
207.164.207.29

[jim618]

It is a possible workaround rather than a fix but you could try connecting to a specific node.
MultiBit will then not do any peer discovery but just connect to the single node specified.

In you multibit.properties add:
singleNodeConnection=12.34.56.78

Where 12.34.56.78 is the IP address of your favourite Satoshi node.
The singleNodeConnection is case sensitive.

Someone requested it for connecting to their local Satoshi client on their local network but you should be able to connect to anywhere.

[ErebusBat]

It is a possible workaround rather than a fix but you could try connecting to a specific node.
MultiBit will then not do any peer discovery but just connect to the single node specified.

In you multibit.properties add:
singleNodeConnection=12.34.56.78

Where 12.34.56.78 is the IP address of your favourite Satoshi node.
The singleNodeConnection is case sensitive.

Someone requested it for connecting to their local Satoshi client on their local network but you should be able to connect to anywhere.

I am glad to know this as I keep a fully synced node on my network for this purpose anyway.

HOWEVER... I still get no connection, and attempting to get bitcoind to add it as a node fails as well... this is very very strange as I don't have anything blocking the connection (that I am aware of).

It is obviously an issue on my end, I will take my laptop home tonight and see what it does there.

[Mushroomized]

While I use this client from time to time, the biggest issue I have with it is that it sometimes doesn't let me send my money, and I have to reset the blockchain and it just dies on me.

This is all good feedback Mushroomized. Is the 'it sometimes doesn't let me send my money" the thing about unconfirmed change ? If so, then yeah we have a plan for that. If it is something else please give some more detail.

The 'it just dies on me' I would like to know more about. What platform are you running on ? I have seen that very occasionally on the Linux VM I use for testing. It is a difficult one to get to the bottom of so any information you have would be useful.

by "it just dies on me" I mean, after resetting the blockchain I still cant use my coins, and have to re install the client.  I should have explained Although I have had it crash a few times on linux mint 64 bit.

[jim618]

In the latest version of bitcoinj (V0.6) is the ability to track the 'transaction confidence'.

One of the measures available is the number of peers that have seen the transaction.
MultiBit typically connects to four peers. If all four have seen the transaction it has most probably propagated out across the network. If only one has seen it then you cannot be too sure of its provenance.

I have added the ability to visualise the confidence of a transaction by updating the icon in the 'Status' field in the 'Transactions' tab.
Have a look at the screenshot:



The mantra I am using is:
    Spikey is dicey. More round is more sound.

The screen updates as the transactions get seen by more peers in real time.
It is a bit of an experiment in visualising this information so am interested in feedback if you think it is useful or not.

The tooltip for the transaction also gives the number of peers e.g.:
    This transaction is not yet confirmed
    Seen by 3 peers.

It will go in the next live release.

[jim618]

I have put some more network information on the tooltip for the 'Online/Connecting..." indicator:



edit: there are also more details in the log file about exactly which peers are being connected to and if it is successful or not (to try to pin down ErebusBat's connectivity problem).

[jim618]

There is a new live release of MultiBit at:

multibit.org


Version 0.4.12

Enhancements:
+ Farsi/ Persian translation 100%
+ "Online/ Connecting..." tooltip now also shows date of last block and number of connected peers.
+ Transaction icon visualises propagation of transaction across peers.
+ Various code hardening/ extra logging.


Scan of release checklist

[ErebusBat]

It is a possible workaround rather than a fix but you could try connecting to a specific node.
MultiBit will then not do any peer discovery but just connect to the single node specified.

In you multibit.properties add:
singleNodeConnection=12.34.56.78

Where 12.34.56.78 is the IP address of your favourite Satoshi node.
The singleNodeConnection is case sensitive.

Someone requested it for connecting to their local Satoshi client on their local network but you should be able to connect to anywhere.

I am glad to know this as I keep a fully synced node on my network for this purpose anyway.

HOWEVER... I still get no connection, and attempting to get bitcoind to add it as a node fails as well... this is very very strange as I don't have anything blocking the connection (that I am aware of).

It is obviously an issue on my end, I will take my laptop home tonight and see what it does there.

Jim (& Others):

Found the issue... I had an old firewall rule to forward port 8333 to a server I had setup to run bitcoind.  This forward was NOT my internal IP.  As soon as I disabled it then BAM MultiBit would connect on startup.

However very oddly at my home where I also have the same rule (although it goes to an active server) it did connect without incident.

Anyway if anyone else complains you may want to have them check for old/invalid firewall rules.

[jim618]

Hi ErebusBat,

Good to know that you found the root cause. As a side effect there is more logging in MultiBit now for the peer connections so that may very help someone else in the future.

It is quite interesting it being your firewall actually. Because bitcoind aren't authenticated if an attacker controls your network neighbourhood (eg imagine your firewall was malicious) it can completely mess you around.

If anyone has any ideas on detecting this I would be interested to hear them. I can't think of a simple way to tell if I have been sandboxed by an attacker.

[ErebusBat]

Hi ErebusBat,

Good to know that you found the root cause. As a side effect there is more logging in MultiBit now for the peer connections so that may very help someone else in the future.

It is quite interesting it being your firewall actually. Because bitcoind aren't authenticated if an attacker controls your network neighbourhood (eg imagine your firewall was malicious) it can completely mess you around.

If anyone has any ideas on detecting this I would be interested to hear them. I can't think of a simple way to tell if I have been sandboxed by an attacker.

At this point it would appear to be only a DOS attack.  I guess they could do a MITM attack and keep block from you or feed you 'bad' blocks, but I think that is only a more advanced DOS attack.

To clarify the problem:
My Laptop: 192.168.1.70
(Old Server): 192.168.1.182

There was a dstnat rule on my router to forward incoming requests on port 8333 to 192.168.1.182.  This server has since been moved and off this network.

So I think what is/was happening is I attempted to make a connection to a node which tried to connect back and the connection was accepted by my FW then forwarded into a blackhole.  However this is pure speculation because my knowledge of how the NAT detection code in bitcoind works is non-existant.

I would speculate that this works at my house because the other bitcoind accepting the incoming requests is most likely detected (probably by some sort of ID echo) which also triggers the NAT code.

[jim618]

Playing around with MultiBit tonight I spotted a bug in the 'Charts' page.
The chart and tab headers go blank, here is a screen shot:

http://multibit.org/postImages/xchart.png

I do have a stack trace of the error so have asked Tim Molter (the XChart library author) to have a look.

If you click on one of the other tab headings the screen goes back to normal so it is recoverable.
I didn't see it at all in testing this morning so I don't know exactly what the cause of it is yet.

edit: This is caused by the vertically rotated text for the Y axis heading. I have removed it and the charts appear ok.

[jim618]

I have added the peer propagation icon (and some descriptive text) onto the 'Send Confirm Dialog' as follows:



When you do a send, MultiBit sends the transaction to one peer, and then listens on all the other peers it is connected to for it to be transmitted back (as the transaction propagates through the network). The icon and text change as more peers see it.

[jim618]

Whilst working on the 'Send Confirm' dialog, I have tweaked it so that the 'Send' button is only enabled once MultiBit has a connected peer.

Screenshot:


When the first peer connects the button is enabled and the text disappears.

Previously MultiBit would queue the send of the transaction until a peer appeared, but this creates a bit of "Send Anxiety". If you are not online it looks like it sent it but actually it is queued for send.

It seemed clearer just to wait until there was definitely a connection available.

[damnek]

Hi Jim,

I'm considering using multibit as my main bitcoin client now, as the satoshi client is simply becoming too slow for me.
I have two small suggestions:
 - scrolling up and down using my mouse wheel in the settings panel goes very slow
 - show the QR codes by default and allow the user to hide them (I didn't understand the green + and there is enough room anyway)
Also, the graphs don't work on my computer. The menu becomes a bit unresponsive when I click on the option.

Thanks for all your work on mutltibit!