I would sell them in smallest lots you can deal with if that makes any sense, that way you get your profit and also don't fall for a scam you also won't end up borking the Bitcoin economy too much either if you sell the coins in batches rather than all at once but I think the volume is a lot bigger now so it may well be that the price won't get affected as much by large trades.

Sage pretty much has the right idea as well, it might be a good thing to diversify in precious metals too so your fiat doesn't immediately lose value the second you cash out.

Please read a few topis on this in this or the Development forum, there's enough arguments for and against this practice already.

SD creates 5000 Satoshi bitdust nowadays by the way.

maybe by validating IF the transaction is a certain size than + specific fee....

just trying to give some basic ideas.

the way i did it is i assumed each transaction is going to have a fee of 0.005

like this

<?php
require_once 'jsonRPCClient.php';
  // Replace with the username and password you set in bitcoin.conf
  $bitcoin = new jsonRPCClient('http:/xxxx:xxxx@xx.xx.xx.xx:8332/');
  print($bitcoin->settxfee(0.005));
 ?>

The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.


Because the fee is related to the amount of data that makes up the transaction and not to the amount of Bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (e.g. as small payments from a mining pool) then fees when sending will be higher than if your activity follows the pattern of conventional consumer or business transactions.

As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.

A transaction will be sent without fees if these conditions are met:

    It is smaller than 10 thousand bytes.
    All outputs are 0.01 BTC or larger.
    Its priority is large enough (see the Technical Info section below)

Otherwise, the reference implementation will round up the transaction size to the nearest thousand bytes and then add a fee of 0.0005 BTC per thousand bytes. Users may override the default 0.0005 BTC/kb fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

Note that a typical transaction is 500 bytes, so the typical transaction fee is 0.0005 BTC, regardless of the number of bitcoins sent.


I hope this helps you

That's a pretty bold claim. Perhaps you should provide some evidence to support your argument quick before you're flamed into oblivion...

Nah, it's almost as simple as it could be.  Try designing one with built in crypto agility and an automatically varying block size limit. 

Actually the "script" system, most of which is crippled anyway, is needlessly complex.  But other than that it's really simple.

Just because something clouds your judgement does not mean it clouds everyone's judgement. Unless you think all the smart folks in the world are going to simply stop being a part of society, I don't think you need to worry. There are people willing to delve into the nitty gritty details and share them with the rest of us in a way we can easily understand.

You use satoshiDICE as an example, but don't you take the chance of "being swindled" out of your money any time you gamble, regardless of where? Aren't you attempting to "swindle" satoshiDICE out of their money by gambling there?

Meh, I think you are just underestimating the power of scamsters in real life and everywhere.  You'd be amazed at how complex scams can run and how many otherwise "normal, intelligent" people fall for them everyday. 

I agree, which is what I'm trying to get madmadmax to understand.

Meaning that anyone who has access to your server now has access to the user's password, and all their bitcoins.  That doesn't sound secure, and doesn't sound like a good idea.  The way https://bclockchain.info/wallet handles it is far more secure (and faster).

I agree.  All that in addition to the serious lack of security.

That will take too much time, I can't speak for 0.8.0 cause i have yet to play with it but anything lower than this will not be able to do. You have to rescan when you switch the wallet.dat, and that takes awhile.


No I am just talking about protecting the wallet.dat file. Honestly this not really good way to do it. But to create a new address, you would have to decrypt the wallet.dat with the password from the person and you would probably have to encrypt the bitcoin.conf so you can use JSON RPC API to create the new address. It is so many working parts that would take a long time, while keeping the connection to the user alive so they can get the address as soon as it is create.

If you don't send the raw password over the network, how are you going to encrypt or decrypt the wallet? Don't you need the actual encryption password to do that?

I see that you "want to have separate wallets all encrypted with the users password"

Wouldn't that require that they send you their password in order to decrypt and use the wallet?  That seems like a significant security flaw.  I'd think it would be better to create a database that contains a user identifier and bitcoin address as a primary key along with a column for the encrypted password.  Then any new bitcoin address can be generated and the private key can then be encrypted on the user side.  Having the bitcoin addresses would allow you to show balances, and any time the user needs/wants to send a transaction, you can supply them with the encrypted password only.  The users client program can decrypt the private key locally and sign the transaction.  That way you never have access to the user's private keys or password.

If on the other hand you plan to send the user the entire encrypted wallet, and have them decrypt it locally (and use it decrypted locally), then there isn't any need to "write an app to shutdown the daemon and replace the wallet.dat file"  Since the user will be using the wallet on their end, you don't need a daemon at all.

So I'm working on a project that will hold bitcoins and of course, security is the most obvious risk/danger.

On advice of the developer we have a specially compiled version of bitcoind (unnecessary RPC calls have been removed, as well as calls that pose a security risk).

Bitcoind runs under a separate user than the php script. SSH/ftp into the server is only possible with keyfiles.

All mysql calls are escaped so injection should (hopefully) be covered.

A cold wallet is being implemented so the majority of funds are off-site.

What other steps should I be keeping in mind? After some advice from a friend I'm worried as well about somehow the database being compromised in some slight way as to affect imperceptible shifts in balances that I would be unable to detect.

I toyed with the idea of every database entry having a hash generated from all the data and the hash being periodically verified against the database to check for manipulation. But is this realistic?

Anyone have any more ideas? Thank you

I bet with them regularly and have never had a problem, a few websites don't change their footer to display the year they were established.

If your trying to create a blockchain.info like site, I highly discourage it cause the reasons blockchain.info is so good is the hybird wallet system, which I don't think you have full grasped the concept of yet from this thread.