MultiBit

[bitcoinspot.nl]

Just out of curiosity. If i understand it correct, multibit is a lighweight client, so it doensnt download and distribute the entire blockchain?
But if everyone starts using lightweight clients, will the blockchain still be distributed over the internet.

[1713250847]

1713250847

[1713250847]

1713250847

[jim618]

You are correct - like other bitcoinj clients (including the mobile ones) it only 'takes' blocks and does not 'give' blocks to other nodes.   

The Satoshi clients/miners are the backbone of the network.   In some ways they *are* the network.
There have to be enough Satoshis/miners for the bitcoin network to be effective.   If there were 100.00% lightweight clients it wouldn't work as the blocks would not propagate around.   It would be like everybody listening but nobody talking.


Another further simplification in bitcoinj/MultiBit is that whilst the blocks are downloaded with all the transactions, once the block is processed it is stored *without* the transactions.   This is the main reason the bitcoinj blockchain is so much smaller than the Satoshi client's on the disk.   (Of course everything comes at a price - not having all the transactions on disk makes things like rescanning and importing keys more difficult.)

I expect we will eventually migrate to a 'hub and spoke' network where the Satoshi clients / miners are the interconnected hubs and the various lightweight clients are the spokes.

[freemoney458]

Hi,

congratulations to your client, it really downloads the blockchain fast as hell under linux on my mac book.
Also the blockchain is really small so that I can keep the client, the blockchain and the wallet file on a TrueCrypted USB thumbdrive.

For me, that is a near perfect solution.

I have some improvement suggestions. The reasons I posted here:
https://bitcointalk.org/index.php?topic=39729.msg553496#msg553496

Here are my improvement requests in short:

1) Please add optional wallet encryption like in the standard client.
2) Please add a feature to import and export the private keys.
    There are some discussions and improvement requests about this for the standard bitcoin client, too.
    Therefore it would be nice if you could find a format that is also supported from the standard bitcoin client.
3) I would also find it practical if you could import/export private keys in QR code format, maybe even supporting
    https://www.casascius.com/ or http://www.bitbills.com/ 
4) I would like to have the possibility to redirect exchange bitcoins to a choosable fixed address instead of the automatic generation of a new address for exchange bitcoins.

I feel that the above requests are badly needed by any client to improve the ability of bitcoin to provide a secure and reliable storage of wealth.
The next requests should enable bitcoin to improve usability in a "real-world" economy.

5) The client should offer the possibility to display the balance in any currency the user likes, e.g. $, EUR, etc.
6) The client should offer the possibility to choose the currency for a money transfer in any currency that the user chooses for the specific transfer. The exchange rate should be customizable like in otc-marketplace.
7) The client should display the transaction history with the specific currency and exchange rate that the user selected for the specific money transfer.

I know the above whishlist is already huge, but wait for the last one:

The client should have an interface to a crowd-based currency exchange mechanism like e.g. ripple. This way the user is not forced to get into the details of currency exchange. This is like using credit card payments in a foreign country: You do not bother about the details, you should pay in the currency you are requested to and the rest is done by the payment system itself. Of course one can think to incorporate online exchanges etc, but personally I prefer to as much keep the concept of distributed crowd services, because it minimizes possible attack vectors against single weak points (and online exchanges have abundantly prooved to be single weak points, even without mentioning past centralized systems like e-gold which were shut down by the governments)


Please keep up the good work.
I am considering contributing with coding to your work, can you give me directions where to start?
Because I am totally unfamiliar to the development environment you are using.

[jim618]

Thanks very much for your thoughtful post.

If I go through your points in turn:
RE: running under Linux on a Mac book.   If you want, you can run MultiBit as a fully fledged Mac app (with pretty icons and everything).   It's the same code but just better integrated for the Mac platform.   I only finished this off this week but will put out a beta next week with the Mac dmg file.

RE: 1).   Yes encryption is a must have.   I plan to copy the standard client's encryption *exactly*.

RE: 2), 3)  Importing and exporting keys are, when it comes down it it, about interoperability.   One of the things that I am adding in the current round of dev work is to change the MultiBit wallet storage format to 'Protocol Buffers' which can be read and written by C++, Java and Python easily.   (You can basically auto-generate the code to access the wallet).
One of the reasons to copy the standard client's encryption exactly is that it makes the possibility of interoperable *wallets* possible.   This is more a long term goal than anything - I haven't even started talking to the C++ devs about it yet.    This would cut out a lot of the importing/ exporting of private keys people currently have to do.

For wider adoption of bitcoin, I think people are happy with the idea of a 'wallet' but the moment you start talking about private keys and asymmetric encryption you are talking another language and they switch off.

RE: 4)  Redirecting change to a fixed address.  Would you mind explaining why you want to do that?  I mean, what is the use case that you are trying to fulfil ?


RE: 5), 6) and 7) Integration with fiat currencies.   This is a tricky one.   If you think of the work the exchanges put in to make exchanging BTC for fiat you realise it is a big task.    Also, you add a lot of complexity and touch points (points of interoperation with 'something else' you don't control) into the code.
Whilst there are other things to do (e.g. encryption) I plan to hold off adding fiat support.
If the exchanges make it easy to convert fiat/ BTC (and perhaps come up with a standard API common between exchanges so that you can get quotes and buy from the best one) then it might be worth doing as the exchanges would then 'own' the complexity.   I expect this is a way off yet.   Also I think fellow traveler is already doing this in his Open Transactions project.

The 'design goal' for multibit is actually the usage you describe as 'Run it from your USB drive/ home computer.   Nice and secure.   Send and receive bitcoin easily'.  

RE: Ripple.   Yes Ripple looks very nice and is obviously complementary to Bitcoin in its philosophy and decentralisation.   Which leads on nicely to your final point . . .

If you want to write code there are various approaches you can take, depending on where your interests lie.   First of all, definitely start using github.com.   It is a step up from coding using SVN or whatever and is practically designed to support open source projects.   It's free for open source.   It is a bit of a learning curve (I am still learning loads) but, well, it is just better.

If you want to work directly on MultiBit then there is plenty of work going !   I think all open source projects are man-power limited and help is definitely welcome.

You might also want to think about 'cloning' MultiBit and using it as a basis for your own project.   I am quite happy for people to reuse the work I have put in as the starting point for their own project.   It is all MIT licence.   Reading some of your other posts I think you might be interested in producing a bitcoinj *Ripple* client.   By this I mean something that connects to the Ripple network but also connects to the bitcoin network.   A bridge if you like.   By reusing the work I have done on the UI work and concentrating on the Ripple network integration you could get further, faster.

I must admit I am not following the Ripple project at the development level so you would want to talk to them to see if they are already working on such a project in Java.   I haven't seen anything on the bitcoinj mailing list about it so I *think* it is 'up for grabs'.   You might also want to check with fellow traveler (who writes Open Transactions) to check there is no duplication there.   (IMHO it is always better to contribute to an existing project that has the same goals rather than starting up a new one as you can get further in a team and it is more fun).

If you want to have a look at the MultiBit code and start building it, create an account on github.com and then do a 'git clone' of the project (jim618/multibit) onto your machine.

The build is now a fairly standard Maven build (the building of the installers is a bit 'round the houses' but it works ok).   If you are not familiar with Maven definitely read up on it as it is excellent.
(The MultiBit readme is a bit out of date actually - it refers to a previous build using ANT - so I would ignore that for now).

Let me know if you need any help.   You can send messages in github.com directly so please use that for any technical questions.   (I try to keep this thread as free as possible from technical mumbo-jumbo to keep it readable for everyone).

Edit: for developing MultiBit, it is fairly independent of the IDE (integrated design environment) you use.  I use Eclipse but  I know other people use Netbeans.   Pretty much everything now understands the structure of Maven projects so you just import it and away you go.








  

[2112]

Integration with fiat currencies.   This is a tricky one.   If you think of the work the exchanges put in to make exchanging BTC for fiat you realise it is a big task.  Also, you add a lot of complexity and touch points (points of interoperation with 'something else' you don't control) into the code.

It is much easier that you make it. Pretty much everything on Earth that is fungible is being traded using FIX protocol. With the curious exception of Bitcoin, where the primitive one-directional JSON-RPC rules. The multi-exchange trading software exists for over a decade.

http://en.wikipedia.org/wiki/Financial_Information_eXchange
http://www.fixprotocol.org/

It is very curious form of myopia or gazing at their own navel. It is almost like the Bitcoin community is somehow trying to reinvent the whell and is hell bent on square whells.

[jim618]

Very interesting 2112 - that protocol is obviously new to me.

I think you are right that bitcoin generally suffers from 'not invented here' syndrome.   I will have a look at that.   Something that is 1992 vintage must already have an open source Java implementation.

Cheers

Edit: Open source Java FIX protocol code = http://www.quickfixj.org/

[freemoney458]

Thank you for your reply, I appreciate very much the dedication you took for answering.

If I go through your points in turn:
RE: running under Linux on a Mac book.   If you want, you can run MultiBit as a fully fledged Mac app (with pretty icons and everything).   It's the same code but just better integrated for the Mac platform.   I only finished this off this week but will put out a beta next week with the Mac dmg file.

I will try it out.

RE: 1).   Yes encryption is a must have.   I plan to copy the standard client's encryption *exactly*.

Glad that you plan it and take it over exactly from the standard client.

RE: 2), 3)  Importing and exporting keys are, when it comes down it it, about interoperability.   One of the things that I am adding in the current round of dev work is to change the MultiBit wallet storage format to 'Protocol Buffers' which can be read and written by C++, Java and Python easily.   (You can basically auto-generate the code to access the wallet).
One of the reasons to copy the standard client's encryption exactly is that it makes the possibility of interoperable *wallets* possible.   This is more a long term goal than anything - I haven't even started talking to the C++ devs about it yet.    This would cut out a lot of the importing/ exporting of private keys people currently have to do.

You are right, it is about interoperability AND not depending on a specific technical solution (client, format of data storage).
Your plans sound reasonable to achieve these goals.
What I am still missing is an import/export button for e.g. bitbills or the like, meaning a solution which needs no programming skills and is easy to handle for the average joe.

For wider adoption of bitcoin, I think people are happy with the idea of a 'wallet' but the moment you start talking about private keys and asymmetric encryption you are talking another language and they switch off.

I completely agree.

RE: 4)  Redirecting change to a fixed address.  Would you mind explaining why you want to do that?  I mean, what is the use case that you are trying to fulfil ?

I have to admit that I have not sent bitcoins myself, I got this idea just from reading the forums. So I could be mistaken.
My use case is the following:
1) I create a 100% secure off-line savings wallet like described in https://bitcointalk.org/index.php?topic=17240.0
2) I save the encrypted wallet in different locations. I could also choose to store just the key to this ONE address in different ways, e.g. as a QR code (encrypted of course).
3) I copy ONE bitcoin address from this wallet and use it as my 100% secure savings address
4) I send bitcoins to this ONE address from lesser secure online exchanges or from other bitcoin clients.
    I can do this overs years without connecting the 100% secure wallet to the internet and still receive the bitcoins because the network stores the transactions for me. So all of my bitcoin savings are stored in a single address.

Nothing new until now, the tricky part comes when I want to spend bitcoins from the 100% secure savings address.
5) I start again my live CD with unix, connect it to the internet and send a small part of my savings to some other address.

Here lies the problem (if I understand the behaviour of the client correctly):
The client sends out part of the savings to the address where I want the coins to be spent.
The remaining part of the savings the client will send to a newly created address in my wallet (with new private key).
Now my 100% secure savings address is EMPTY and I have to use a new address for the remainder of my savings.
This forces me to store my wallet again in order not to loose the bitcoins.
But now the wallet and the new address has seen an internet connection, so I can not be sure that nobody already got access to the private key of the new savings address.

So my preferred solution for this dilemma is:
6) When executing 1) I offline create TWO wallets with a 100% secure address in each. Both are different of course.
7) When spending bitcoins from the 100% secure savings address, I tell the client that it shall send the remaining part of the bitcoins to the 100% secure address in the second wallet. Since this adress has been created offline and the wallet has never seen any internet connection, the private key to this address is still secure. So now I still have a 100% secure savings address.


Regarding your other comments I will need more time to investigate. You gave me a lot to chew through.
Again, thank you for your answer.

[jim618]

Just to let people know:

I will be presenting "MultiBit - a demo of the latest developments"
at the Bitcoin European Conference in Prague in November (25-27).

Should be an interesting conference.

If you want to follow #eurobit there is a bitcointalk.org thread dedicated to it:
https://bitcointalk.org/index.php?topic=40272.0

[jim618]

You are right I think that there will be a third stage where the blocks are so large that only servers will be processing all the transactions.   I hope by then we will have the infrastructure to have our hosted private keys either fully encrypted (as I believe BCCAPI does) or some other cryptographic technique is used to protect us from private key theft.


RE: Multiple wallets.
The full description for the multiple wallets functionality is given here:
https://github.com/jim618/multibit/wiki/Supporting%20multiple%20wallets

In brief it is:
+  A 'My Wallets' button shows a screen listing the wallets (with their balances etc).
+  You have one wallet at a time as your 'Active Wallet' - chosen with a radio button.
+  The send, receive, transactions pages then work with that one wallet.
+  At the top of the screen is a combo box indicating the active wallet.   You can use the combo box to switch your active wallet.

This stops the user interface becoming too cluttered with too many tabs and buttons.


RE: RPC and mining:   Because MultiBit is a 'dumb client' it does not offer an RPC interface to the outside world.   It only has a connection to the full nodes supplying it with blocks and then just asks them for blocks and transactions.   MultiBit is not mining.  Because of that it will not be generating coinbase transactions - you can still of course send coins from a mining pool to it using a bitcoin address you control.   

MultiBit's design goal is to be quite lightweight in use and so does not repeat the RPC/ mining functionality of the main client. (This cuts down the level of complexity considerably as you can imagine).


RE: MultiBit becoming 'stable' rather than 'experimental'.   There is still quite a lot to go into MultiBit before it is the sort of thing you want your grandma to use so it will be experimental for a while yet I think.   It will get there in the end but it takes a remarkably long time to make something production quality.   As an indication of how long, it has taken me about 4 months to get it to where it is now.

The Satoshi client is the place to keep your Big Savings Stash of bitcoins, especially now that the private keys are encrypted.

[jim618]

That is actually quite a subtle point about what has access to the wallet files for updating.

Because you don't want lots of processes 'fighting' over access to the same wallet files I plan to do the following:

+  You open up MultiBit and it displays a list of wallets.   You now have one MultiBit window on the screen and one Java Virtual Machine (JVM) running.   This JVM will do all the reading and writing to the wallets and keeping them up to date.
+  When you want to view a second wallet, or you want to drag and drop between wallets, you will start up another MultiBit window (with everything - amount, buttons, status bar etc) using a menu option I have not decided on yet.   Something like "File | new MultiBit window".
+  At this point you have 2 MultiBit windows but you still only have 1 JVM.   This makes coordination between the MultiBit windows and the thing doing all the updating of the files easier to control and less error prone.  (For the technically minded: You can have JVM level file locks in Java 6+).

This would be the approach for multiple windows on the same machine.   I think it is probably a bad idea to have distinct MultiBits on different machines looking at a common wallet on, say, a network drive.   That is just asking for something to go wrong so I doubt I will support that.

[jim618]

Hello Everybody,

There is a new beta available for MultiBit. The download details are at:

http://multibit.org/download.html
http://multibit.org


Version 0.2.0beta1
Enhancements
+  More language work done - English, Russian, Spanish, Swedish complete.
    French, Italian, Norwegian coming along nicely.
    Improved language picker in preferences screen.
+  Installers for Windows, Linux and DMG file for Mac.
+  Copy and paste added to address field.
+  Fee added to send confirm screen.   Send confirm screen improved.
+  User interface now uses system look and feel for better integration.
+  Added 'singleConnectionNode' option into multibit.properties.
+  Various user interface tidy ups.

Thanks to everyone who has contributed to this beta.

[freemoney458]

Hi,

I just tried out the Version 0.2.0beta1 under Mac OS X 10.5.8 on a MacBook.
The installer works without any problem, and so does the client.

I just seem too dumb to get the QR codes working.
Copying from the Receive screen to MS Word is possible, but dragging a QR code into the Send screen has no effect.

Any suggestions?

[jim618]

At the moment you have to drop the QR code right onto the existing QR code on the send screen for it to get recognised. (I will most likely change this in the future to make it easier). Try that.

Also, it might be something specific to the format of data coming from Word. Try dragging a 'receive' QR code to your Mac *desktop* (which I know works) and then switch to the send screen to drag it back. That would give me a clue that it is Word specific.

[jim618]

Gary Rowe and I have given the http://multibit.org website a new look to make it easier to use.
It also has links to our YouTube channel where you can see our most recent screencast:

"Using MultiBit to buy online with a Bitcoin swatch"

http://youtube.com/user/MultiBitOrg

[freemoney458]

At the moment you have to drop the QR code right onto the existing QR code on the send screen for it to get recognised. (I will most likely change this in the future to make it easier). Try that.

Also, it might be something specific to the format of data coming from Word. Try dragging a 'receive' QR code to your Mac *desktop* (which I know works) and then switch to the send screen to drag it back. That would give me a clue that it is Word specific.

I tried it like you explained, and now it works fine.  
Really seems to be something MS Word specific.

Congratulations to the new homepage and to the youtube screencast. The homepage looks great!
Good purchasing choice during the screencast, too (one of my favourite readings and in a way fitting to the subject).

[mameise]

Hi,

just found this and thought the bitcoin swatches would be great for sells.
Problem: I cannot find to make them in your program.

it would be great to have an api or something.
i think it would be much more easier when we could put in our receiving adress, a label and the amount and it would generate such a swatch like you used it.
it also would be great to enter an amount in usd or € instead of btc, and it converts into btc using mtgox or so.

if this would be possible, it would looks great so maybe you can think about it.

thanks

[jim618]

freemoney458 - thanks !  Yes we wanted to put Cryptonomicon in as the purchase as it is such an appropriate book for bitcoin.

mameise - yes - I have just been writing a 'swatch generator' into MultiBit so that the user can create them.   This should go into the next beta.   In the receive bitcoin panel when you type in the label and amount it creates a swatch automatically in the panel on the right hand side so that you can copy it out of MultiBit.  It will still be in BTC though as we do not have any exchange look up in MultiBit yet.

I am hoping to do betas about every two weeks or so until the 0.2.0 work is all done.

[brandondayton]

What happens with my current wallet when I install a new client? Will MultipBit create a new Wallet.Dat or does it look for something, if it's already there? Just want to make sure I don't end up deleting my current wallet or something awesome like that.

[jim618]

MultiBit does not touch any existing wallet.dat.

The default wallet is stored as 'multibit.properties' in the installed MultiBit application directory itself. (Or inside the application bundle on a Mac).

Note that the default multibit.properties location will actually change as it causes problems if you are logged into an account that does not have administrator rights.   I will definitely keep it well away from the Satoshi client's wallet.dat though.

[brandondayton]

Cool. I'll give it a spin.