I was having the same problem and just managed to fix it now.
Since the file bitcoin.conf does not exist inside ~/.bitcoin, Just create one.
Here's what did:
Enter letter 'a' (to edit the file). Then type:
Press the ESC key, and press ZZ to exit vi
Apparently the password that bitcoind ...
By default the RPC interface is only exposed to localhost (127.0.0.1 and ::1), not to the world. In that setting, you need an RPC password only to protect against untrusted local users on your system (unless you're somehow tunneling the RPC port 8332 out).
That said, why do you have an rpcpassword at all? If you're only going to use bitcoin-cli for example ...
You are not sending with public key.
You broadcast the transaction message that is signed with private key that only the owner of the coins has. (you can consider signing to be analogous to encrypting in the sense of the question)
Public key that everybody knows can verify this message (verifying can be considered analogous to decrypting here). If the ...
The RPC interface is not exposed to anything except localhost by default. So other people on your network, nor people on the internet, can access it unless you have explicitly enabled outside access using rpcbind=<ip> and rpcallowip=<ip>. So even using an insecure rpcpassword should be safe. Furthermore, it is completely useless if you don't also ...
You don't need to grant someone access to the entire machine to be able to use bitcoin-cli. You can provision credentials using the rpcauth parameter in bitcoin.conf (it may be defined multiple times for multiple username/password combinations), and whitelist their IP address for the port you are running the bitcoin RPC on.
They can then use a local bitcoin-...
So in Bitcoind you can define authentication via an rpc interface (remote procedure call). In the config file of Bitcoind which is usually located in ~/.bitcoin/bitcoin.conf you can set the values for
Obviously you should select other values than the ones in this answer / question. You ...
I suggest you don't use rpcuser and password if you don't need to. If you don't set them, Bitcoin Core will use a cookie in your .bitcoin directory as a mean to identify you.
Besides rpcuser and rpcpassword are deprecated now, you're supposed to use this python script to generate a password and copy the output in your config file like this : rpcauth=[user]:[...
I chatted to Wladimir about this. He hasn't switched to a new key, he's just using a separate key to sign binary releases.
Additionally, he has signed the new key with the old key, so there's an audit path.
A closer look at their API page, you will find LakeBTC has provided a simple code for Python: https://github.com/LakeBTC/lakebtc_python
And others Sample Code you can find here: https://www.lakebtc.com/s/api include PHP, Node.JS, Ruby and Python, maybe will more Code in the future :)
Disclaimer: I work for 2FA company CryptoPhoto
Google Authenticator does not save you from phishing or MitM/MitB or malware like NeverQuest, Hesperbot, Zeus, Ice IX, Bugat V2, Carberp, Citadel, Syscron, SpyEye, etc - or any APTs at all.
Google Authenticator (GA) is not open source (only same antique version no longer in use ever got ...
I think I figured out your problem. (Or, one of them, at least.)
Step 6: POST params data in JSON format to this url:
You're not POSTing the the right information; you're POSTing the entire signature.
response = requests.post(self.apiUrl, data=p, headers=header)
Should be something along the lines of:
response = ...
The only reason I can think of that would result in the above with a valid OTP seed is invalid OTP settings (but default should work for Google Auth) OR incorrect time on the device OR invalid time (drifted) on the GreenAddress service clock.
I checked for the last one personally and the services clock is fine: in my experience most of the time is time/...
Despite I run both bitcoind and bitcoin-cli as the same user, it for some reason fails to find my personal config file located in standard location:
So I have set up an alias:
bitcoind -daemon -datadir=/raid1a/bitcoind/ -conf=/home/user/.bitcoin/bitcoin.conf
You can't. The cookie file is for bitcoind to write it's automatically generated credentials to for other software to read. If you want to set the RPC credentials, you need to do so within the bitcoin.conf file using the rpcauth option (or rpcuser and rpcpassword but these are deprecated). These could also be specified on the command line.
There is spending condition and ownership condition. The spending condition is set by the previous sender of the funds in the pubkey script: “proof that you can create the hash which belongs to this address”. With the one way hash function this proofs, that only “you” can be the individual, to further spend the funds.
You explained it correctly with the ...
1) The addresses would obsolete after one use.
2) If someone does a Sybil attack, s/he can prevent the transactions from relaying (which may also happen now), but also s/he can make a fake transaction from that address and relay it, as the attacker knows what the preimage is.
3) Even without a Sybil attack, someone could take advantage from eventual ...
It is supported according to the LND installation guide
The auth parameters rpcuser and rpcpass parameters can typically be determined by lnd for a bitcoind instance running under the same user, including when using cookie auth. In this case, you can exclude them from the lnd options entirely.
Your first point is indeed right: The BTC puzzle is only useful for ensuring the security of the blockchain.
Onto your next question: One of the first attempts to define a "useful" PoW was Primecoin, created back in 2013. Additional research in this area is being done.
In defense of Bitcoin's PoW, some people have said that Bitcoin mining tends to use up ...
Then, why I cannot broadcast to the community that the public key "hjf734hkjf" is sending 100 bitcoins to me?
That is not how Bitcoin works.
First of all, you do not send from a public key or an address. That idea is related to traditional "accounts", but Bitcoin does not use any sort of accounts system at the protocol level.
When you receive Bitcoin, ...
The rpc user/pass is only needed if you're planning to access the node via RPC. If you're running Armory on top of it, for example, that requires RPC and hence you would need it (Armory auto-creates the rpcuser/password for you, though).
If you're running a node and don't need the RPC functionality, no, you don't need those parameters set.
Maybe he is worried his old key was compromised somehow? If that is the case I would be careful about trusting anything signed with the old GPG key after the soonest date it could have been compromised.
I don't see a reason to worry about future releases he signs with his new GPG key.
As you have correctly noticed none of the Bitcoin exchanges have implemented the FIDO standards there is not a large demand for this feature from what I gather. If the standard were to gain mass adoption and many users began requesting it I'm sure it would become a greater priority for exchanges to implement.
As a side note the Ledger hardware wallet ...
You should have the option to remove / change the 2-factor Authentication under Settings >> Personal Details, though this may have changed. My guess is you'll probably need to contact Coinbase support if nothing else has worked so far: http://support.coinbase.com/customer/portal/emails/new
I'm not sure I see why you'd want to do it (increased centralization, likely decreased anonymization, and decreased mining incentive are generally considered bad things), but here's how I think I would do it, in general terms.
Have one (or more) master public keys hardcoded into the app. Have a special type of transaction that must be signed by a master's ...
There are different KYC (Know Your Customer) laws in different jurisdictions, but generally it takes information that is difficult or very time consuming to falsify. License/ID scans, utility bills, and SSNs are examples
Suggesting "hashing" as a KYC solution suggests you do not know what hashing is (unless you were referring to the way a server should ...
To generate the Rest-Sign header, use the following code (example in PHP):
function hmac_512($msg, $secret)
$secret = base64_decode($secret);
$result = hash_hmac('sha512', $msg, $secret, true);
$post_data should be an array with a ...