MultiBit

[bitcoinspot.nl]

Hi there!

A little while ago i posted a message regarding a few wishes i had for multibit. I love the client a lot but would like to see a few extra options so that it can be used in a retail-setting.

- the option to show a qrcode of the adress in full-screen
- the option to add a email-adress to a transaction to send a payment request

Did you have time to look further into these ?

p.s.
Will the other clients be using the bitcoin-browser integration soon ?

[1715210862]

1715210862

[1715210862]

1715210862

[1715210862]

1715210862

[jim618]

Hi bitcoinspot.nl,

Thanks for your feedback on MultiBit and suggestions.   I have had a think as to implementing them:

Bigger QR code
I have put the 'show QR code bigger' functionality into the UI rework I plan to do for the 0.3 release.
The document with all the UI rework is here:

https://docs.google.com/document/d/1eJ-vKf6yc5tLuvzKPJDiSwKzHophVYXH0rPfhpIUzq8/edit?hl=en_GB&pli=1

Email support
I have had a think about the emailing of transaction details.   It would be possible to add in configuration data for a link to an SMTP server (this is a standard email server type that most non-web email clients connect to).   It would then be possible to have a set up with:

1) Whenever you send bitcoins have the option to add in a recipient email address so that they get a message something like:
    "You have received X bitcoins to address Y.   The label was 'Z'.

   There would have to be a template file for the format of the email for it to be useful and localisable.
   You would probably want to CC yourself in too.

   This would be like the PayPal 'You have received funds' email you get.

2) Even when no recipient email was specified you could CC yourself for your own records.

This would give a "funds sent' email.

Tracking transactions
You also mentioned earlier keeping track of 'transactions not yet paid for' (Invoices).  This is much more work as currently there is no database backing MultiBit.   Transactions are only the basic transactions stored in the bitcoinj wallet.   To start tracking transactions for which there is no bitcoin transactions means adding a backing db.   I can see this coming but it is a big chunk of work - I am hoping I will be able to reuse the work Gary Rowe is doing on MultiBitMerchant when he completes this as it is similiar.

Order of work : What I am currently working on
I have put your email support suggestion into the proposed list of work for MultiBit 0.4.   The list of what work is in which version is here:
https://github.com/jim618/multibit/wiki

Currently I am doing some maintenance work and then will be making a push on having encrypted private key files and encrypting the wallets themselves.   After that I will be working on the UI refresh and basic exchange integration using Tim Molter's XChange library (the two are a bit entwined).   The 'show QR code bigger' functionality I will add in then.

That will be, more or less, everything in the 0.3 release so I will then get that out and start bug fixing.

After that I will start on the more detailed 0.4 use cases - including your email support requests - so I will probably ask for more details (or ask for you to review the use cases) at that point.

Also parallel to this is the Open Transactions fork of MultiBit in which they have added OT functionality.   I am planning to have a look at what they have done when I do the UI refresh/ basic exchange integration to see if this can be 'folded in' to the UI/ code.   This is a bit experimental at this stage so I have not put it explicitly in the deliverables.  

[jim618]

Sorry - forgot your PS about bitcoin URI support.

I know Electrum has added support for bitcoin links (that you can click in a browser and the details get put into the bitcoin client).
The Satoshi client and Armory I do not know if they are supporting it/ what their plans are.

There are also a couple of upgrades to the bitcoin URI format in the works.

One is a better, more future proof, format specified here:

https://en.bitcoin.it/wiki/BIP_0021

Gary Rowe has just coded this up in Java and I am currently putting it into MultiBit.   The code we are donating to bitcoinj so that other bitcoinj clients will be able to use it.
ThomasV was the driver for this format so I am pretty sure Electrum will be supporting this (if he has not already).

ThomasV has also created the idea of email aliases and signed URIs, which is already in Electrum 0.38 and is described here:
http://bitcoinmedia.com/electrum-0-38-aliases-and-signed-uris/

I think aliases and signed uris are great and think that both MultiBitMerchant and MultiBit should support them.   Actually coding it up I am not sure when we will do it as both Gary and I are pretty much 'full' workwise at the moment.

[jim618]

Also, I have been looking into getting some custom USB drives made with the MultiBit logo/ site URL on and preloading them with:

+ the MultiBit executable
+ Java runtimes for Windows + Linux (Macs always have one).

This would mean you could have a 'secure stash' for your bitcoins where you could plug in your 'MultiBit USB drive' into ANY Windows/ Mac/ Linux machine to access your bitcoins.   Your wallets would be stored on the USB drive.
When you are not accessing them you just store them wherever you store your passports/ family jewelry.

Our current prefered model is this one:
http://www.usb-flashdrive.co.uk/usb-flash-drives/twister-drive-1


For backup, you will be able to export your wallets' private keys and put them somewhere safe.
For security this would only make sense when both the MultiBit private key export files and wallets are both encrypted hence the push on that.

We will be offering these for sale to the general public at pretty close to cost price.   It feels like a good way to get the word out about bitcoin.

[freemoney458]

I thought you would be interested in some future MultiBit development work we are starting up.

Tim Molter is a Java developer who is writing a library to integrate with the various bitcoin exchanges.
You can get more details of his project here:

https://github.com/timmolter/XChange/wiki/Milestones
https://github.com/timmolter/XChange/wiki/Exchange-support


We are planning to use XChange in both MultiBit and MultiBitMerchant, initially to get exchange rate data but later on to provide deeper integration with the exchanges.   (We are still working out what we can and cannot do).

It will be a while before it appears fully productised in MultiBit / MultiBitMerchant but it is very interesting work.

Hi Jim,

I appreciate that you plan to integrate an interface to bitcoin exchanges.
I think it will really help to improve the usability of any bitcoin client for a broader audience.

However, I think it is not enough to only integrate an interface to centralized exchanges for two reasons.
1. The recent events around Paxum and Tradehill show the vulnerabiltiy of bitcoin and of centralized exchanges.
    The experience of the Tradehill customers having to find another exchange is not acceptable for a broader audience, but only for enthusiasts.
2. Even having to sign up and to mantain an account at an exchange is an effort that many people will not like.

I thought a bit about decentralized exchanges and how to integrate them into bitcoin clients, you can find it here:
https://bitcointalk.org/index.php?topic=45751.msg746894#msg746894

So here is my conclusion:
An interface for some basic exchange function support should be added to bitcoin clients.
The interface should offer the possibility that the bitcoin client interacts with centralized and with decentralized exchanges.
Ideally, the buying and selling of bitcoins runs automated in the background without the need of a user interaction.
There is no need to integrate everything in the client, this can be done with a brokerage client which interfaces with the bitcoin client.

The interface to the brokerage client would need such functions as:
-Inform about the bitcoin balance in a wallet (this would allow automated brokerage whenever the amount of bitcoins in the wallet reaches lower or upper limits)
-Inform about Buy/Sell orders of the user (assuming that the user initiates such orders in the client)
-Payment of bitcoin through the client to a bitcoin buyer in the case that the user want to sell bitcoins
-Inform about bitcoin receiving address generated in the client in the case that the user want to buy bitcoins
-Inform about received bitcoins in the case that the user wants to buy bitcoins
-The whole interface to the brokerage client needs to be encrypted for security reasons

Do you know if this will be possible with Tim Molters work or with the OT fork of MultiBit?

[jim618]

Hi freemoney,

I think we are both thinking along the same lines.
I would love for there to be decentralised exchanges in bitcoin but I do not think we are anywhere near there yet.

Initially the MultiBit exchange integration will be quite shallow (probably just getting exchange rates initially just to get the plumbing working) but I would like to deepen it over time to have the buy and sell orders etc.

I figure if I/ the bitcoin community collectively can get it to work for centralised exchanges then we are one step nearer decentralised exchanges.

I think the most difficult area is the contact point with the 'World of Fiat'.  In your linked example you mention DarkExchange and a Germany specific account link.  I am hoping that experience from integrating a few exchanges and OT will give us a workable interface that gives most functionality that is required (as an interface i.e. there will be limited implementations)

At that point it might be practical to have Country/ Fiat providers specific plugins.   The XChange code is open source and whilst we are concentrating on the Java implementation it is not actually language specific.   That would be the place for Country/ Fiat provider plugins to go (and hence they would not be MultiBit specific and available to all).

One step at a time here I think !

:-)

p.s. If anyone is interested in actually DOING an open source country/ fiat provider specific plugin let me know.

[garyrowe]

The interface to the brokerage client would need such functions as:
-Inform about the bitcoin balance in a wallet (this would allow automated brokerage whenever the amount of bitcoins in the wallet reaches lower or upper limits)
-Inform about Buy/Sell orders of the user (assuming that the user initiates such orders in the client)
-Payment of bitcoin through the client to a bitcoin buyer in the case that the user want to sell bitcoins
-Inform about bitcoin receiving address generated in the client in the case that the user want to buy bitcoins
-Inform about received bitcoins in the case that the user wants to buy bitcoins
-The whole interface to the brokerage client needs to be encrypted for security reasons

Without hijacking the Multibit thread, I'd just like to clarify the purpose of the XChange project.

It's intended to act as a common API for any exchange (Bitcoin, fiat, centralised, distributed etc) so that applications can easily use any of them, in combination if required. To that end pretty much all of the above functions are going to be supported. For all operations, a brokerage is considered to be the same as an exchange.

When it comes to depositing fiat into the exchange there is a potential issue. XChange won't support this directly (it's not a payment gateway for MasterCard for example) but it would facilitate instructing the exchange to make, say, an authorised debit against a registered bank account if the exchange supported that through it's API.

As mentioned, XChange is Java only at the moment, but if anyone wants to start up a sister project, or work within the same repo, using a different language then they are certainly welcome. Just PM me for more details.

Finally, by providing a standard API XChange may be able to assist developers of new exchanges by showing them what needs to be available and how to implement it securely, and have a suitable test client all ready to go so they can verify that it all works as intended.

[freemoney458]

Hi Jim and Gary,

thank you for clarifiying the aim of the XChange project and for clarifying the roadmap as you see it for the future of exchange integration.

It is really nice to see that we are thinking along the same lines.
I did not want to sound impatient, I can imagine how much work you already put into it and how much work it still will be.
So: Thank you again for all the work and enthusiasm you are putting into this.

I hope that the other clients and the exchanges will incorporate the XChange API.

[jim618]

Hi freemoney,

Yes - it will be an interesting Spring and Summer if we can program it all up !

:-)




On a completely different note:

piuk - the author of the blockchain.info wallet - has introduced the ability to import the MultiBit key export files in their entirety into the blockchain.info wallet.

The option is in the 'Import/ Export' tab in the 'Import Wallet' section.
You just paste in the whole contents of a MultiBit key export file in the text box and hit 'Import Wallet'.

A couple of times when I have done it I had to close the browser tab, open a new one and relog in to my wallet to get it to refresh (I have mentioned this to piuk) but apart from that it seems to work well.   MultiBit does not see the zero-confirmation sends if you send from the blockchain.info wallet but it picks up the block confirmation (I will look into this).

It is like having a 'live backup' of a MultiBit wallet in blockchain.info and vice versa.

[bitcoinspot.nl]

Hi!

Thanks for incorporating my suggestions in the client, i really appreciate it!
one note though:

I though of the email feature more for payment-requests, not only for payment notifications.
The idea is that: if someone says "to which adress must i send the bitcoins" (e.g. in a restaurant or what have you) that you can say, "well let me just send you an email out of multibit which contains a swatch and bitcoin adress".

Like the notification option though

Greetings!

[jim618]

Hi bitcoinspot.nl,

Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.

RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil.   Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).

For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.

His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.

You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).

ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine.   This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.

[ThomasV]

Hi bitcoinspot.nl,

Glad to hear your suggestions - it gives me useful feedback as to where to direct my efforts.

RE: using email for payment requests.
One of the unfortunate limitations of the email practically everyone uses is that is it as insecure as sending someone a postcard written with a pencil.   Anybody who forwards it can read it and alter it. (Obviously not true with encrypted, signed email but this isn't widely used).

For payment requests it adds a whole number of security holes: For instance -
Scammer walks into your restaurant, eats a delicious meal and asks for the bitcoin address to pay to.
You email a payment request to him and (via his email server he has set up) swaps out YOUR bitcoin address for an address he controls.

His phone pings when you send the email and right in front of you he pays with the address in the email that looks like it came from you.
The bitcoin actually goes to an address he controls.

You will never see the bitcoin but it looks like he paid (and he can show you 'your' email with 'your' bitcoin address he just paid to).

ThomasV has added an experimental idea to have signed URIs so that you can tell the URI is genuine.   This (or something to improve the URI security in a similar way) would have to be added before vanilla email can be used safely for payment requests.

Hi  Jim,

There are two parts to that proposal: signed URIs and aliases.
Aliases are similar to email addresses. Instead of handing out your bitcoin address to someone, you just give your alias to someone.
I think that such a possibility would vastly increase the usability and acceptance of Bitcoin.
There is some demand for it (see thewalletlist.com)

However, my current proposal relies on a trusted authority that signs the alias.
The trusted authority must never be hacked, and it must follow certain rules (it should never sign the same alias twice).
If the owner of the alias wants to update the alias, he has to create a chain of signatures.

I think that this proposal would be improved if we could store aliases in the blockchain. The blockchain is a secure way to authenticate ownership of an alias.
I guess we could use Bitcoin or Namecoin. The Namecoin blockchain has been designed to suit that need. To play with the idea, I created the following alias:
http://explorer.dot-bit.org/n/37310
As you can see, it points to a Bitcoin address.
In order to simplify wallet management, I guess the Namecoin address that is used and the Bitcoin address could be derived from the same private key.

Using the Bitcoin blockchain would be perhaps a bit more convenient and easy for both users and programmers. Since we do not need to store arbitrary key-value pairs (the value is a Bitcoin address), using Namecoin introduces unnecessary complexities. We could derive a Bitcoin address from an alias (using a hash, but not the same hash as if the alias was the private key :-) ), and send a satoshi to that address; this creates an alias. To update it, the address owning the alias would need to create a transaction that transfers the alias to another address, for example with two outputs: the alias and the new address.

[m3ta]

Code:

05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1 
05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 2 
05:37:34.263 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1 
05:37:34.264 [AWT-EventQueue-0] ERROR c.g.bitcoin.core.TransactionOutput - Could not parse tx output script: com.google.bitcoin.core.ScriptException: Script not of right size to be a scriptPubKey, expecting 5 but got 1 

(2GB of logs like this)

3956 block(s) to download. This may take a while

And stuck.

[jim618]

Hi m3ta,

I know Mike Hearn updated the bitcoinj library for the code throwing the error (TransactionOutput) to handle scripts it does not understand on February 10th.   This is not in the released MultiBit yet.

If you let me know the platform you are using (Windows, Mac, Linux) I will create you a build of the latest code for you to try out.   This code is not quite production release yet - I need to do some more testing on it and some bug fixes - but will establish whether the latest bitcoinj code fixes your problem.

[fsb4000]

I had a strange bag today

Code:

2012-02-19 19:41:07,640 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,425 INFO  - NetworkConnection          - Connected to peer: version=40000, subVer='', services=0x1, time=Sun Feb 19 19:41:08 NOVT 2012, blocks=167511
2012-02-19 19:41:08,426 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:08,426 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,426 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

2012-02-19 19:41:12,640 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,606 INFO  - NetworkConnection          - Connected to peer: version=32400, subVer='', services=0x1, time=Sun Feb 19 19:38:18 NOVT 2012, blocks=167511
2012-02-19 19:41:13,606 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:13,607 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,607 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

2012-02-19 19:41:17,640 INFO  - PeerGroup                  - connecting to Peer(bitseed.xf2.org/173.255.194.34:8333)
2012-02-19 19:41:19,365 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:22,641 INFO  - PeerGroup                  - connecting to Peer(bitseed.xf2.org/66.158.72.2:8333)
2012-02-19 19:41:25,056 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:27,641 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 INFO  - NetworkConnection          - Connected to peer: version=50200, subVer='', services=0x1, time=Sun Feb 19 19:41:28 NOVT 2012, blocks=167511
2012-02-19 19:41:28,304 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:28,304 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Connecting.... Synchronising with network 735 blocks to download.
jim618 can give some version of me as well. System: Windows 7 x64 Home Premium

[CrownCloud]

I had a strange bag today

Code:

2012-02-19 19:41:07,640 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,425 INFO  - NetworkConnection          - Connected to peer: version=40000, subVer='', services=0x1, time=Sun Feb 19 19:41:08 NOVT 2012, blocks=167511
2012-02-19 19:41:08,426 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:08,426 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/213.216.77.143:8333)
2012-02-19 19:41:08,426 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

2012-02-19 19:41:12,640 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,606 INFO  - NetworkConnection          - Connected to peer: version=32400, subVer='', services=0x1, time=Sun Feb 19 19:38:18 NOVT 2012, blocks=167511
2012-02-19 19:41:13,606 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:13,607 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/193.107.204.107:8333)
2012-02-19 19:41:13,607 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

2012-02-19 19:41:17,640 INFO  - PeerGroup                  - connecting to Peer(bitseed.xf2.org/173.255.194.34:8333)
2012-02-19 19:41:19,365 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:22,641 INFO  - PeerGroup                  - connecting to Peer(bitseed.xf2.org/66.158.72.2:8333)
2012-02-19 19:41:25,056 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException java.net.ConnectException: Connection refused: connect
2012-02-19 19:41:27,641 INFO  - PeerGroup                  - connecting to Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 INFO  - NetworkConnection          - Connected to peer: version=50200, subVer='', services=0x1, time=Sun Feb 19 19:41:28 NOVT 2012, blocks=167511
2012-02-19 19:41:28,304 INFO  - Peer                       - blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000)
2012-02-19 19:41:28,304 INFO  - PeerGroup                  - running Peer(dnsseed.bluematt.me/184.73.208.210:8333)
2012-02-19 19:41:28,304 ERROR - PeerGroup                  - error while talking to peer : class com.google.bitcoin.core.PeerException com.google.bitcoin.core.ProtocolException: Error deserializing message 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee00000064000000004653656520626974636f696e2e6f72672f666562323020696620796f7520686176652074726f75626c6520636f6e6e656374696e67206166746572203230204665627275617279004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Connecting.... Synchronising with network 735 blocks to download.
jim618 can give some version of me as well. System: Windows 7 x64 Home Premium

I'm having a similar problem it says "Connecting"  203 Block(s) to download...

[jim618]

Hi m3ta, fsb4000, speedbus,

RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:

Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe

Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg

Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar


I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.

A couple of notes:
1) I was not planning to release this code just yet.   I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.

2) There is not much visually different with this release compared to the previous.   I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot).  Oh - and having a holiday in Spain !

[CrownCloud]

Hi m3ta, fsb4000, speedbus,

RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:

Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe

Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg

Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar


I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.

A couple of notes:
1) I was not planning to release this code just yet.   I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.

2) There is not much visually different with this release compared to the previous.   I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot).  Oh - and having a holiday in Spain !

Thanks !! It works

[fsb4000]

Hi m3ta, fsb4000, speedbus,

RE: your connection problems today - I have built my current MultiBit codebase into a release 0.3.0beta3 and loaded it to github as follows:

Windows installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-windows.exe

Mac DMG file
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3.dmg

Linux installer
https://github.com/downloads/jim618/multibit/multibit-0.3.0-beta3-linux.jar


I have done a quick test on my Mac + virtual machines (Win XP, Ubuntu 10.4 LTS) and they all connect and download blocks ok. Please let me know if they connect and download blocks on your systems.

A couple of notes:
1) I was not planning to release this code just yet.   I know it has a bug in the private key import that I have not tracked down yet.
I expect I will do another release a bit later on this week once I have fixed it.

2) There is not much visually different with this release compared to the previous.   I have mainly been working on updating from an older version of bitcoinj (0.3) to the latest code (0.4-snapshot).  Oh - and having a holiday in Spain !

Thanks !! It works

Thanks !! It works too

[jim618]

I just fired up the 0.3.0beta3 code (the one in the links a few posts above) to check it works post midnight feb20.
It connects ok, downloads blocks and I just sent some BTC to and from it ok.

Also, I think I have figured out what the bug was in the 0.3.0beta2 code that prevents it connecting - I think it was the alert message sent out on Feb 19 - it did not understand it and that messed up the connection