My suggestions on how to make a decent client

[RodeoX]

@Gabi - You had it right in the title when you said you had "suggestions". The client is at version 0.5.1. The zero means no complaining, no saying "this SUCKS!!!11!"; IMO.
Having said that, some of your suggestions good ones!

[1714064926]

1714064926

[1714064926]

1714064926

[1714064926]

1714064926

[Gabi]

@Gabi - You had it right in the title when you said you had "suggestions". The client is at version 0.5.1. The zero means no complaining, no saying "this SUCKS!!!11!"; IMO.
Having said that, some of your suggestions good ones!

If no one complains that 0 become and 1 with the client seeing no improvement cause "well no one complained, it's fine"

[netrin]

If seeing one complains with cause, "well fine" that client complained become improvement and no no no, the 0 it's 1

ftfy

[Deafboy]

Another suggestion:
Make full client act as light client until the blockchain is fully downloaded.

And this leads to another suggestion:
Universal server should be made to allow several light clients to connect. Maybe you should talk with devs of electrum about this.
Or even better - allow the full client to act as server for light clients if blockchain is up to date.

Possible GUI improvements:
Icons in 0.5.X client seems not to be in correct size (or has been resized from larger PNG images). It is detail, but it looks terrible.
Also the red/yellow color of connections indicator always looks like there is something wrong even when I have >30 connections opened.

I also think that online wallets are fine, but we should not advice new users to use them.
The danger of online wallets is similar to using credit card online. Trusted wallet provider can change the situation (like PayPal for bitcoins), but we do not want to make the same mistakes over and over again, do we?

[Gabi]

Integrating a thin client in the standard client is a nice idea indeed!

So you can choose if use your blockchain or use it as thin client and connect to a server. Very helpful for new ppl, so they tell you "ok i downloaded the standard client, what now to use my btc?" "Select "thin client" and you can use them right now, then if you want.. -explain blockchain-"

And remove the "oh well now you have to wait 12 hours to download the blockchain... or you can download it from that site but then you will have to run the client with the -rescan parameter... or use a thin client, here, download it here" (and he is like "then why the hell i found that client on the official site...")

[netrin]

Integrating a thin client in the standard client is a nice idea indeed!

So you can choose if use your blockchain or use it as thin client and connect to a server (peer)

If each client has a decoupled blockchain and wallet, then peers can ask each other for address balances (anon shot) and even to submit transactions on their behalf, which might increase anonymity/deniability of transaction origin.

[Gabi]

Even better, nice idea!

[grue]

If I thought that downloading and installing software onto your computer is the way to go then I'd be helping make it better.

I don't. I think 90-something-percent of future Bitcoin users will be using it on an iPad or mobile phone or on their computer in a web browser.

I'm sorry you think 0.5 is worse than 0.4, but you're in the (vocal) minority. Nobody stepped up to support the 0.4 wxWidgets-based GUI, and we've got several people working on the 0.5 Qt-based GUI, so I'm confident switching was the right decision.

I don't think he's complaining about the qt framework. he's complaining about the new layout + useless features added to 0.5. like the overview tab, and csv export

[Raoul Duke]

Well, the csv export isn't that useless. I couldn't find any other way besides exporting to get to the tx ID...

[ThiagoCMC]

Guys,

 A lot of people forget that Bitcoin is a BETA software.
 It is just a embryo!! A baby software.
 Bitcoin 0.4.0 is great...
 Bitcoin 0.5.1 is AWESOME!
 Bitcoin 0.6.0 need a lots of tests BEFORE the final release!
 So, stop crying (sorry if I'm being rude) and start helping!!
 Draw your suggestions in a mock-up software/site...

Best!
Thiago

[justusranvier]

Integrating a thin client in the standard client is a nice idea indeed!

So you can choose if use your blockchain or use it as thin client and connect to a server (peer)

If each client has a decoupled blockchain and wallet, then peers can ask each other for address balances (anon shot) and even to submit transactions on their behalf, which might increase anonymity/deniability of transaction origin.

My LAN at home has three computers on it, two of which have GUIs installed and one of which serves as a headless router/firewall. If you count my smartphone then the network has four computers on it.

From my point of view I would like to see a complete separation of the blockchain tracking/network communication functions from wallet management/user interface. It doesn't really make sense to run more than one copy of the server on a single home LAN but there are three other computers (counting the phone) that might be using clients.

In an ideal world I'd run the server on the headless machine and it would advertise itself via zeroconf/avahi so that any client that was started in that network would automagically who to connect to in order to initiate a transaction.

[gmaxwell]

In an ideal world I'd run the server on the headless machine and it would advertise itself via zeroconf/avahi so that any client that was started in that network would automagically who to connect to in order to initiate a transaction.

Hm— well, different models are possible here.   I'd like a separated GUI and backend because I can run a single trusted backend and not deal with the computationally expensive zero trust stuff on all the other clients I need.   I wouldn't want to use some node just because I heard about it via zeroconf/avahi.

If you're going to discover nodes via zeroconf then you need to be able to operate in a way where you don't trust them. Thats significantly more expensive than being able to trust them.

[justusranvier]

In an ideal world I'd run the server on the headless machine and it would advertise itself via zeroconf/avahi so that any client that was started in that network would automagically who to connect to in order to initiate a transaction.

Hm— well, different models are possible here.   I'd like a separated GUI and backend because I can run a single trusted backend and not deal with the computationally expensive zero trust stuff on all the other clients I need.   I wouldn't want to use some node just because I heard about it via zeroconf/avahi.

If you're going to discover nodes via zeroconf then you need to be able to operate in a way where you don't trust them. Thats significantly more expensive than being able to trust them.

If the client is the one that controls the wallet then it doesn't need to trust the node to do any cryptography, does it? All it needs to do is to have the node forward the transaction to the rest of the network. A node can't tamper with transactions if it lacks access to the private keys, can it?

[netrin]

You need to trust that the node is in fact sending the transactions and not trying to identify you by your address balance requests (though ANY node can and may attempt that).

I'd like to see a simple onion network between nodes without Tor.

[justusranvier]

You need to trust that the node is in fact sending the transactions and not trying to identify you by your address balance requests (though ANY node can and may attempt that).

I'd like to see a simple onion network between nodes without Tor.

In the use case I mentioned a single network administrator controls the computers that run the node and the front end. I guess the risk then would be one of the computers on the same network becoming compromised and using zeroconf to advertise a malicious node?

[netrin]

There are plenty of trust-based services on the LAN. High performance data-stores rarely authenticate and encrypt traffic, but rather assume the network is secure.