Bitcoin Forum
April 16, 2014, 08:44:49 AM *
News: ♦♦ A bug in OpenSSL, used by Bitcoin-Qt/Bitcoin Core, could allow your bitcoins to be stolen. Immediately updating Bitcoin Core to 0.9.1 is required in some cases, especially if you're using 0.9.0. Download. More info.
The same bug also affected the forum. Changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 [All]
  Print  
Author Topic: Preparing for wx --> qt switch  (Read 3886 times)
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
September 16, 2011, 03:49:34 PM
 #1

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.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397637889
Hero Member
*
Offline Offline

Posts: 1397637889

View Profile Personal Message (Offline)

Ignore
1397637889
Reply with quote  #2

1397637889
Report to moderator
1397637889
Hero Member
*
Offline Offline

Posts: 1397637889

View Profile Personal Message (Offline)

Ignore
1397637889
Reply with quote  #2

1397637889
Report to moderator
Remember remember the 5th of November
Hero Member
*****
Offline Offline

Activity: 882

Remember me


View Profile

Ignore
September 16, 2011, 04:23:12 PM
 #2

Can you provide a screenshot for a reference?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile

Ignore
September 16, 2011, 04:27:38 PM
 #3

  • Cannot act as a rpc client (ok with me, we'll still compile/ship a headless bitcoind)

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)

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
nelisky
Hero Member
*****
Offline Offline

Activity: 1218


View Profile

Ignore
September 16, 2011, 04:28:58 PM
 #4


  • Cannot act as a rpc client (ok with me, we'll still compile/ship a headless bitcoind)

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* Smiley

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...

we measure long periods of time in bitcoin blocks, and short ones in vodka tonics
DividendRippler  | DICEonCRACK | The Amazing Anonymous Bitcoin Lottery
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
September 16, 2011, 05:07:21 PM
 #5

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.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
nelisky
Hero Member
*****
Offline Offline

Activity: 1218


View Profile

Ignore
September 16, 2011, 06:23:12 PM
 #6

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

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.


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

That's more than fair Smiley 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 Smiley

we measure long periods of time in bitcoin blocks, and short ones in vodka tonics
DividendRippler  | DICEonCRACK | The Amazing Anonymous Bitcoin Lottery
nibor
Sr. Member
****
Offline Offline

Activity: 343


View Profile

Ignore
September 16, 2011, 07:58:37 PM
 #7

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

Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
September 16, 2011, 09:56:38 PM
 #8

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

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?



Will I see you in Amsterdam?
  http://bitcoin2014.com/
btcbaby
Member
**
Offline Offline

Activity: 87



View Profile WWW

Ignore
September 16, 2011, 11:33:59 PM
 #9

QT is an awesome platform, good move.

https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.btclog.com%2Fuploads%2FFileUpload%2Fe6%2F9cc97eb4c91db1ec5fb30ca35f0da8.png&t=539&c=hRLPnhiorUy_rA
Write an excellent post on btc::log and you just might win 1BTC in our daily giveaway.
btc::log is the professionally managed and community moderated Bitcoin Forum
ThiagoCMC
Staff
Hero Member
*****
Offline Offline

Activity: 980


฿itcoin: Currency of Resistance!


View Profile WWW

Ignore
September 17, 2011, 06:38:27 AM
 #10

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... Huh

Thanks!
Thiago

* Bitfication.com! Turn your fiat, into bits!
nibor
Sr. Member
****
Offline Offline

Activity: 343


View Profile

Ignore
September 17, 2011, 11:13:56 AM
 #11

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

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?




So the integers will be:
40000
41000
42000
50000

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

zwierzak
Newbie
*
Offline Offline

Activity: 24



View Profile WWW

Ignore
September 17, 2011, 11:23:20 AM
 #12

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... Huh
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.
ThiagoCMC
Staff
Hero Member
*****
Offline Offline

Activity: 980


฿itcoin: Currency of Resistance!


View Profile WWW

Ignore
September 17, 2011, 06:45:15 PM
 #13

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... Huh
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/

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

* Bitfication.com! Turn your fiat, into bits!
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 630

No Maps for These Territories


View Profile

Ignore
September 18, 2011, 11:34:46 AM
 #14

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

Quote
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!).
Thanks! Smiley

Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
error
Sr. Member
****
Offline Offline

Activity: 462



View Profile

Ignore
September 18, 2011, 12:21:08 PM
 #15

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
justusranvier
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW

Ignore
September 18, 2011, 04:53:59 PM
 #16

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.
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.

davux
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW

Ignore
September 20, 2011, 09:14:47 PM
 #17

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.

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 20, 2011, 09:41:06 PM
 #18

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.
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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 20, 2011, 10:32:04 PM
 #19

... Such solution would have a number of advantages.

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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
September 20, 2011, 11:47:49 PM
 #20

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Luke-Jr
Hero Member
*****
expert
Offline Offline

Activity: 1204



View Profile

Ignore
September 21, 2011, 12:15:34 AM
 #21

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.

BTW, I don't like QT... It is a ugly toolkit... GTK3 is much nicer... But, I appreciate the effort!!
Qt supports GTK2 right now, at least. I expect it will support GTK3 soon.


Luke-Jr
Hero Member
*****
expert
Offline Offline

Activity: 1204



View Profile

Ignore
September 21, 2011, 12:16:12 AM
 #22

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.
Speaking as a non-developer user I would love to see a complete separation between the two.
You can already run bitcoind+Spesmilo

wumpus
Hero Member
*****
qt
Offline Offline

Activity: 630

No Maps for These Territories


View Profile

Ignore
September 21, 2011, 06:23:12 AM
 #23

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.
This has been fixed, you can provide USE_UPNP=XXX to the qmake script (see the qt readme).

Quote
It also adds an implementation of bitcoin: URIs that is not compatible with the existing established/in-use standard.
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)

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.
+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
Quote
I am all in favor of UI / backend split, but see no advantage in making main UI browser-based.
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).

You can already run bitcoind+Spesmilo
Yes, I recommended Spesmilo to the people that want RPC client support in bitcoin-qt.

Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 21, 2011, 07:24:11 AM
 #24

Wow, the URI topic has surfaced again Smiley

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 Smiley

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

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
AlexWaters
Member
**
Offline Offline

Activity: 66


CoinApex.com | Twitter: @xH2Os


View Profile

Ignore
September 21, 2011, 09:32:36 AM
 #25

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.

CoinApex.com
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 09:50:31 AM
 #26

IMO the best GUI would be browser-based
... Such solution would have a number of advantages.

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

Quote
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.
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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 21, 2011, 10:04:19 AM
 #27

- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI

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

- easy to setup remote access to the GUI

When do you need it and what about security implications?

- the ultimate platform independence (no wx, no other qt will give you that)

- the ultimate browser type and version dependence.

Slower response times don't matter in this kind of application.

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

You can limit the GUI to accept connections only from localhost.

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

Debugging of HTTP/JS apps is easy.

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...


BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 10:16:17 AM
 #28

- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI

This is solved by writing a native, not a browser GUI.
And then develop each platform independently?

Quote
- easy to setup remote access to the GUI
When do you need it and what about security implications?
Oh. Just give me such option and let me worry about my security.
I really don't see it as a problem.

Quote
- the ultimate platform independence (no wx, no other qt will give you that)
- the ultimate browser type and version dependence.
No. It's 2011. You can easily make HTML/JS app that works fine with every modern browser.


Quote
Slower response times matter in any kind of application. They affect subconscious feelings of the users - how they feel about the application.
Sounds like you are a real expert in this domain - I'm not going to argue here. Smiley

Quote
You can limit the GUI to accept connections only from localhost.
...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? It will be accepted because it will come from localhost.
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?


Quote
Debugging of HTTP/JS apps is easy.

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...
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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
error
Sr. Member
****
Offline Offline

Activity: 462



View Profile

Ignore
September 21, 2011, 10:19:44 AM
 #29

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

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...
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. Smiley

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 10:23:42 AM
 #30

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

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...
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. Smiley
uTorrent's WebUI works fine with IE as well.

I didn't miss the sarcasm - I just followed it Smiley

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 21, 2011, 10:29:10 AM
 #31

And then develop each platform independently?

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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
Cryptoman
Hero Member
*****
Offline Offline

Activity: 726



View Profile

Ignore
September 21, 2011, 03:22:40 PM
 #32

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

"A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history." --Gandhi
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 04:23:53 PM
 #33

And then develop each platform independently?
The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.
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 Smiley

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 21, 2011, 05:33:26 PM
 #34


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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 05:41:41 PM
 #35


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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
flower1024
Hero Member
*****
Offline Offline

Activity: 770


luck is just a share away


View Profile WWW

Ignore
September 21, 2011, 05:42:49 PM
 #36

+1

Cheesy BitSource.org Buy, Sell and Trade Bitcoins and Litecoins Easily! http://BitSource.org/ Wink
***Premier Exchange - VISA/Mastercard Accepted Soon. Get Trading Today!***
Luke-Jr
Hero Member
*****
expert
Offline Offline

Activity: 1204



View Profile

Ignore
September 21, 2011, 05:59:25 PM
 #37

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

2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
September 21, 2011, 06:39:00 PM
 #38

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
flower1024
Hero Member
*****
Offline Offline

Activity: 770


luck is just a share away


View Profile WWW

Ignore
September 21, 2011, 06:46:38 PM
 #39

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.

Cheesy BitSource.org Buy, Sell and Trade Bitcoins and Litecoins Easily! http://BitSource.org/ Wink
***Premier Exchange - VISA/Mastercard Accepted Soon. Get Trading Today!***
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW

Ignore
September 21, 2011, 06:48:21 PM
 #40

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.

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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
piotr_n
Hero Member
*****
Offline Offline

Activity: 938



View Profile

Ignore
September 21, 2011, 06:55:48 PM
 #41

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);
}
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 Smiley
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 Smiley

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile

Ignore
September 21, 2011, 11:10:03 PM
 #42

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.

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.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
September 22, 2011, 03:02:16 AM
 #43

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

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile

Ignore
September 22, 2011, 03:51:33 AM
 #44

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

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
2112
Hero Member
*****
Offline Offline

Activity: 826



View Profile

Ignore
September 22, 2011, 05:41:48 AM
 #45

Does this solve your inversion of control problem?
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/

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 630

No Maps for These Territories


View Profile

Ignore
September 22, 2011, 05:46:24 AM
 #46

The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.
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.

I think John Smith did a feat of software engineering comparable to doing a successful face ansplant on a Frankenstein.
You have to start somewhere uh Smiley Have many face transplants have you done where the patient was trying to strangle you  Cheesy

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.

Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
kjj
Hero Member
*****
Offline Offline

Activity: 1022


Bitcoin Foundation - Lifetime Member


View Profile

Ignore
September 22, 2011, 01:45:42 PM
 #47

Does this solve your inversion of control problem?
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/

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 630

No Maps for These Territories


View Profile

Ignore
September 23, 2011, 06:44:28 AM
 #48

As far as I can tell, there has been absolutely zero progress from any of them, for exactly the reason that 2112 mentions. 
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.

Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
vv01f
Sr. Member
****
Offline Offline

Activity: 293


View Profile

Ignore
September 23, 2011, 07:59:31 AM
 #49

Back in June or so, several projects [..] intending to make secure hardware wallets.  [..]there has been absolutely zero progress from any of them[..]
There is a one-way hardware-wallet: casascius' coin Wink
And I would handle smartphones or even tablets as "like" a hardware-wallet - as they are portable enough. or is there a contrary definition?

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb or litecoin LWNJrWfAMiNWvqppbtSXfSu5ygzhQUFMfH
a good European exchange: bitcoin.de (ref-link)
genjix
Hero Member
*****
expert
Offline Offline

Activity: 1064


View Profile

Ignore
September 23, 2011, 09:11:40 PM
 #50

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.

trifecta of a new world: economy, technology and industry | Freenode IRC #darkwallet
Pages: 1 2 3 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!