So when will tapatalk arrive?

This is why most of AV detects miners as threat:
http://img851.imageshack.us/img851/9199/combofixm.jpg
http://img233.imageshack.us/img233/7248/malwaremal.jpg
It is all because creators of viruses are so lazy that they don't take source code of miner and use it in virus but they copy binary files from creator of miner and write only starter (something like GUIMiner). So viruses use original files of miners so AV threat them also as virus!

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.

One thing which should be change before merge! Progressbar which inform about sync process should be like in Bitcoin Wallet for Android. This mean that 0% is than, when we run client and it is unsynchronized. Now it shows 99% after start and it not changing until full synchronization. This is not functional if not inform about progress.

Rather http://dot-bit.org/Main_Page

Idea of no wallet bitcoind is stupid in a few ways:
- how to make it useful for bitcoin exchange or bitcoin bank? Coins should be on server side, not client, because we can't ensure that user that want sell 1000BTC realy have them!
- if it would came true in future there will be viruses that would stole money in this way.

And I was talking about my idea of multiwallet server and how to solve this 2 problems. Because there is no sense to start develop something that isn't possible to finish with full functionality. Discussion about no-wallet, or rather about light client, that don't have blockchain are taken in others topics.

A few days ago I was thinking what we can do to make bitcoind safer for „banks” or exchange and than I came up with idea of multiwallet bitcoind.

To access to wallet by JSON RPC we must to predefine rpcuser and password. Also to secure wallet we must start bitcoind on separate server than web interface, moreover we must connect to it only by connection like VPN. In near future bitcoind will also have possibility to encrypt wallet by password known only to owner.

But what about accessing to bitcoind by JSON RPC in this way:
- rpcuser defines which wallet file to select (ex. for user “zwierzak” we select “wallet_zwierzak.dat”),
- password isn't written in any database, because verification of user is successful decryption of wallet.
In this way you can have bitcoind on the same server on which you have web interface (not recommended) and stole password for all users accounts would be much harder than stole 1 global user password or get access to separated server.

So advantages:
- every user is responsible of safety of his wallet file,
- we could allow user to download their wallets to hard disk if they want (every user have separate encrypted wallet) and insert it into bitcoin client
- easier to make sure that crackers can stole only part of bitcoins

We must take care about:
- make sure that user use hard password (libcrack)
- username can contain only some characters (regexp: “[A-Za-z0-9\-_]”) to not allow to write something like “../../../etc/passwd”

But this makes 2 new problems:
- if user lost his password then it will be our fault that he lost his savings, because he can't decrypt his wallet
- exchange will not be in realtime, because if you use only one wallet and 1 address per user you calculate balance on your own. Outgoing money you can sign from everyone private key in wallet. But if you separate wallets that after transaction on site you need to transfer coins from one account to another. But this take time to conform transaction.

What do you think about it and will you be interested in this modification of bitcoind? Also do you have any idea how to solve this 2 problems? Or maybe you think that problems are somewhere else?

And what about noSQL databases? Everyone says that they are faster and more scalable than SQL. Moreover MongoDB have interface in JSON, so it fits with default bitcoind interface.

Report to github, not us. We can't do anything with this.

So with this in future I can replace bitcoind+JSON or this is just API for bitcoind?

Hmmm, I have no idea, why sometimes Knotify accepts longer messages. Here are some examples of receiving notify:
http://img708.imageshack.us/img708/6855/bitcoinqt4.png
http://img59.imageshack.us/img59/6594/bitcoinqt5.png

What about qconf? Project from Psi developers.

If you're interested in good example of using CMake with bitcoin sources you can look at sources of rpcminer. It have fork of Bitcoin with CMake.

Mingw is generating libraries for Windows, so you can use without problem from VS in mingw or from mingw in VS.

Did you try to build using just mingw or cygwin instead of MS VS?

NO! No autoconf! It is better to use cmake. Like all KDE or rpcminer is using. I had in future plan to take care about it so you can assign me this task. Additionally QtCreator also support it.

The last screenshot is standard information from your program. I just rewrite all tray->showMessage to my Notification::instance->notify. For now I have biggest problems with this icons. Temporary I have hardcoded them, but in future they need to be get from system directories.

About replacing all QMessageBox into notify, I also think that it isn't good idea. There are sometimes such situations when user must know that program want answer from him. But many messages can be done my path. For example information about changing status of transaction (from unknown to confirmed).

Hi,

I made some changes in BitCoin-Qt to support FreeDesktop Notifications (like KNotify in KDE4, libnotify in Gnome or osd-notify in Ubuntu). I think that they are a lot better then standard Qt messages and they're great integrating with system. If you don't read them now they will be stored for later (in KDE4). Only dependency is Qt-DBus, so we don't need in system kdelibs or libnotify. If your system don't support FreeDesktop Notify (you don't have daemon or you are using Windows) it will use at first Qt Tray messages and than QMessageBox.

Known issues:
- text is limited to 105 characters (probably limit in KNotify), so I need to made some possibility to read whole message,
- icons are hardcoded because DBus can't send icons' objects, it's require icon's path, which don't exists when we don't have installed program or we use Qt resources (they are inside binary file). I used Oxygen icons, but in future I will patch it to get icons from default system theme

Future:
- replace QMessageBox with FreeDesktop Notifications, you can add actions to notify, so they can replace QMessageBox in 100%, problem are asynchronous answers

Some screenshots:
http://img199.imageshack.us/img199/8586/bitcoinqt1.png
http://img850.imageshack.us/img850/2773/bitcoinqt2.png
http://img29.imageshack.us/img29/905/bitcoinqt3.png

If you're interested in my fork that go ahead and download it form my GitHub:
https://github.com/zwierzak/bitcoin-qt

When I finish my modification I'm going to push this changes to official repository of BitCoin-Qt, but not now. I must repair most annoying issues. Also I found some crashes in original program, which I will try to fix.

To encourage me to continue my work don't affraid to send some tips to my address:
1L7AeokogyuXGmUrx9SRTNhRPzYcmmghdo

Disconnect BIOS battery and every source of power for about 5 minuts. After this time insert again battery, connect to power and try to start. If this doesn't work that motherboard is trashed.

Here is some more info about this 3 beeps:
http://www.bioscentral.com/beepcodes/amibeep.htm#
3 short - Base 64K memory failure - A memory failure has occurred in the first 64K of RAM.  The RAM IC is probably bad

Try start it with other RAM.

Fuuuuu, it is 5 post and 4 hour rule, not 5 posts or 4 hour! I read this wrong at first time.

I made some changes to Bitcoin-Qt project and it is hard for me to notify about them creator. It would be nice to establish some cooperation on this project.