Bitcoin Forum

So the plan is for the next release of bitcoin to switch from the wxWidgets GUI we have now to the vastly nicer QT GUI that John Smith created.

I spent some time yesterday compiling Qt and bitcoin-qt, and some time this morning doing a very quick code review (executive summary: looks great!).

I'm mostly posting this as a brain dump of "stuff not to forget" when it is time to pull QT and remove WX.

Major behavioral differences I noticed during code review:

• Does not generate new receiving addresses automatically (good idea, I think, but may be controversial).
• Cannot act as a rpc client (ok with me, we'll still compile/ship a headless bitcoind)

Will-need-to-be-done stuff:

• Find and replace or remove references to wxwidgets in documentation, makefiles, etc.
• Change makefiles to track rpc.cpp --> bitcoinrpc.cpp name changes
• The QT library is LGPGL licensed; do we need to change READMEs or other files?

... and probably a bunch of other little things I didn't notice or I forgot to write down.

Can you provide a screenshot for a reference?

Can you expand on this? I currently run 'bitcoin -server' on my linux machine. This gives me the GUI for monitoring transactions and the RPC functions to support solo mining. If the RPC client is removed, I'll have to run 'bitcoin' and 'bitcoind', but there is (I think) a conflict with the port address and the second client will not run. I will also need to download and maintain two copies of the block chain (a minor annoyance)

Is there a reason for this or is it just "the way it got coded"? It helps me somewhat to be able to have rpc to the running GUI bitcoin client. Either that or the priv key import/export *hint* :)

Also, this may not be the right place to ask, but why the move from wx to qt? I know a better GUI was long due, but I happen to know and like wx (have no quarrel with qt, mind you) and I don't think there's much if anything that you can do with one and not with the other...

RE: cannot act as a RPC client:

I believe it will still be able to act as a RPC server.

So you can run the GUI with the -server switch, but you'll have to talk to it using (for example)
  bitcoind getinfo

... as opposed to today, where you can run "bitcoin -server" to get the GUI and then run "bitcoin getinfo" to talk to the running GUI process.

RE: why switch:  because no wxwidgets programmers stepped up and made it better.  And from what I can see, QT is more popular and supported (so there are more programmers able and willing to help improve).

RE: screen shots:  See the bitcoin-qt thread in the Alternative Clients sub-forum here.

That's perfectly acceptable. I thought the rpc server was being removed for whatever reason, but if it's just the cli client for the GUI then it makes perfect sense.


That's more than fair :) I am not a die hard wxwidgets coder, nor a GUI coder tbh. I actually have "I suck at designing user interfaces" in my CV, though not in those exact words! I was just curious about some shortcoming of wx that I was unaware of. All good :)

Gavin,

Could you or someone provide a list of future version numbers you are intending to use?

I will then add them all in one go to the rrd charts of versions running at:
http://bitcoinstatus.rowit.co.uk/versions.html


It is very dull job adding them and I would much rather add a load in one go!


Thanks

0.4.0 : Out real soon (0.4.0 release candidate 2 binaries are available on sourceforge now)

0.4.1 : I'd give about a 80% chance of happening (major bug or security problem found in 0.4.0)
0.4.2 : I'd give about a 20% chance of happening (major bug or security problem found in 0.4.1)

0.5.0 : Will be the Qt release.

Beyond that...  who knows?

QT is an awesome platform, good move.

Mmm...

> Does not generate new receiving addresses automatically (good idea, I think, but may be controversial).

 I like this feature. I do not want to see it removed. I like to keep track of all my "DYMANIC" and of my "STATIC" addresses... This should NOT be changed.

 BTW, I don't like QT... It is a ugly toolkit... GTK3 is much nicer... But, I appreciate the effort!!

 Anyway, do you know, more or less, when the Bitcoin core will be decoupled of the GUIs?! I mean, when will be only somekind of oficial LibBitcoin and a lots of GUIs, like QT, WX, GTK3, GTK2... ???

Thanks!
Thiago

So the integers will be:
40000
41000
42000
50000

This follows on from the current ones that are:
32400
32500
etc...

BTW, I don't like GTK… It is a ugly library that needs more libraries to call it ugly toolkit… Qt is much nicer… Thanks for the effort!

Ok other thing. Do you know that in Qt you have built in GTK style? It import the current GTK system and maps it on Qt application (also with switched order od OK and Cancel in dialog box). It should be automaticly turn on if Qt detects Gnome session, but you can change it running qt-config.

Well, honestly, you have the point... And I agree with you... GTK have its own problems, so as QT (license issues?! Don't know anymore, in the past, yes...)...

But my point is, and I just like to have an idea about it, I'm not demanding this from anybody ok... When the Bitcoin will be detached from the GUI / Daemon? Is there any roadmap for this?!

I like to see tons of GUIs (QT, GTK3/2, ELF, OpenStep, Aqua, Windows, etc...) using the same "LibBitcoin" (from http://bitcoin.org), including the non-gui bitcoind...

BTW, what about Enlightenment Foundation Libraries?! I think it is one of the most amazing open source toolkit out there... Don't you think!? http://www.enlightenment.org/ (http://www.enlightenment.org/)

I'm asking this because I have a draft of my own Bitcoin GUI and I'll hire two developers (friend of mine) to write the GUI... But first, I see that we need a libbitcoin or something like that befora start anything like that...

Thank you!
Thiago

I just made the big pull request: https://github.com/bitcoin/bitcoin/pull/521

• To be clear, the Qt GUI can function as RPC server. You can mine with it, or interface to it from your favourite remote control script; just provide -server (and all other bitcoin command line arguments except -daemon).

• It is not a RPC client. This might be added in the future (see issue #17 (https://github.com/laanwj/bitcoin-qt/issues/17)), but in that case it will work as a graphical RPC client and not a command-line one. For the love of separation of concerns and other sound software engineering principles I'm against combining a command line RPC client and a GUI server/native client in one executable.

• "Qt is an ugly toolkit" is BS, you can theme it any way you want with both images and vector graphics. You can even make it show in GTK themes. I chose QT not because of the graphical looks but because it is well-designed and encourages clean, maintainable code.

• Also: as the Qt GUI is pretty much isolated from the core (only the models communicate with the core), it can serve as an example for other GUIs, or used as a starting point for moving all non-GUI code (such as lock handling) to the core and offering a nicer interface there. I did not do this because I wanted to minimize core changes.

• What license issues? Qt is LGPL, just like GTK. Wx is similar "The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms" (http://www.wxwidgets.org/about/newlicen.htm)

Thanks! :)

MIT code can use LGPL libraries with no legal problem. So can just about anything else. It was the whole point of the L in LGPL.

Speaking as a non-developer user I would love to see a complete separation between the two.

It would be awesome to have a server that assumes that it will be managing the wallets of everybody on a LAN and authenticates users via PAM (or whatever they use on Windows to do the same thing) and that the GUI clients were just that and nothing more.

The windows installer could install both the service and the client at the same time so those users wouldn't even know the difference and you could even use zeroconf/avahi to make it easier for the clients to find the local server.

I'm not sure we need to switch, at least not yet. Sounds very dangerous to me not having any transitional strategy. That never works... Looking at the code and already seeing potential issues is one thing, but trying the client in real life is another one, it will unveil tons of unexpected issues. Let's be very careful, because the client is a major part (nearly 100%) of the Bitcoin network.

I'd say qt-bitcoin is (at last!) released, and people be free to use whichever client(s) they prefer. Moreover, protocols need diversity in implementations, so it's all for the better.

Don't mean to break the fun, but IMO the best GUI would be browser-based, where the client only exposes HTTP server and serves some customizable HTTP/JS app. And the user's browser does the rest. Such solution would have a number of advantages.
I think Qt is a waste of time - we will still need a huge dev env to change a dot in the GUI.

Such as?

I can think of a lot of disadvantages, such as slower interface response times, exposing your interface to anyone who connects to a port, debugging it in all the browsers and their different versions, interfering browser plugins and adblocks, phishing, etc. The GUI is very simple, you won't get much advantage by using a browser as your GUI, it will probably be more difficult.

I am all in favor of UI / backend split, but see no advantage in making main UI browser-based.

Reading this thread it occured to me that bitcoin already has one killer application: Satoshi bitcoin client can be an excellent way to judge the competence of the applicants for a C++ programming job.

It is open source and it is fairly short. Yet its architecture is such convoluted that can be an excellent means of judging the advanced programming skills. Example: just ask an applicant what would it take to convert the wxWidgets/QT user interface to a http+ajax one. Or ask what would be required to implement a multiple wallets. Or ask to estimate the time required to replace BerkeleyDB with say Oracle.

Mad props to John Smith for having enough understanding of both UI toolkits to execute this change single-handedly.

I don't know if it's been fixed since I noticed it, but at least some version of it is lacking the ability to enable/disable UPnP support at compile-time.
It also adds an implementation of bitcoin: URIs that is not compatible with the existing established/in-use standard.

Qt supports GTK2 right now, at least. I expect it will support GTK3 soon.

You can already run bitcoind+Spesmilo

This has been fixed, you can provide USE_UPNP=XXX to the qmake script (see the qt readme).

It's just a wiki page, not a standard. In my (and Gavin's and many others) opionion URLs should be as simple as possible. The 1243X45 exponent stuff is simply arcane.

I do agree more standardization should happen, an "official" Bitcoin URL format would be an interesting subject for a BEP. When that standard format is determined, it will of course be integrated into the client.

Until then, we chose the most simple format possible, which can be described in one line: bitcoin:<addr>?label=<label>&amount=<BTC>   (label and amount are optional)

+1 It is a security nightmare. Suddenly everyone developing on the UI has to worry about CSRF, XSS, and so on. The browser has such a large attack surface, you'd probably make some "security researchers" very happy. .

Also, most users of any OS still expect an application to have a desktop UI not a "website in a program".

There is a web UI, though I don't know how stable or mature it is: https://github.com/zamgo/bitcoin-webskin
A network UI/backend split would "only" be a matter of extending the RPC enough to make a full-functional UI (it especially needs async notifications/callbacks).

Yes, I recommended Spesmilo to the people that want RPC client support in bitcoin-qt.

Wow, the URI topic has surfaced again :)

I still love the Vladimir's scheme better as more readable:

bitcoin:/0.02/address or bitcoin://address if there is no amount

but I am so glad you guys prefer simplicity. Last time I've argued about the URI's I thought everything was lost and the Luke's "standard" will be eventually implemented :)

About UI / Backend split: it is important. If there was a backend right now I'd write a native Windows UI in a couple of days, without QT, without boost. It would be small and fast.

I don't believe much in a single codebase for all platforms. It works for "numbers stuff", like encryption or file access or even network. Those thing are relatively easy to port.

The GUI is different. In my opinion, it should be natively written for every platform. GIU concepts are different across platforms.

Also, I've installed QT yesterday and even if I selected only absolutely necessary stuff it took more than 1 GB! Having such a dependency for a simple GUI like this is an overkill. Plus, the less code is better from the security and reliability points of view.

Backend doesn't have to be an extension of the RPC server, that would be cumbersome. It should include (optional at compile time) RPC server, but would itself probably better be implemented as a library (both dynamic and static).

If anyone is interested in helping to test the UI, please send an email to QA@BitcoinTesting.org - a description of experience is helpful but not needed.

Such as:
- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI
- easy to setup remote access to the GUI
- the ultimate platform independence (no wx, no other qt will ever give you that)

Slower response times don't matter in this kind of application.
You can limit the GUI to accept TCP connections only from localhost.
Developing and debugging of HTTP/JS apps is easy.

To give you an example, an idea, just have a look at the WebUI of uTorrent.
It is much more complex GUI that BitCoin will ever have. And it works really great, nobody has with it any problems you've mentioned. It works with basically every modern browser.

This is solved by writing a native, not a browser GUI.


When do you need it and what about security implications?


- the ultimate browser type and version dependence.


Slower response times matter in any kind of application. They affect subconscious feelings of users - how they feel about the application.


...making it easier for any malicious, especially browser-based, viruses to interact with the client. I am not sure, but what if the user opens a README for some program that contains an AJAX javascript to interact with the GUI? Will it be accepted because it will come from localhost?


Ha! Why didn't I know this before?! What a fool I was spending countless hours, trying to make something look and work the same way in all browsers...

And then develop each platform independently?

Oh. Just give me such option and let me worry about my security.
I really don't see it as a problem.

No. It's 2011. You can easily make HTML/JS app that works fine with every modern browser.


Sounds like you are a real expert in this domain - I'm not going to argue here. :)

Maybe it will, maybe it wont... You can protect HTTP session by different means.
I really don't understand your security concerns. Don't you use internet banking?


Oh, I'm sorry to hear that. Next time feel welcome to ask me - I will help you to write a webpage that looks the same on every browser.

Only if you consider Internet Explorer "not a modern browser."

And anyway I think you missed the sarcasm. :)

uTorrent's WebUI works fine with IE as well.

I didn't miss the sarcasm - I just followed it :)

The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.

See no point in arguing about the rest of your points - I've already stated my opinions about them.

I just want to say that I'm very enthusiastic about the switch to Qt.  The fact that my window manager of choice is KDE probably has a lot to do with that.  :P  Anyway, props to the developers for their contributions and for putting up with the criticisms from the community.

For me it's not about writing a GUI for the current client - there is already a GUI for the current client, so why to change it? Just so it would respond a few ms quicker on mouse clicks? Maybe that would be a good reason if it was slow, but it isn't slow. The biggest problem of the current GUI is that it's a hassle to change anything in it and hard to control/review the changes.

I thought wx was being abandoned to make further development of bitcoin's UI easier - that would be a good reason.
Unfortunately IMO you won't make further GUI development easier by switching from wx to Qt.

Maybe the GUI shall be indeed a separate application which talks to bitcoind via some interface - like the JSON-RPC, but with both-way notifications, so the GUI doesn't need to pull for data.
Then you could create your OS-specific GUI, while I'd do my web based one - and everybody would be happy :)

The most flexible solution would be to create one cross-platform "block-chain server", which only serves as a storage for the block-chain and handles connections.

Any app checks if such server is installed on the system and whether it's running or not. Runs it if it's not started.

This "block-chain server" will have nothing to do with wallets, so no protection is needed.

The client handles all wallet-related stuff and registers a global URI handler.

Any other application, such as a miner, that needs to access block-chain does this easily with no security concerns.

Any application or a browser that wants to send money simply opens the URI, the same way links or magnets are handled. The default "wallet app" pops up a dialog to the user and he either confirms or denies this request.

I like it. Sounds like a good split.

+1

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

I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}

Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.

If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.

I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.

maybe:
client sets a default fee for every transaction and server just checks if currentfee<defaultfee and sends it?

if its bigger it could return and the client could retry with another defaultfee.

Yeah, yeah, yeah... You're smart, we're stupid. We got it.


BTW, Frankenstein is the name of the creator, not the monster, smart ass.

This is how I see it:
 * grab_the_wallet_lock(); - not needed
 * solve_inverted_knapsack_problem_to_select_the_best_coin_subset() - not needed (see below)
 * fee = compute_the_required_transaction_fee() - just take the value from the user interface
 * yesno = ::ThreadSafeAskFee(fee) - useless (always answer 'yes - i'm sure what i set')
 * commit_transaction_and_release_lock(yesno) - this is the only thing you need to do. so you first talk to the wallet, saying that you want to send this money to this address. the wallet does the solve_inverted_knapsack_problem_to_select_the_best_coin_subset and returns you the signed transaction. then the UI app forwards it to the blockchain server.
and then you also need to resend to the blockchain server those transactions that have not been mined yet.
and also there are other things that you need to think about :)
but basically the idea of splitting it into a blockchain/transaction server, a wallet and a native GUI app seems to me the most reasonable to go with :)

An interesting problem, perhaps we could crowdsource a solution.

Oh wait, nobody without a masters in software engineering is qualified to make suggestions on the architecture of the client.

http://www.tomsguide.com/us/video-game-foldit-research-aids-virus-folding,news-12584.html (http://www.tomsguide.com/us/video-game-foldit-research-aids-virus-folding,news-12584.html)

You might be interested to note most of the gamers didn't have degrees in molecular biology.

Interesting link, albeit pretty much content-free. I'm going to have to assume two things:

1) "gamers" were actually CS students on the BSc or MSc track.
2) "gamers" didn't have the attitude "lets fuck big pharma if they give us a chance"

Here we have a crowd developing a revolutionary financial solution and the prevailing attitude is: fuck accountants and the GAAP-horse they rode on. I think I know how that is going to end: they lawyer will tell them that the only words they are allowed to speak are: "Yes, your honor!". It is very much similar to the new drivers who only learn how to drive after they had to stand before the judge.

I haven't worked with anyone from entertainment industry background for many years. But from the past I remember well that there were clear distinction between at least two groups:

A) those who could persuasively discuss the drawbacks and benefits of duo-quaternions and 4-by-4 homogenous matrices.
Z) those who had very twitchy fingers and traded rants: "OpenGL rules and you are paid MSFT shill!" vs. "DirectX rules and you are SGI troll!".

Do you (or any one else here) have an idea or suggestion how the game development community separates wheat like (A) from the chaff like (Z)?

As I understand the problem, in order to separate the wallet/GUI from the block chain you need to draw a line between them.

The wallet has:
    High security
    The macro transaction as defined by the user (number of coins, dst address, maximum tx fee)
    All the valid addresses associated with the signing key
    The signing key
The wallet needs:
    An exact list of the micro transactions required to execute the macro transaction
------------------------------------------------------------------------------------------------------------------------------
The block handler has:
    Internet connectivity
    A list of all addresses in the universe and how many coins are associated with each of them
The block handler needs:
    A signed list of micro transactions to be included into the block chain


So, it seems like the following steps are required to perform a send transaction:

1) User inputs the number of coins, destination address and maximum transaction fee (optionally the addresses to take the coins from)
2) Wallet requests number of coins in each address (from block handler) starting with the oldest until sufficient coins are available to complete transaction
3) Wallet builds micro transaction list, calculates TX fee, and prompts user if calculated fee is too high
4) Wallet sends signed micro transaction list to block handler
5) Block handler validates transactions and reports back to user success/failure. Note that the block handler does this for transactions from the internet anyway.
6) If valid (block chain hasn't reorg'd) transaction is broadcast to world

Does this solve your inversion of control problem? I believe it addresses my security concerns regarding the signing key being attached directly to the internet. There is an issue with the wallet needing to request all coins in all addresses in order to update the current balance. I prefer the extra workload this incurs over having all the wallet addresses resident in the block handler where they could potentially be stolen.

PS a better link http://www.wired.com/medtech/genetics/magazine/17-05/ff_protein?currentPage=all (http://www.wired.com/medtech/genetics/magazine/17-05/ff_protein?currentPage=all)

No, it doesn't. My short example assumed that the "client" maintains the current integrated architecture. If you want to split it between wallet-less "bitcoind" and block-chain-less "bitcoinui" then you have to explicitly specify which protocol you are going to use between the two halves. You cannot just hide behind a row of dashes. It has to be a two-way communication protocol that handles (a) receiving coins (b) sending coins (c) chain extension (d) chain reorganization (e) all other miscellaneous tasks most importantly "getwork" for mining. So far nobody had made any workable proposal. There is some sketch by Genjix & friends: http://bitcoinconsultancy.com/libbitcoin/libbitcoin/

Trivial, hah, I thought the same in the first two weeks of working on this, when I had made some mockups in Qt Designer.  Then reality hit me.

You have to start somewhere uh :) Have many face transplants have you done where the patient was trying to strangle you  :D

Which is also why I'm done bickering about whether Qt was the right choice, why not the zillion other UI libraries, why I chose this specific URL scheme etc. If you have anything to add, you know where the "pull request" button is.

I've implemented the most-requested features and removed the most common annoyances, and the UI as a major concern is now addressed.

Now let's move on to helping Alex Waters with his QA stuff so that we can refactor the core code *with* the assurance of unit tests.

Back in June or so, several projects popped up intending to make secure hardware wallets.  As far as I can tell, there has been absolutely zero progress from any of them, for exactly the reason that 2112 mentions.  Pay special attention to the one I bolded.

This is completely usual in open source. Many times, the reason is simply that people give up, or don't have enough commitment to one project and let it linger. There were also zillions of "user friendly alternative bitcoin UIs" that popped up around when I started coding om bitcoin-qt. Most of those have been abandoned a long time ago.

There is a one-way hardware-wallet: casascius' coin (https://bitcointalk.org/index.php?topic=41892.0) ;)
And I would handle smartphones or even tablets as "like" a hardware-wallet - as they are portable enough. or is there a contrary definition?

Hey John,

I don't know if you've been following my project libbitcoin:

https://bitcointalk.org/index.php?topic=30646.0
https://gitorious.org/libbitcoin/libbitcoin

I've been making good progress.

Anyway I just wanted to say that you should try to make bitcoin-qt as generic as possible wherever you can with replaceable backends. That means in the future you'll have more developers focused around developing one GUI (and pooling effort) rather than many competing clients running in parallel.