Topic: Preparing for wx --> qt switch (Read 6535 times)

Hey John,

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

https://bitcointalksearch.org/topic/libbitcoin-30646
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.

There is a one-way hardware-wallet: casascius' coin
And I would handle smartphones or even tablets as "like" a hardware-wallet - as they are portable enough. or is there a contrary definition?

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.

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.

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 

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.

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/

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

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)?

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

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

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

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.

maybe:
client sets a default fee for every transaction and server just checks if currentfee
if its bigger it could return and the client could retry with another defaultfee.

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.

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

+1

I like it. Sounds like a good split.

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.

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

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.    Anyway, props to the developers for their contributions and for putting up with the criticisms from the community.

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.