Important notice for the users of the server electrum.novit.ro.
One of the disks decided to resign from duty last night, hard-locking the machine (so I guess I wasn't treating it nice enough...). The admins in the datacenter had to take the disk out and reboot the machine. This probably happened when Electrum was updating the database, because the db was full of errors after I resynced the RAID matrix and restarted all services. Right now electrum.novit.ro is rebuilding the database, so don't worry if your balance is zero - the blocks are not up to date at the moment. ETA ~48 hours (yeah, I know...), you should use ecdsa.org for the moment.
Sorry for this! I blame it on the Grinch.
|
|
|
Maybe you could symlink the blockchain(and all files that don't change) to the main data dir.
OP didn't specify if he's using a symlink-capable OS. Even if he is, I'm pretty sure the client won't like the blockchain being updated from another process. Having multiple datadirs seems the best solution, but it will use a lot more disk space.
|
|
|
Yeah and absolutely no deniability. So when the news starts running reports on this massive global cyber attack and all the evidence points to Bank Of America and you have employees and contractors whistle blowing that is going to look great. Even if they don't suffer any civil or criminal charges the negative PR would be in the tens if not hundreds of millions of dollars.
Why would they need to deny anything? They will ride it as the best thing they did since inventing credit cards - they saved the world consumers from the claws of secretive money-laundering illegal drug-consuming tax-evading anarchists! They might even get tax deductions for their heroic efforts. They will also most likely have the approval of law enforcements agencies. "Sorry, ma'am, I know it's hot and noisy in our office, but we're fighting against cyber terrorists, so your money can be safe in our bank." This has happened before (more than once): representatives from antivirus companies break into botnet C&C servers and shut them down. Good for them, the general public and the media say. But in reality, the are illegaly hacking into computers hosted in another country, computers who are sometimes owned by botnet masters or used with permission. Without a court order, most often than not even without informing local law enforcement. The are cyber attackers just like the botnet operators. They are heroes. Question: if I break into a stolen car and I dismantle something so the car is unusable, am I a hero? Or did I just do something illegal? Both? I'd say we shouldn't underestimate the power of FUD/PR. If Bitcoin will die, I think this is where the fatal blow will come from.
|
|
|
If assembled into 8 GPU rigs it would require assembling 2500 to 3000 computers. Who is going to assemble them? Who is going to adminster them? Who is going to construct racks, run the miles of networking cables, and build the power distribution circuits? Who is going to guard them (don't want $7M in computers to walk away)? You need to consider labor costs.
....
The true cost in planning, construction, and execution is likely 3x higher. Still your right it would be possible for a bank or rogue government to execute a non-economic 51% attack.
It doesn't have to be that complicated. You are thinking the adversary will create a dedicated mining facility, but it would be easier for them to use existing infrastructure. Large banks already have tens of thousands of computers. Some of them might be already powerful enough to mine, others can be upgraded with minimal costs - get any local contractor to drop decent GPUs in a few computers at every branch. These are already solved problems, upgrades and fixes are one email away. Administration is already solved, too. Mass deployment of a smart miner (I'm thinking cgminer) who can do everything automatically is simple enough (already existing procedures). A few more GPUs won't make a major impact on the local power grids, so no worries there either. All they need is to run their own pool and write the attack code. Large institutions already have people who could do that, too. I dare say that any top bank can do a 51% attack with minimum hardware investment, plus the human resources cost and extra power consumption. It's not going to be cheap, of course, but nowhere near your calculations.
|
|
|
Also: I suspect your server is not 64 bits.
|
|
|
after moving bitcoin to my server, i get:
bash: ./bitcoind: cannot execute binary file
-rwxr-xr-x 1 btc btc 3356222 12-19 14:52 bitcoind
anybody knows what is the problem?
k.
The binary is not executable in your setup. Run these and paste here the results: file ./bitcoind ldd ./bitcoind
|
|
|
daemon is working... i can talk to it... but is has asked me to make rpcpassword in configuration file... i set it, but what is it? when i will need it? how secure it has to be? Moderately secure if you only access the rpc ports from local. and second question... how to talk to this deamon from PHP? https://en.bitcoin.it/wiki/PHP_developer_introand 3rd (probably it is somewhere already)... how to protect btc files on server (which file - which user - which permission)... i know that i have to keep all the btc out of server and i am going to do it... but i need some BTC ready to spend... and i do not want to loose them until i spend it Run a different container (like LXC, vserver..., NOT process based, like chroot). Firewall it well. Only allow rpc connections from the php machine. Run the bitcoind daemon as user bitcoin. This will protect you against vulnerabilities in bitcoind which could compromise your server and against vulnerabilities in your other applications which might compromise your wallet. If will NOT protect you against vulnerabilities in your bitcoin webapp! If you don't need to do payments immediately as they are generated on the webapp, I would suggest you keep the bitcoin wallet and the app separate. The webapp should send an email to a human, who will review the transaction and manually approve it.
|
|
|
0.5.1 works ok for me. Compiled from source, Ubuntu Linux 11.04, 64 bit.
|
|
|
You can't choose the sending address using the standard client. You can only generate a new receiving address (Receive Coins tab). The Address book is just as the name says - a way of attaching labels to addresses.
|
|
|
maybe i do have to do something else than just type bitcoind in my console?
Did you type 'bitcoind' or './bitcoind' ? If the binary's location is not in your path, the first will not work, not even if you're in the correct directory. Make sure you do this: * open a console, then: $ cd /path/where/bitcoind/is/located $ ./bitcoind You can also copy the bitcoind binary in a standard path directory, I recommend /usr/local/bin, you will need to do it as root, so: $ sudo cp ./bitcoind /usr/local/bin After that, running 'bitcoind' from any path should work ok.
|
|
|
Please don't download v0.2, it does not include the final v0.34 of Electrum. v0.21 will be uploaded asap. Sorry for this.
|
|
|
Is all that's needed to backup a wallet a copy of the wallet.dat file? And to restore it to a new machine do you just install bitcoin again and copy the wallet.dat back?
Yes. Also, what would happen if you put the same wallet.dat on 2 machines at once? (Those questions were probably answered elsewhere but I never have any luck finding answers)
I didn't try to do it. I think it's most likely the client (and you) will get confused because the history and balance will change if the other copy spends some coins. After the first outgoing transaction, there will also be new private keys for that copy of the wallet, so the two wallets will no longer be identical and it will be difficult to merge them again. Better to avoid doing it.
|
|
|
I have received the bounty from OP. Thank you!
|
|
|
PM'ed my address. I am sorry, I don't know Eclipse that well, I think there is a Maven plugin for it, but not much more.
|
|
|
|