Talk:QBitcoin

Skip IRC bootstrap?

As said in the earlier stages of bitcoin IRC is only a temporary solution for bootstrapping. Since I do not feel like implementing something that will be dropped soon after, I'd guess I should just skip the IRC bootstrap part and implement various other way to harvest initial nodes. I'm thinking of storing known peers in a database, and keeping those that stay most of the time (ie, got a fixed ip and provide bitcoin service). Any comment? MagicalTux 07:32, 18 December 2010 (GMT)

If the file is large and releases are often, then there should be at least a few bootstrap clients in the file that work. Genjix 03:04, 24 December 2010 (GMT)

Even if not often, some nodes are probably going to stay for years (the nodelist will start with the most long-established nodes). Once one node has been reached, things are easy MagicalTux 03:17, 24 December 2010 (GMT)

Initial welcome/login screen

Upon starting the GUI, the user should initially be prompted to either:

• Login to a local/remote RPC core, or
• Create a new local/standalone core

If a local core is detected, (A) should be default. Otherwise (B). The user should have the option to automatically choose the same by default at future launches. Ideally, users should be able to connect to and interact with multiple cores from the same GUI.

Preferrable if it silently selects a local core, but is configurable to use a remote one. Genjix 23:12, 12 January 2011 (GMT)

I disagree. A pre-configured "Login" dialog (with checked "automatically log me in") that the user clicks once the first time they run it shouldn't be a nuance. Luke-jr 01:08, 13 January 2011 (GMT)

Currency Settings

Users should have the option to display their choice (single or multiple) of currencies in the window: Fixed currencies:

• Decimal BitCoin (BTC) -- DEFAULT
• Milli-BitCoin (mBTC)
• Micro-BitCoin (μBTC)
• Mill-TonalBitCoin (ᵐTBC)
• TonalBitCoin (TBC)
• TonalBitCoin-bong (TBCᵇ)
• Custom (Multiply/offset)

Exchange currencies:

• USD/EUR/Gold equivalent via MtGox/Market/Central/etc APIs

Separate core from transaction generation

Transactions should be generated/signed with a library, leaving the core to handle only the p2p network.

Suggestions

Add this article to the Software category. User:sgornick 06:32 19 February 2011 (GMT)

I've had various ideas for improvements for improving Bitcoin, but because I haven't written them down I've forgotten most of them. I'll try to keep a list here of ideas:

• Show small denominations of bitcoins using SI-notation. i.e 0.001 BTC = 1 mBTC, 100000 BTC = 0.1 GBTC
• Do not have accounts. Instead allow more flexible tree based method of organising addresses with ability to tag them in groups or categories.
• Basic libbitcoin so others can make clients for gtk, KDE ...
• Ability to generate at lower speeds
• Same one column for transaction amounts. Money sent is like -10 BTC and the row's background is highlighted red. Money received, the row is highlighed green and shown as +10 BTC. Genjix 17:35, 24 December 2010 (GMT)

Ok let's see...

• SI denomination: mostly cosmetic, why not. The difficult part will be to choose the right unit
• Accounts-in-a-tree, that sounds interesting :) I was already planning to give one "account" the ability to hold more than one address so returns can be kept together
• This one is not going to get easy since I'm using Qt net libs. The core component do not use QtGui so it can be easily connected to a gtk UI, but the networking will still be done by Qt
• The client itself will not include any generator, generation will be handled by external binaries via a specific API. Still I'll include a CPU miner in the distro, giving it the ability to generate at lower speeds should be possible (result may vary depending on OS)
• This one is already planned in the UI :p

MagicalTux 03:17, 24 December 2010 (GMT)

• SI denominations are already a standard. So you don't need to pick a unit.
• Maybe you could have 2 components- core network with API as a library, and thin client GUI on top.
• Not including a generator in the application is a great idea.

Genjix 17:35, 24 December 2010 (GMT)

• What I mean is, let's say I have 4740000 BTC, should I display 4.74 MBTC or 4740 kBTC ? This kind of things...
• The core component and the GUI are already separated, however the core component uses Qt for non-gui stuff (networking, etc... Qt can do many things beside GUI)
• I've read some documentation about that. I'm considering allowing the generator to show a configuration panel (or configuration api) to configure generator settings, but that's for later ;)

MagicalTux 18:34, 24 December 2010 (GMT)

Another idea. The main list view should look something like this:

Status	Date	Description	Credit	Balance
Processing (2)	20 Dec 10	hello jon	-10	170
Confirmed (10)	18 Dec 10	bls djdsksd sdls	+20	180

The date should be in that format, as it's confusing for non-Americans as they write the date wrong as MM/DD/YY instead of the usual DD/MM/YY.

Also here's a link to a list of SI prefixes. People find it confusing dealing with large numbers, which is why SI prefixes exist. It's easier to handle numbers in the 0-100 range than the 10000000000-100000000000 range.

Another idea would be that it'd be nice to associate bitcoin addresses with people's names like with email. So if I wanted to send money to my friend John, then I just click his name. When you send money in Bitcoin, there's a button to open the address book. It should already be integrated in that send dialog- having to make another click to reach the address book is off putting for the user and discourages them to use it. If it was already integrated as a list view in that dialog then it'd be easy to quickly select your friends, type in a number and hit send. Instead of type number, click address book, select friend, click OK, click OK. Genjix 17:35, 24 December 2010 (GMT)

I like the idea of allowing the user to have an address book of contacts (other than his own addresses). I don't like however that users will send bitcoins to the same address for someone each time, but this can be solved the following way:

• User decides to send 100 BTC to contact X
• The client sends a request on the P2P network asing for X (by providing his address), and also including a freshly generated public key
  • Case 1: X's client is running, it receives the P2P request and signs back a reply including a different (freshly generated) address and broadcasts it back on the network after encrypting it (ECIES) with the provided public key
  • Case 2: X's client is not running, the transaction is sent as-is on the blockchain after a few minutes (less anonymous)

This is still as secure (nobody can provide a different address since it is signed, and the reply cannot be understood, so it cannot be linked to the resulting transaction) and would allow keeping fixed addresses without having each transaction sent to the same address. Of course the discovery packet will not be included in the chain, and clients would have to forget those after ~24 hours

MagicalTux 18:34, 24 December 2010 (GMT)

Ah, good point. That was a bad idea. Your idea while feasible sounds waayyyy complex (for the beginning :p)... I'll keep adding more points here as I remember. Will you be using a private git repo that you'll share with me to spy on you? I'm curious how Bitcoin works internally.

According to this thread, it's possible to share a wallet between many parties, so that permission is required to use it. So in my poker software, we could have several independent servers who own all the players money. Cashing out and adding money to table requires permission from all 8 holders of that wallet. Do you think something like this could be possible in your client? =) Genjix 23:20, 24 December 2010 (GMT)

Why not drop the JSON API? If you have a small core which supports basic commands, and the client is a wrapper on top then if someone wants to make the JSON API then they can program their own intermediate layer. Or use system() calls. Genjix 23:25, 24 December 2010 (GMT)