EDIT: Caveat emptor on Ubuntu distributions from 14.10 and forward - init was chosen over upstart and is being phased in the future. I don't know when that will be done nor what impact it will have on upstart scripts.
Extract from the page RentFree refers to; note that it assumes that you have created a user called bitcoinuser for the sake of security:
There's an upstart script for Ubuntu in the Bitcoin Core source tree. Using that is the most correct way.
However, I just login as the user account I want to run Bitcoin Core daemon, start a terminal (if I'm in the GUI), and run the following command to edit my crontab:
Then I add the following line:
@reboot bitcoind -daemon
Save the file ...
It's definitely not against the law. It might be breaking the terms of service (ToS) but there's really no reason why any dedicated server hosting provider wouldn't allow you to max out the CPU. I wouldn't do business with them if they limited that. However, you need to read your hosting provider's ToS. They might forbid certain applications like IRC servers,...
The first thing Bitcoin-QT does is verify that the data stored on the disk is valid. Among other checks this includes verifying the last 288 blocks (the past two days in expectation). This task involves a large number of signature checks and will take some time to complete. Only after the startup checks have successfully completed will the connections to the ...
We have publicly stated that we don't expect the code to be made publicly available in less than two months and that we would consider it a failure if we didn't make the code publicly available before the end of the year.
Right now, we've received a lot of public feedback and are trying to make changes responsive to that feedback. See this github issue for ...
Once you've installed bitcoind, you should create a configuration file (stored in ~/.bitcoin/bitcoin.conf) containing at least an RPC username and password, and then you just run bitcoind to start the server.
Edited answer after Tom van der Woerdt's comment about using an untrusted repo
sudo apt-get update
sudo apt-get install -y git-core build-essential libssl-dev libboost-all-dev libdb5.1-dev libdb5.1++-dev libgtk2.0-dev
git clone https://github.com/bitcoin/bitcoin.git
make -f makefile.unix ...
Multisig and singlesig wallets use the same flow. A Tx proposal need to be created in singlesig wallets also. Copay syncronize across devices, so you can have a non-signing copayers in a 1-1 wallet that submit proposals, for later approval.
The flow is:
create => publish => sign => broadcast.
You can check the official client https://github.com/bitpay/...
I have a mac that I never use, would storing my bitcoins on a wallet on that laptop and then only connecting it to the internet when I am ready to transfer money be safe? Is there any reason not to do this?
Your laptop needs to catch up every time you want to make a transaction, which is not good.
The ideal solution would be Bitcoin Armory, which is ...
Well, I would run the bitcoind in a VM, and regularly snapshot it. If it fails, rollback the snapshot and reboot. Back online in < 10 min, assuming frequent backups and you start working right away. Not sure if this is the use case you're asking about, but that's what I'd do for max uptime.
If you're mining in a pool, bitcoind doesn't even have anything to do with the system. It doesn't need to be running, it doesn't even need to exist on your hard drive. The remote pool does that for you.
This guide will set up everything you need on a single machine.
Let's get started by setting up the environment:
sudo apt-get update
sudo apt-get install build-essential
sudo apt-get install automake gcc
sudo apt-get install libevent-dev libmemcached-dev libcurl4-openssl-dev zlib1g-dev libjansson-dev curl memcached
Depending on your distro some of these ...
If you have SSH access on both machines you can simply create an SSH tunnel from machine B to A and forward port 8332 through it. That way the behavior is just like it would be if bitcoind were installed on both machines, the traffic between the two machines is encrypted with SSH and bitcoind does only have to listen to the loopback interface and would not ...
I think you are slightly misunderstanding some things, but basically you are already on the right path.
I signed up for a bitcoin wallet (coinbase) where I am given an id.
When you want to manage your wallet (send and receive Bitcoin, create new wallets etc.) on your local machine, that’s a must. On a side-note: in ...
I would highly recommend using Ubuntu Server for this, as long as you know what you are doing without a GUI. Not having a GUI at all means smaller OS size and much less OS tasks. This translates into more power savings. If you are using graphics cards, a non-GUI OS will improve your mining performance. If using an ASIC/etc. you probably will not see ...
There is no central authority that "determines the equations". Instead, every Bitcoin node (whether run by a big mining operation or your computer in your basement) is responsible for verifying all the work done by others. Every Bitcoin node knows and agrees upon the rules for determining what the difficulty level should be.
The precautions you can take from an architerual point of view would be as follows:
The database storing the private keys or the seeds in case of HD wallets should be running on a separate instance and only accessible via the application server(AWS allows lots of configuration you can make in the virtual private cloud i.e. VPC to accomplish this).
The keys ...
There is no need to resolve anything - some miners create arbitrary versions to attempt to speed up the mining process, as it gives them an additional field in the block block header to alter without having to recalculate the merkle root and other fields.
This is harmless, provided they aren't producing invalid blocks for version 2, in which case the block ...
I understand the initial logic to put the bitcoind & wallets onto a separate server, but think about it... if your webserver becomes compromised, then it doesn't matter where your bitcoind is.. it is also compromised.
Example; Bitcoind is on server A, webserver is on server B.
webserver B sends requests -> to bitcoind server A . . replies -> back ...
Is it possible that nodes, connected to my vServer A, identify the servers purpose from the transactions and try to attack him?
Yes, if they can see enough of the network, they can figure out whether you are originating a transaction or just passing it on. It's easier to figure out you're running RPC through a port scan, though.
There are ways to prevent ...
Bitcoin wallet development usually involves communicating with either bitcoind through HTTP JSON RPC, or otherwise with other Bitcoin Clients through the Bitcoin Protocol over TCP. On top of that, there are the usual requirements of authenticating users, securing data and so forth. All of those security issues are not Bitcoin specific, thus I think this ...
A long time ago I read about using amazon cloud instances when the value vs. effort made it profitable to mine with them, but that was before GPU-mining took over.
To be competitive today a service provider would have to employ ASICs. There would also be some economical overhead of providing the customer service, instead of just mining. Strict bitcoin ...
Use Bitcoin Core in server mode and use it's notification functions:
blocknotify = curl\yoururl
walletnotify = curl\yoururl
Set them up to make a call to your app.
This way, you won't be making expensive RPC calls to Bitcoin Core. You will only be receiving notifications for operations that Bitcoin Core itself already is making. So you won't ...
I had a similar problem - it turned out that Bitcoin was running out of memory. (This happened when I was using one of DigitalOcean's 512MB VPS's.)
Here's what you can do to check if this is the problem:
Run the command watch free -m
You'll see something like this:
total used free shared buffers cached