text:
How many confirmations takes place before transaction is successful
Yesterday I attempted to send two bitcoin transfers from Livecoin and almost 24 hours later it hasn't been successful. When I check the transactions they have 99 and 95 confirmations. What does that mean?

6f5d6cc00cabf6259852048eef2f8d827b7d43c08da361cec08d67e468c5e1de

f2cc94ce66eca7e55108ad0655e66ec1a97c12d05b51e8dd518a669f288de6e4

It looks like you have been bamboozled. These tx ids do not exist. What wallet / service are you using to send transactions?
https://blockchain.info/search?search=6f5d6cc00cabf6259852048eef2f8d827b7d43c08da361cec08d67e468c5%E2%80%8C%E2%80%8Be1de&searchbar=search // https://blockchain.info/search?search=f2cc94ce66eca7e55108ad0655e66ec1a97c12d05b51e8dd518a669f288d%E2%80%8C%E2%80%8Be6e4

I sent the transactions from Livecoin

1BABUhAB7976cP7qVcAEfUrtmitYZYkTw7

1GKHoWnZr9vpFjzZas6138fc1QrrAndiHp sending to these two wallets

It has no outputs, only one input from 19Bb7JdyMzdgRXznTgbaMEdtod13qQUnQD & 1Jtr7CWkWLqNsT2VP7F8uRY4CoigDxt8Jp             , see https://blockchain.info/address/1BABUhAB7976cP7qVcAEfUrtmitYZYkTw7

what does this mean? is it that my transfer has failed?

No, it means that you never transfered anything in the first place.

Try to broadcast the transaction again

Thank you. I will try again. The money was withdrawn from my livecoin account though

Actually, you did receive 30$ on https://blockchain.info/address/1BABUhAB7976cP7qVcAEfUrtmitYZYkTw7  with TXID https://blockchain.info/tx/6f5d6cc00cabf6259852048eef2f8d827b7d43c08da361cec08d67e468c5e1de I'm not sure if you were only talking about outputs, or inputs. In this case it seems you did receive the money, if this is your external wallet. sorry for my misunderstanding

But its not showing up in the wallet. Is it simply that I just need to wait some time longer?

No, it should be in your wallet right now. What wallet are you using if i may ask?

Can you explain precisely how you determined that it hasn't been successful? Be as detailed as you can.

It means that there have been 99 blocks after your transaction that have been succesfully confirmed.
99 blocks have basically confirmed that your transaction is real, and now ( and still does) belongs in the ( bitcoin ) blockchain.
So, yes your transaction has been successful, if you haven't been credited your bitcoin, or received it, something else is wrong. Mind linking me your TXID?
The more confirmations a transaction has, the less likely it will be that it could be overthrown in a 51% attack, or for example a double spend ( 1+
 confirmations already makes sure that isn't the case)..
Generally a transaction with over 6 confirmations is seen as "Irreversible", (aslong as there isn't 1 miner with 51% hashpower) since it would be mathematically impossible to throw over these 6 blocks.
See Why is 6 the number of confirms that is considered secure? for more information about why these confirmations are so important.

That said, IIRC, new coins (from mining) may require longer proofs - 100 comes to my mind for bitcoin cash on some exchanges at the moment.

Yes this is COINBASE_MATURITY and in Bitcoin is 100 blocks: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h


text:
How to recover Bitcoin Cash from Multibit Wallet?
I have been reading through posts and cannot figure out if this is possible or not. But I had bitcoin on an old Multibit wallet. I do not have the seed phrase from when I opened the wallet, just the key to the wallet. I have just moved the bitcoin off to a secure wallet. However is there any way to recover the bitcoin cash? Thanks in advance!

Export the private keys from the Multibit wallet, then import them into a Bitcoin Cash wallet. How to import them will depend on which wallet you choose to use.
Don't use the public addresses associated with those private keys again for Bitcoin transactions (I think you know that already though since you've already shifted your bitcoins away... which is the safe thing to do).

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How do I buy Monero with my Bitcoin?
I saw a guy on CNBC talking about Monero, how do I buy with BTC?

http://monero.org/services/exchange/

You can use shapeshift to buy monero with bitcoin

You can go on any exchange and do the swap.

Not all exchanges trade Monero...

Sure : go to Kraken :)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How much space does a backup of a wallet usually take?
I have a Bitcoin QT v0.8.5-beta wallet (downloaded in 2013) which I will backup before trying to export the private keys to a Electrum wallet. I have found a backup button in the QT wallet, but it doesn't describe what the backup leads to.
I have downloaded about 1/15 of the blockchain (224 weeks behind) in the QT wallet, and I have a pendrive with about 2 GB free space that I intend make a backup to. So should there be enough space on the pendrive to take the backup?

0.8 will not really be able to sync (0.15 is orders of magnitudes faster), you'll need to upgrade.

Wallet backups are a few megabytes, depending on the number of transactions it has made.

Just a quick note, there is a difference between the wallet and the blockchain. When you back up a wallet, you are backing up your private keys, addresses, etc., not the entire blockchain. The blockchain takes around 150GB as of writing this post (see here: https://blockchain.info/charts/blocks-size), but a wallet backup is much smaller, as eponymous said.
You can back up the blockchain too, it is found inside your bitcoin data directory, but that is unnecessary because it can always be redownload from the network if needed. Only the wallet itself holds your keys which you must back up to keep safe.


text:
Differences between types of paper wallets at bitaddress.org
What are the differences between the different types of paper wallets offered at bitaddress.org? I think the same question applies for the paper wallets offered at bitcoinpaperwallet.com.
On bitaddress.org, the options currently include:

Single Wallet
Paper Wallet
Bulk Wallet
Brain Wallet
Vanity Wallet
Split Wallet
Wallet Details


text:
Running two bitcoin instances on a linux server, can't get peers on second instance
I am running two bitcoin instances using the method described in this previous thread: https://bitcoin.stackexchange.com/a/13584/6024
I have set the new datadir and each instance has a different wallet.
However, I found that I can't use the same port to listen on, otherwise there is a conflict. If I change the port for the second daemon, it receives no peers and cannot update the blockchain database.
How can I solve this issue?

You'll want to add either addnode=<ipaddress> or connect=<ipaddress> to the bitcoin.conf of the node that is not working, where <ipaddress> equals the 127.0.0.1
These can also be command line flags (e.g., bitcoind -connect=127.0.0.1).
The difference between addnode and connect is explained like this (attributed to 'Noodle' on Freenode):

Quick Primer on addnode vs connect
Let's say for instance you use addnode=4.2.2.4
  addnode will connect you to and tell you about the nodes connected to 4.2.2.4.  In addition it will tellthe other nodes connected to it that you exist so they can connect to you.
  connect will not do the above when you 'connect' to it.
  It will only connect you to 4.2.2.4 and no one else
  So if you're behind a firewall, or have other problems
  finding nodes, add some using 'addnode'.
  If you want to stay private, use 'connect' to only connect to "trusted" nodes.
  If you run multiple nodes on a LAN, there's no need for
  all of them to open lots of connections.  Instead 'connect' them all to one node that is port forwarded and has lots of connections.


text:
How does a miner insert the hash of a merged-mined alt chain's transaction into a Bitcoin transaction?
I've read the how does merged mining work? thread and I'm a bit confused as to how one of the transactions in the bitcoin block "stores" the hash of the Namecoin block. Where is this information stored in the transaction sent to the bitcoin network? As a recipient address? Somewhere else?

A 44-byte header cointaining:

magic: 0xfa, 0xbe, 'm', 'm' (only required if over 20 bytes past the start of the script; optional otherwise)
block_hash: Hash of the Namecoin block header
merkle_size: Number of entries in aux work merkle tree.
merkle_nonce: Nonce used to calculate indexes into aux work merkle tree; you may as well leave this at zero

is included in the scriptSig of the coinbase transaction in the Bitcoin block and sent to the Bitcoin network. Note that it is only sent to the Bitcoin network if it meets the network difficulty of Bitcoin. If it only meets the difficulty of Namecoin, it is only sent to the Namecoin network.
Source: https://en.bitcoin.it/wiki/Merged_mining_specification


text:
Why are transactions with no outputs not relayed by default?
I was reading this thread about making a transaction without an output:
Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)?
The answer is that outputs under a certain value are considered "dust" or "spam".
What is the reasoning behind this? If the input value minus the output value is above the getMinNonDustValue minimum limit, why would the transaction be considered "dust"? The coinbase of the block containing this transaction would simply be allowed to be of higher value, which is how fees usually work.
If my understanding is correct, the network would benefit greatly from a transaction with no outputs. It's fairly easy to circumvent this rule anyway; one could simply add an output that matches getMinNonDustValue and increase the input by that same amount. Allowing a zero output transaction would mean less network load, less data storage requirement, and most importantly less CPU cycles required because the output script is not necessary in this transaction. There is also the added effect of making miners happy by introducing a new rule that allows "donation only" transactions where all Bitcoin go to the miner who solves that block.

The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are many good changes that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just as you said, this can be easily circumvented.


text:
Can you be 100% certain that a payment was sent from a specific address?
Reading this thread about determining the sending address of a bitcoin transaction. I'm a bit confused, how do you differentiate between the change address and the "receiving" address of the last transaction?
txid = <relevant transaction id>
addresses = []
raw_tx = decoderawtransaction(getrawtransaction(txid))
for(input in raw_tx['vin']) {
  input_raw_tx = decoderawtransaction(getrawtransaction(input['txid']))
  addresses.push(input_raw_tx['vout'][input['vout']]['scriptPubKey']['addresses'] [0])
}

Would addresses not include other outputs that are unrelated to the sending address? I'm trying to build a block explorer and I'm uncertain how to determine which address sent coins in each transaction. Is it possible to tell?

Payments are not sent from addresses, they're only sent to addresses.

Is that to say there is no way to tell with 100% certainty which address signed a transaction into the network?

You can tell which address(es) keys were used to sign the transaction, but that doesn't tell you who sent the transaction, only what keys were needed to sign it.

Let's say a website has online wallets, and each account is given an address which they can send coins to other addresses on the site from. Considering the site controls every RPC call of all of these addresses, and you always use the sendfrom command, is it true that you'd be able to tell which address signed each transaction? Is there any possibility for abuse if the users of the site don't have access to the private keys? (I'm thinking of making a color coin type app, with small transaction amounts, but very long delays between transactions to avoid spam of the network).

I can't see how that would work, unless the site sends each transaction twice, first to the source it needs to send them from for the real send. To the extent you can send funds "from" an address, it must be the address those funds were last sent to. Also, I'm not sure this would help -- people wouldn't, in general, know transactions came from this site so even if this site could make the information reliable, people wouldn't know it was reliable and so couldn't rely on it.

Could the site not provide a signed message to prove it owns an address? The idea is that the "color coin" within this network of people should not be sent outside of the network and is tracked by the site itself, which validates sending and receiving bits of that color coin amongst users of the site. It's simply using the blockchain to recognize these transactions publicly.

Yeah, but I think that would be an example of an entire class of silly answers to the question you asked. You can be 100% certain that a payment was sent from a specified address if you sent it too. Yes, if some out of band mechanism you trust, assures you of something, then you can be certain of it.

possible duplicate of When a transaction is split into two outputs, how does the network "know" you're the owner of the "change" address?

@Stephen Gornick the questions are entirely different, this is a blockchain data structure question whereas the last question was about the distinction between an address, an account, and the way the private key works in the wallet. They are sort of similar, though.

Every output is identified by the hash of the transaction it is in, and the serial number of this output in the list of transaction outputs.
If an output is spent as the input of another transaction, the input of that transaction contains two fields, txid and vout, to specify the tx id and the serial number of that output.
In the code snippet you give, first input['txid'] is used to pinpoint the transaction, and then input['vout'] is used to find the specific output.

Okay, so when you're looking at a transaction, the vin array contains txid and vout metadata, so if you then look at that txid and find the vout with the same n value as vout you've found the output that refers to that exact transaction? Meaning you can be sure that if you're looking at the vout field of the transaction with the txid hash and n = vout then you've found the exact output that refers to that input? But can't addresses in the scriptPubKey array have more than one address?

@bvpx: I'm not sure but I believe multisig outputs will have multiple addresses listed.

From the Bitcoin Wiki:

An input is a reference to an output in a different transaction.

A transaction can have multiple outputs, e.g., a normal one and the change, which specify the recipient address in their scriptPubKey. So usually to each output belongs one address, and the input specifies which output it redeems.
If an output specifies multiple destination addresses (which is rarely the case), only one of those can redeem the transaction. You can find out which one by looking at the scriptSig of the input.

Okay, so the addresses field in the scriptPubKey can potentially contain multiple addresses? What scriptSig specifically can allow this?


text:
Does bitcoind not support txindex=1 option in regtest mode?
Is it possible to specify txindex=1 option in bitcoin.conf or elsewhere?
It doesn't seem to work. Whenever I run bitcoind -daemon, it stops.
If I remove txindex=1 from the conf file, it works.
I am using regtest mode.
Here is the conf file:
rpcuser=abc
rpcpassword=secret
regtest=1
rpcport=8332
txindex=1

If bitcoind stops, them you should have a look in your debug.log file.
Enabling -txindex with an already initialised blockchain (not your first regtest start) requires a reindex.
Either you start with -reindex-chainstate or you delete your <bitcoin-data-dir>/regtest folder


text:
how do I import a private key corresponding to bech32 address to bitcoin-core?
Example address
bc1q69wqlexdn250purgskahfj9pg2f3ylg82vgy9m
private key (WIF)
KyVWvid6fC5WXHrV35ZkxqXgXsYrE9mPxMpusWBFiF771y2AYZrz
How can I import this into an existing wallet (Bitcoin-qt)?
I tried the other questions about import but that doesn't seem to work anymore (as of 2023).
importprivatekey command returns null but that address (or any other address) is nowhere to be seen in QT.

Do you know if you're trying to import it into a legacy wallet or a newer descriptor based one?

I used the latest bitcoin-core (downloaded yesterday)

Ok and did you create a new wallet or import an existing one?
I'm asking all this because wallets are now descriptor based by default, and I think you should use importdescriptor instead of importprivkey if that's a new wallet.
That should look something like wpkh(KyVWvid6fC5WXHrV35ZkxqXgXsYrE9mPxMpusWBFiF771y2AYZrz).
I can't help with the gui though, as I haven't used it in ages.

There should be the addresses shown in the Receiving addresses window:

Wow! the import actually worked. No need for descriptor. It imported 3 addresses, which I assume are, non-segwit, segwit and segwit-bech32. That "receiving address" option is so hidden, that I missed it. I clicked on "Receive" and there were no addresses shown.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
when I send money from my wallet, which address shows up as "sender"?
I have not yet sent money to anyone. I was wondering if there is any way to control which address shows up in the block chain as the sending address.
Say I receive money on addresses A, B, C.
I want to send money to someone from a totally unrelated address D. How to do this using the bitcoin client.
EDIT: I want to unlink addresses (A, B, C) from D
So when I send money, the sender should be D, and there should be no transactions from any of (A, B, C) to D, directly or in a chain. I guess this is not possible without 3rd party help.
I fear that the ability to follow transactions in a chain will eventually reveal enough information about identity of users. So there should be a way to send/receive from two complietely unlinked addresses. (linked = connected via a transaction chain).

Are you specifically concerned only with the sending address? Or are you trying to prevent the coins from being traced back to addresses A, B, and/or C. For example, would transferring from A to D and then from D to the recipient accomplish your objective? D would be the sending address, but D would have received the coins from A.

It's also worth considering what the "change" address will be in the transaction. The asker of this question may be unaware of that address existing.

Actually I am not aware of 'change' address, as I have never spent any BTC yet. Can you please elaborate?

@Jus12: See https://en.bitcoin.it/wiki/Change.

@DavidSchwartz: I want to prevent the coins from being traced to A, B or C. I have updated my question with this information.

Bitcoin doesn't really have sender addresses.
Every transaction consumes some of your coins, and creates one or more new coins, potentially assigned to a different address. What the receiver can see is the transaction, and he can trace which coins it spent, and which addresses those coins were previously assigned to. Some programs/sites use the first such address as sender, but this is not recommended. It doesn't say who sent the money - only who previously controlled it (which may for example be a shared webwallet).
The reference client always considers its entire pool of (confirmed) coins as source for creating transactions. The recently (0.7.0) introduced raw transaction API allows fine-grained control over which coins are used as input, but does not have a GUI (yet).

In every client that I know of today, the sending account is selected automatically for you based on a defined set of rules.
If you need to control the sending address, you could do so using a client like Multibit, though the process would not exactly be straightforward.  Assuming that you have a Multibit wallet with bitcoins, you would have to:

export your private keys.
edit the export file in a text editor to remove all keys except the one that you wish to spend.
create a second wallet file in Multibit.
import your edited private key file.
spend your coins from the new wallet.
export the keys from the new wallet file.
import the keys from the new wallet file into your old wallet file.
delete the new wallet file.

Note, steps 6 and 7 are necessary to capture the change addresses if you did not spend the entire amount in the new wallet.
It may also be possible to take that exported private key and import it into an online wallet like BlockChain.info's My Wallet or Mt Gox and spend it from there.

You can use Raw transactions to create a spend transaction from A, B, and C to the address D and then spend from D.

http://en.bitcoin.it/wiki/Raw_Transactions

This obviously links D to A, B and C.
The only option to de-link these is to use other coins, similar to what mixing services provide.


text:
How do off chain transactions work?
Some wallets (such as inputs.io) claim to provide off-chain transactions. Note: I have not used that wallet yet.
Say if I have a Bitcoin address A in such a wallet provider and send 1 Bitcoin to address B from the same wallet provider, what will show on the public blockchain?

Will there be 1 Bitcoin in B on the public blockchain?
If yes to 1, will that Bitcoin show as coming from A?

There will have to be a public record of a transfer into address B before any transfers can come from address B.  Internally the provider may move the funds from one address to the other "off-chain" for purposes of display but until some BTC moves into address B publicly it can't be spent from B.
Most likely when you attempt to send BTC externally from address B, that amount will either be:
1) transferred publicly from A to B and subsequently from B onward (incurring 2 transactions and twice the confirmation delay)
2) transferred to a provider address from address A and be internally deducted from address B inside the provider system and actually transferred from some other provider address
3) publicly paid directly from address A but shown as deducted from B in the provider system
Off-chain transfers are one way to add additional anonymity to Bitcoin transactions but at some point the source address has to be publicly credited with BTC for the exchange to be valid in the block chain.

If this is all managed off-chain within the same wallet provider then there would be no record of the transaction at all in the public blockchain.
It would just be bit-flipping inside of the wallet provider's internal database (just like with a traditional bank, or with PayPal).

whats the point of using a Bitcoin address then?

What else would you use? Compared to withdrawing the money and transmitting USD it is cheaper, faster, easier. Compared to sending to a user account name on the wallet service it is more private. Compared to sending it over the block-chain it is faster (no need for confirmations), cheaper (no transaction fee), and more scalable (reduces strain on the network by keeping things off the chain).

For example, if you use a inputs.io wallet (as you said) to pay a merchant who uses inputs.io as a payment processor, there is no point actually sending a tx to the Bitcoin network, when inputs.io can just internally shift who owns what amount of bitcoins. This is reflective of the typical "exchange" model of off chain transactions, where you're dealing with two parties who both have accounts with the same intermediary entity.
This is happening for saving time rather than waiting for miners to confirm a valid transaction in Blockchain.
On the other hand this procedure is not transparent because the transferring of funds it is only happening in a local-based off chain internal ledger.


text:
what is wrong with this litecoin transaction? getting "tx rejected: (code -22")
raw hex:
0100000001390210797248b4f5a4a6c0fbcbde14a3ea132bdbfedb07aea35bff5cfc0766b1000000008a4730450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da41041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42cffffffff0140420f00000000001976a914bee3bbfdad113a061739375edcfe6a908c096c7088ac00000000

I got this handcrafted tx from somewhere. I want to know why it is not being accepted.
From sendrawtransaction in litecoin-qt, I get TX rejected (code -22)
EDIT: I missed a zero in the beginning. Fixed it
Here is what I get using decoderawtransaction
{
"txid" : "a3de612bfa175d4c688648e205644305561f7d2cd96ae6a4ad23cabac4e3b887",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "b16607fc5cff5ba3ae07dbfedb2b13eaa314decbfbc0a6a4f5b4487279100239",
"vout" : 0,
"scriptSig" : {
"asm" : "30450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da 041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42c",
"hex" : "4730450220035db00b2bed0e4e97b92b9ee3610587110041c0e71f99b4563fe990d1a5a2b0022100ded70700477d36e7867dfb11842e86ef95e06e5fe910f4334730195493b362da41041862f45bcd7f2a0a8b2f1d24effdcede809ba4f46a78e5baac43ae0c0f6c651ceb02db5a9527ca9e722a4aca51284d6ee36408625b3463c68abfe3b5740aa42c"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.01000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 bee3bbfdad113a061739375edcfe6a908c096c70 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914bee3bbfdad113a061739375edcfe6a908c096c7088ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"LcdHTvKV5PNBbhcHrd1h3QRNcJLsxkfUfd"
]
}
}
]
}

EDIT: could be a problem with signatures. Can someone verify if the signatures are correct. I don't know enough about the litecoin protocol to do it myself.

Bitcoind can't decode that, so I've no idea how you managed to create it.

@Anonymous I made a typo in the transaction. I have fixed it.

It looks like these are freshly mined Litecoins that have not matured yet, you need to wait until they mature to spend them. Maturity refers to the number of confirmations that newly mined coins need to have. For Litecoin (and Bitcoin) this is 120 blocks.
(See a discussion related to this here: https://github.com/litecoin-project/litecoin/issues/26)
So you won't be able to spend these coins until those blocks get mined. But at the rate that Litecoin blocks get solved that would be around 4 hours, which means that same transaction might work now.

it does not seem to be that. Its been more than 12 hrs. I still get the same error. Also, on a block-explorer they dont seem to be fresh.


text:
Missing key on blockchain
I created 2 different wallets at block chain. The first one gave me an address for receiving btc. I used that address for a purchase, however, now when I login to my wallet, it no longer shows that address. Luckily, I saved it, and can search for it. It does show the btc I purchased, but requires me to enter the private key before moving them. I thought the entire address I sent for the btc included the private key. I also checked the other wallet I created, and the address I first got is not there either. These are the only 2 wallets I created and I know I received the original address from one of them. I know there are hackers out there, but that is not me. This is MY wallet, and I paid a lot of money for the btc, but clearly I screwed up somewhere. This is the address: 1593pt67xM8KRZ23Akxp2KwCj856fCfWSh

"I thought the entire address I sent for the btc included the private key." That would make the system fairly useless. Every time you wanted someone to send you money, you'd have to give them the ability to take your money!

Your Bitcoin address and your private key are not the same.
The private key is a random number. You keep that number a secret, and only having it allows you to spend Bitcoins. It is used to sign transactions.
From the private key you derive a public key. It is used to show that you are using the correct private key. It is used to verify transaction signatures.
From the public key you can derive the Bitcoin address, which is a convenient way of encoding the public key. It is more compact, comes with error detection, and so forth. It is used to let people know where to send their Bitcoins to when sending you money.
From a private key you can derive the public key. From the public key - the Bitcoin address, but in neither of those cases can you do it in reverse. If you have lost your private key, your money is lost forever.
However, from what I can see your address has been successfully used for withdrawals, and its balance is currently zero. If you have gotten it from blockchain.info eWallet, you probably should contact the owner of the site with your issues. In Bitcoin world, it is very hard to prove that you own an address without having a private key.

Are you saying you received a payment but don't see the address when viewing the Receive Money tab in Blockchain.info/wallet?
That can happen when the funds have been spent, as the address gets archived.  Click the Archive sub-tab to see if the address appears there.
Also you can see all activity for your wallet by clicking the My Transactions main-tab near the top.


text:
What are the advantages and disadvantages of keeping bitcoins in an exchange versus a private wallet?
What are the advantages and disadvantages of keeping bitcoins in an exchange versus a private wallet?
Exchange advantages:

Liquidity - you can quickly trade bitcoins for dollars, and vice versa.
Can hold dollars directly

Wallet advantages:

No reporting requirements
Can quickly get at your bitcoins

In the form of a question, Alex.

@StephenGornick :) okay, modified

possible duplicate of Pros and cons of using Mt. Gox as an e-wallet

It is the trade-off between security (as Sly has elaborated) and flexibility to convert BTC into hard (cough!) currencies.
Say you are some miner from the old days and keeping some thousand BTCs somewhere in your private wallet maybe you want to buy a nice car and you need $30,000 you could go to mtgox (or any other exchange) and sell these 1000 BTCs and retrieving the money (several limitations apply)
On volatile BTC exchange rates you may want to sell immediately however the transfer from your private wallet to the exchange account takes some time (around some hours(!) sometimes), maybe the rate has dropped already and you do not want to sell anymore.
You are buying this flexibility with the risk of a compromised account or a hacked website (MtGox was already hacked in the past,though no user bitcoin accounts we stolen ).
So keep a strategy how and where to transfer your BTCs
I usually hold only a limited amount outside my private wallets These are the BTCs I want to sell

From what I understand it comes down to how you feel about security, to have a wallet stored privately means that you run the risk of equipment damage where you'll have to spend time on the recovery.
On the other hand you have the risk on network security, at least 2 exchanges have had high profile thefts occur in past years which have effected the market, exchanges make for big money targets and there's no real way to recover the funds.
Personally I think there is likely room for a hybrid solution between the two but I haven't seen anything yet.


text:
HD wallets and address reuse
HD wallets create a series of addresses, and then when one address has received an input it will give you a new address that hasn't received inputs yet
So in the idea of you sending yourself bitcoin from an exchange, and having different addresses all the time on the exchange, and different addresses in your wallets, then an observer wouldn't be able to track the sum of all your funds.
But isn't this all undermined when you move a large amount of bitcoin and the transaction combines bitcoin from all of the addresses in that wallet?
How is that part avoided while retaining the ability to realistically send funds quickly and conveniently? I understand that it is possible to form a transaction to only use a certain address for sending, but ultimately there is still a third party with one address that I want to send bitcoin to. So I will have to use several of my addresses to get the appropriate balance.
This seems to completely undo my privacy. Not necessarily from blockchain analysis but by having records of a single address (such as from the exchange).
For instance, lets say an exchange gave over the user names to a government. The government then looks at all the addresses that user sent bitcoin to from the exchange. Then they simply look in the blockchain for that address and look to see where it was used again to combine bitcoin with other addresses, as this reveals that one person had the private keys to all those addresses used. Privacy undermined.
Solution? I can imagine a scenario where I could do one transaction at a time back to a different exchange, generating new addresses in my exchange wallet. Cumbersome. But for something like a bitpay payment, I don't see how this is practical, unless third parties also let me choose how many addresses they would generate for me.

As mentioned, I don't believe HD Wallets are relevant to this problem. Even with simple wallets combining inputs from multiple addresses proves that a single person owned all the addresses included. I'm not sure if this would meet your specific privacy needs, but it is at least a straightforward way of avoiding that problem:
Assume you have 4 addresses, A, B, C, and D. You want to send a transaction that requires funds from all 4 without proving that they were owned by the same person. You could generate a 4th address E and over the course of several days combine all the address values at a new address.
While the blockchain would show that the funds in E came from A-D, there wouldn't be any proof that A-D were owned by the same person, as they were never in a single transaction together, and it is feasible that 4 different people all transferred value to E, instead of the same person transferring value to E.
It seems feasible to write a client that follows that policy of never combining inputs from multiple addresses in a single transaction, which would at least allow plausible deniability. The user would be able to manage timeframes depending on their needs, so that the combination could occur over the period of an hour or a year, depending how soon they need the transaction. You could also add some intermediary steps to split things up a bit more and pass through a few extra addresses to make it slightly harder to follow.
Since it is a public ledger it really isn't a very anonymous system, and achieving anonymity is difficult without a mixer, but the biggest compromise to anonymity is connecting multiple addresses in a single input, so simply avoiding doing that will be helpful, but at the expense of convenience.

hm yes, an algorithm to never combine inputs

Is there a way to eject an address out of an HD wallet? remove an existing address from the sequence of addresses?

Unfortunately I cannot conceive of a way that would be possible. The purpose of a HD wallet is that a single seed is capable of generating all the addresses under it in a deterministic fashion. So if a wallet falls under your seed's space you would need to undo laws of math to get rid of it. Your best bet would be generating a new seed and sending your coins there.

interesting, I think BIP32, BIP39 and BIP44 needs to come with best practices. I see a variety of problems with it that may not be apparent. What it can do and what it can't do for you.

Privacy is one of the most common myths about Bitcoin. By default, it does not provide anonymity, for many reasons, including the ones you have mentioned. Applying graph theory on the transactions can reveal a lot of information, connect seemingly independent addresses and thus compromise them. Bitcoin was never meant to provide anonymity out-of-the-box, so it's hard to blame it.
However, this does not mean the anonymity is impossible to achieve. There are many 3rd party services specializing at this, mixing your coins with other people's coins, for example bitmixer.io. You can find more such services and use them in chain for even better anonymity, just search the Internet for bitcoin mixer or bitcoin laundry.
Note: the problem of connecting addresses to the same owner is not specific to HD wallets, but concerns also simple wallets that generate all the addresses randomly. For the outside observer, there's no way to tell if you're using one or another, but this information is not necessary to connect the addresses once you've made a transaction combining their inputs.

mixers are inconvenient, expensive, centralized, not trustless, contain records, the user nor the admin would never know if the mixer has been compromised for years, and ultimately it greatly increases the transaction cost. secondly, if this isn't done before one is seeking to make an unlinkable payment, for example - to a bitpay address - then they won't be able to mix within the 15 minute window that bitpay gives.

yep, it is essentially true what you're saying, yet Bitcoin mixins play a significant role especially in the black markets, where coin anonymization is essential. It is a common practice to always keep some "mixed coins" in your wallet, so that you can use them (immediately) whenever needed. You can increase the anonymity by using multiple mixins in a row, but obviously you can never be 100% sure. Well, guess Bitcoin would have a much harder time getting legal recognition if it was anonymous :-)

Whatever the answer is today, it probably won't matter in the not-too-distant future.  The blockchain is a public and permanent record of everyone's transactions.
Besides the fact that one would have to be 100% anonymous for each and every transaction, 100% of the time to remain anonymous (whatever that solution is)... There's that permanent public record of every one of your transactions.  If somebody wants to they will eventually connect the dots from enough public and private databases.  Not to mention quantum computing or other future advancements.
If I were a tax collector and wanted to prevent cheating, I would create a foolproof system to maintain a permanent record of every transaction.  Then we could make it easy, troll the blockchain and submit monthly tax invoices to my minions.  Don't pay it?  Your transactions will not confirm. Can't spend. Kinda hard to refute then.

pure conjecture, John, the exchange operator, cannot prove that Alice, an account holder on the exchange, is in possession of a private key by the mere existence of Alice sending bitcoin from one address to the next. if Alice uses different addresses for every transaction, there are simply no dots to connect. Your answer suggests you have no idea what the actual "threat" from quantum computers is.

Yes, conjecture.  Hence the 'probably'.  My point is whatever happens in the future, there's this blockchain permanent record that will be used to retroactively nab people.  One vector we currently know if is quantum computing and the potential to hack our keys (not to mention SSL etc.).
Another vector would be mixing your banking info with your bitcoins by buying coins from someone like Coinbase.  Coinbase could easily be forced to give up info tracing the purchase of my coins, connecting the dots.

You are missing the point. The entire scenario already considers that this is already happening, consider the exchange already having this information, best practices from  satoshi's 2008 whitepaper still counteract this. you are just writing random gibberish for the sake of it, this is about unlinking transactions, where unlinking is unlinking. There would be no correlations to make, no encryption to bust.

I'll fill in the technical aspects where I can later today, but in principle what's happening is a private key is being altered in such a way so that HD public keys can be created and traced up the family tree, that we both know.
But here's a few thing to consider:

Can a pubkey be isolated as being your key? Most likely not, but assuming so, it's still only the hash160 shared publicly. What's to say you haven't changed wallet seeds, for example?
Assuming 1 to be true, reversing the SHA256 AND ripemd160 for your public key x/y coordinates is ~impossible ie
pubkey <==A==> hash <=====B===== 0x04 X + Y
      A = base58,     B = SHA256/RIPEMD160

.
The only probably way a link between the public key and the private key can be found is by having at minimum the private key, and ideally for an attacker, a set of privatekeys

yes, but lets say I have 3 pubKeys, with 1 btc each. I then encounter a bitpay pubKey and to acquire the good/service I must send that bitpay address 2.5 btc. Any thing I think of will combine the transactions from pubkey A, B and C, whether I do it in one transaction or 3+ transactions, within the 15 minute time period that bitpay allows.


text:
How difficult is it to determine the owner of some bitcoins?
When Bitcoin was making the media waves back in 2011, a lot of it focused on the anonymity aspect of bitcoins, the hacks, and the illegal contents of the silk road onion address. From my limited understanding, it didn't seem like bitcoin wallet owners and transactions were all that anonymous, only merely obfuscated.
I feel like one would have to go out of their way to really make their bitcoin ownership anonymous.
I would like empirical resources on:
1) finding a user through a block chain
2) further obfuscating ownership of bitcoins
and any other currently relevant or useful literature. Perhaps a case study of an actual investigation on a bitcoin holder. (Like tracking down perps in the bigger security breaches)

I agree with Colin Dean, possible duplicate.

@gosmond let me get this straight, I had a unique question that got edited into a duplicate question and then closed? wtf. well I'll check out the other answer on that question


text:
How are per-day statistics computed on MtGox in the middle of the day?
MtGox trades 24 hours a day, 7 days a week. Yet charts show daily charts and volume stats, especially intraday, when does the trading session begin and end on Mt. Gox, for reporting purposes? Also, what time zone.


text:
bitcoind validateaddress extended info.. somtimes there, somtimes not, why?
I have noticed sometimes ./bitcoind validateaddress [addr] produces an extended output, like this:
./bitcoind validateaddress mjYvqa4tC4oEC2ATQrcJh9Ux3CLcszW5J9
{
    "isvalid" : true,
    "address" : "mjYvqa4tC4oEC2ATQrcJh9Ux3CLcszW5J9",
    "ismine" : true,
    "isscript" : false,
    "pubkey" : "03ab4a26a0d577bb4dd5c46b49c1dd19a30a582a5b317f952e490eaac86564fdc0",
    "iscompressed" : true,
    "account" : ""
}

And other times, when I validate and address it looks like this: (why?)
./bitcoind validateaddress n3t74UDtWZtBSVbF5DLxm4ViFiU7rRY5gm
{
    "isvalid" : true,
    "address" : "n3t74UDtWZtBSVbF5DLxm4ViFiU7rRY5gm",
    "ismine" : false
}

Note the difference: one has "ismine" true and in the other it's false.
I haven't specifically checked, but I presume that "ismine" indicates whether or not the address is one belonging to you (and whose key is in your wallet).  If it is your address, then bitcoind is able to report the associated public key, and various other details about how the key is stored and notes associated with it.
If the address is not yours, then since the address is only a hash of a public key, there is no way for bitcoind to know what the public key itself is, nor any other information about how the owner is storing the key, etc; that information is known only to the key's owner.  So you don't see these fields in the output.


text:
Are there bitcoin exchanges that do not require an extensive verification process?
Are there bitcoin exchanges that do not require an extensive verification process to begin trading? I do not want to submit forms on MtGox.

No U.S. exchange. Btc-e does not but they will not do business with U.S. banks. Coinbase does not have an extensive verification process, but they are technically not an exchange, and to buy or sell bitcoins through their service you have to link a U.S. bank account which for all intents and purposes is the same thing as verification.
Due to the patriot act any currency exchange doing business with the U.S. has the burden of proving that they are not laundering money for terrorists.

Most exchanges need your identity information. If you do not want to submit that information, your best bet is face to face or OTC trading with other bitcoiners. If you build up a good reputation trading OTC, then you can trade freely with trusted contacts, but the amounts you can trade will probably be smaller, and at a premium.

Online fiat exchanges can be heavily regulated. To avoid this inconvenience, when you are for example just buying small amount, you can buy over the counter from a friend. Simply send or give the fiat to a friend and recieve the bitcoin.
Another method is to use a bitcoin cash machine.
Good luck!

Bitcoin ATMs often require a mobile phone number for verification of identity.


text:
If all block chain copies get deleted, what would happen?
What would happen if all block chain copies get deleted at one time?
At first, all clients would try to get the block chain from other clients, right? But this would fail. Would the "network" then (but when exactly?) assume that everything just started, and mine the genesis block again?

If you intend to ask a hypothetical question about what would happen if all copies of the block chain were deleted, then you might want to phrase it "What would happen if all block chain files get deleted at one time?". With "when", it sounds like your asking what happens when you delete your copy.

The only time when the actual block data is needed is when other peers are fetching the blocks from you, or when you need to rescan for new wallet transactions.
However, the blocks you have already verified and processed are no longer needed by you yourself. Your node would not reset its state, as it still has the result of validating those blocks (the set of the remaining unspent transaction outputs). You could even mine new blocks still, and broadcast them, and other peers (who were similarly caught up already) would accept them as if nothing happened.
Of course, there are safety checks, and your client will not start when block files are missing. If those would be disabled, and everyone did this, and everyone deleted their blocks, the only effect would be that new nodes would not be able to synchronize anymore.
A future version of the reference client (possibly 0.10.0) will support "pruning", namely actively delete block files after validation when they're old enough. This will make your node stop advertizing as a full node, but it will keep functioning without lessened security otherwise.


text:
Heartbleed bug and Altcoins
Bitcoin recently released V 0.9.1 patching vulnerabilities from the Heartbleed bug, however I have not seen anything from any alt coin. What are the possible security risks associated with using these coins? And what are the risks to the coins themselves?

I've done a little research on this as it was a big concern, not to worry! This is only an issue if you have a bitcoin (or altcoin) daemon set up with RPC over HTTPS. This would only be used if say, you have a daemon running on one VPS and another node which asks it to send money. Source: http://www.cryptocoinsnews.com/news/openssl-heartbleed-security-bug/2014/04/08
This is disabled by default and unless you were using RPC over SSL there is no need to worry :)
If you have been using RPC for any coin I would say a good practice would be to generate a new wallet and send funds there.


text:
51% attack and rewriting to the latest checkpoint
This is not a question about the consequence of a 51% on the price nor as to the motivation of the attacker. Let say we don't care that it's not realistic and we don't care that the attacker wouldn't be rational.
Let's just assume an attacker has always 50%+1 (51%) of the mining power.
My understanding is that if I've got 51% of the mining power I can always, probability-wise, rewrite the blockchain to a blockchain with the more PoW.
I know there are checkpoints in the codebase with hashes of certain blocks and so I cannot wait decades (or hundreds of years), to rewrite the blockchain from scratch.
I read this statement, which I don't know is correct not:

Crypto Fact:  Longest (Bitcoin) Chain with the Most Difficulty Wins , unless a Checkpoint Blocks it.

But can I always rewrite to the latest checkpoint?
When are these checkpoints added and how "far back" do these checkpoints go?
Is there a maximum number of blocks or "rewrite" that nodes can accept hardcoded in the protocol? (where nodes would reject the chain with the most PoW because it "tries to rewrite too many blocks").
What about if I've got 99% of the mining power, is this different than having 75% or 51%?
I mean, theoretically, is there an attack I can mount with 99% that I cannot do with 51%?
This is really just a single question which I think boils down to: Can I always rewrite to the latest checkpoint if I own 51% of the mining power?

By the way this is purely a theoretical question, I tried to ask this on Reddit but let say the community in /r/bitcoin is quite, well, toxic and posts "answers" that are non answers.

As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization.
However, pruned Bitcoin Core nodes already in sync with the "lighter" chain would not be able to reorganize to the heavier if they no longer keep all blocks up to the common ancestor of the two chains. Instead, such a pruned node would have to resync from scratch.
If an attacker controlled hashrate equivalent to 100% of the SHA-256d hashpower they would today be able to rebuild a blockchain of the same aggregate difficulty as Bitcoin's in approximately 186 days.
The checkpoint system is deprecated (see e.g. this GitHub-discussion), instead new releases of Bitcoin Core since 0.14.0 by default use an assumed valid block. The performance of the initial synchronisation is hereby improved by the same mechanism as checkpointing used: Up to the height of the assumevalid block the verifying of scripts/signatures is skipped, only block validity is checked, the UTXO Set is populated, and any data on transactions that concern the node's wallet is collected.
The advantage of assumevalid over checkpoints is that it doesn't force the node onto a predefined chain. The user can pick another block or turn the feature off completely in the configuration of their node. Bitcoin Core by default uses a blockheight that predates the release by multiple weeks.
As such, the defense against such an attack could be to collectively agree to resync with assumevalid set to any block after the attacker's chain has forked off.

you would need to avoid that the attacker rewrites the attack again after the new assumevalid block, though. As the attacker has such "hashpower power", figuring out an scheme they couldn't retarget would be quite hard.

@Ángel: assumevalid would work as a defense if the attacker tried to rewrite the blockchain from the last checkpoint which IIRC is somewhere around height 295k, i.e. 4 years old, which also contain the heaviest portion of the blockchain. Rewriting the last four years would be horrendously expensive and thwarting them once probably enough. You are right though, if they have a much larger portion of the hashrate than just a slight majority (e.g. 90%), and are attempting to replace just a few blocks thwarting them would be almost impossible.

@Murch Bitcoin Core should reorganize fine all the way. Undo data is kept for all blocks that normal block data is kept for (subject to pruning).

@PieterWuille: Thank you, I'll correct my answer.

See What are checkpoints? for some clarification. To quote ThePiachu's answer:

The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".

Now, back to your questions:

If I've got 51% of the mining power [...] can I always rewrite to the latest checkpoint?

Yes. The attacker in your scenario can force the network to accept his chain, since he will outpace the rest of miners in the PoW. He simply needs to wait until his private fork is longer than the current consensus chain, and then publish - nodes will accept. The largest problem with this is the potential double-spending that the attacker can conduct while he is in control.
Note that a 51% attack is also possible with less than half of the total hashing power. Satoshi discusses this in section 11 of his paper. When one controls more than 50% of the mining power, the probability of a successful attack reaches 1.

I mean, theoretically, is there an attack I can mount with 99% that I cannot do with 51%?

No, it does not matter beyond this point.


text:
Bug with bitcoinchain.com?
The bug is with https://bitcoinchain.com
Before I report it I would like to see if I can gain any additional clues as to what might be going on in order to assist their developers to get to the root of the problem quickly.

If I call their API like so:
https://api-r.bitcoinchain.com/v1/address/utxo/1KZnzTTfuxiyHUJdLqn3UnHyTVDN2UgeHU
then add up all of the utxo.amounts they gave me for the wallet in question I get 0.57944267
But if you examine the wallet here https://blockchain.info/address/1KZnzTTfuxiyHUJdLqn3UnHyTVDN2UgeHU
you see that it really holds 1.15968995

With a little digging I see at least two of the utxos txid/hash(s) where they have incorrectly got the wrong output:
https://blockchain.info/tx/37ff697bc958071e6f6dc180f9b80edda8f87ab0ca2ad5cd3753e8f65c38e463

they have picked the wrong wallet address 1o69bsLaqaAM6R7bomaGVFT7uvGFvziTy

and
https://blockchain.info/tx/a02d62638266fe5b9004e99a45d5eca0878ab5dae1d328aeece39672f44cc98eeece39672f44cc98e

they have picked the wrong wallet addess 16tk4YEYpE6taGzZjkH9aiEApLLDR8UZL9

Not every utxo has this mistake, so it could be ruled out that they are always picking the first output.
I would have thought that they should just be asking if the output address matches the queried address but if they were doing that then surely this bug would not exist!
What other factors could cause this?

They're also missing some outputs, like 056c445c8d6f67355c554f186200af3413de9cb3918a13e7e0bb1b2d0a7cc2a3.


text:
Sent Bitcoin Cash to Coinbase Bitcoin address
I just mistakenly sent some Bitcoin Cash from Bittrex to my Coinbase Bitcoin wallet & of course they are now stuck. Bittrex have told me  to remove a private key from a Bitcoin address and import it into a BCC wallet to recover these coins. Apart from contacting Coinbase, has anyone any ideas?

You can wait until Jan 1, 2018 [1]; they are going to add Bitcoin Cash withdraw support. Or you can contact them (of course).
[1] https://support.coinbase.com/customer/portal/articles/2853600-bitcoin-cash---frequently-asked-questions

Thanks, I contacted them & hope they'll have pity on my stupidity


text:
Re-insalling Bitcoin Core without re-downloading blockchain
I had Bitcoin qt installed on my C drive and I downloaded the blockchain onto an external hard drive. I recently had to re-image my C drive. What I want to do is reinstall the Bitcoin software on my C drive without having to re-download the entire blockchain again.

Related: https://bitcoin.stackexchange.com/q/10787/516

Since you downloaded the blockchain onto an external drive, you do not need to redownload the entire blockchain. When you start Bitcoin Core for the first time, it will ask you to choose the data directory. Just choose the folder on your external drive which contains the blockchain data. That folder should have a folder named "blocks", a folder named "chainstate", a file named "wallet.dat", a file named "debug.log" and a few other files.


text:
How to claim Bitcoin Cash & Bitcoin Gold from paper wallet
Before the first Bitcoin fork (August 1st) I put all my Bitcoin into a paper wallet. I kind of forgot about it. Now I think I can claim Bitcoin cash as well. Now there has been another fork resulting in Bitcoin gold. How to I take my Bitcoin from the paper wallet and turn it into Bitcoin, bitcoin cash and Bitcoin gold?
Any step by step guides out there that anyone would know of?

Go to Blockchain.info
Sign up and after logging in, go to settings. Then in settings, you will see addresses as shown below:

Then click on Import Bitcoin Address as shown:

Then add your private key as it is in the form as shown:

Click import, and you will be able to use your BTC again.
Now to get Bitcoin Cash, just go to Settings > General
There you will see a button near this to claim your Bitcoin Cash as well:

Regarding Bitcoin Gold, it is still not officially started, and will update the answer once there is any secure way to access your Bitcoin Gold as well.
Please follow that and let me know if you were able to retrieve the coins.
Update:
For those who want to retrieve BTG, please head to Coinsutra for easy retrieval.

Is there an update on this?

Added the update about BTG as well. Thanks to @salvarico for that.

To claim your Bitcoin Gold you should follow these very simple steps.
To claim your Bitcoin Cash I found Electron Cash to be a very friendly option. You just need to follow steps similar to the Electrum Wallet: by using the New/Restore -> Creating a wallet -> Standard Wallet -> I already have a seed and then provide the seed with the BIP39 seed option checked.
If you want to exchange these coins to BTC I recommend you use Changelly.
ADVICE I suggest you first send your bitcoins to a new wallet and then do the steps above. This way you can be sure your bitcoins are completely safe.

Unfortunately the Coinomi wallet only runs on Android at the current time. What about for the rest of us?

This answer is not specific to paper wallets, but I believe it will work for them, or for any source wallet from which you can retrieve (a) private key(s).
The only well-tested and reliable wallets that I know of for BCH and BTG are the Ledger and Trezor hardware wallets and the Coinomi software wallet. Coinomi runs on the Android platform — usually phones and tablets.
However, you can run Coinomi without an Android device. Install the ARC Welder extension on a Chrome Browser, and download the wallet app, coinomi-1.7.10.apk, from https://coinomi.com/downloads
What I did:
(1) Moved my BTC from a local wallet on an internet-connected computer ("old wallet") to a secure offline wallet.
(2) Retrieved the private keys from the old wallet for any transaction in which BTC were received pre-fork(s) and which remained unspent at the time of the fork. (Retrieving  a key for a non-qualifying transaction is harmless; at worst it will cost you a little extra effort, and Coinomi will "harvest" no BCH or BTG from it.) Because of step (1), exposure of these private keys to possible compromise (spying, hacking) risks only your BCH and BTG, not BTC.
(3) In Coinomi, created a new wallet for BCH and another new one for BTG. Separately for each of these new wallets, with each relevant private key from step (2), I selected the "Sweep wallet" command from the three-vertical-dots menu at the upper right of the screen and pasted in the private key. (Typing in the key rather than pasting is not only error-prone but runs into some issues with Coinomi-on-Chrome.)
A quirk in Coinomi-on-Chrome: the shortcut key for Paste (Ctrl-V or Cmd-V) may not work for pasting in a private key. Workaround: type any character or two, select what you've typed, and a "Paste" button pops up.
Background on what happens in Coinomi, or any wallet which imports private keys: the wallet software accesses the BTC blockchain and looks up any pre-fork BTC transaction (i.e., any BCH or BTG transaction, respectively) in which coins were sent to a (public) address associated with the private key you entered and which remained unspent at the time of the fork.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
blockchain.info seems to source transaction money from an address not in my wallet
Today, I have send a transaction with too low a fee:
https://blockchain.info/tx/84eb8a6c6562a9cfedc0e82c7fbe3355615b8154e376db0a325b4ae4f26180b2
I have retrieved the twelve word pass phrase from my wallet on blockchain.info, and calculated the private keys for the addresses in my wallet. However, the address
1PUBmT2fzVMtNWg58K67knqoz58MmCJ8pn
is not amongst these, and it is also the only address that does not show up in my blockchain.info wallet. Therefore it I can only double-spend part of my first transaction (so to void it). What is happening here?

these are derived from the pass phrase that I got from blockchain.info

I'm just curious about how you derive keys from the passphrase.

I'd guess the transaction will probably be processed even if it takes a few days.

Did you input any private keys to your wallet? If so, those private keys won't be able to be generated from the wallet seed (the twelve word pass phrase).

@MaxVernon the bip39 tool on github

@HighlyIrregular No, I didn't, I'm quite puzzled by this

It is likely that the address in question is a change address. Change addresses are generated using a different key derivation path than your other addresses so you will not see it if you only generated the keys at only one derivation path.
The "normal" key derivation path (a.k.a the "external keychain") is m/44'/0'/0'/i. However keys for change addresses are typically generated on a so called "internal keychain" which has a derivation path of m/44'/0'/1'/i. It is likely that you only looked at keys on the external keychain and not the internal keychain so you did not see this address.


text:
How do I run two instances of bitcoind on the same linux machine with different conf files?
I want to run two instances of bitcoind on my machine.
I know my bitcoin.conf file is in ./bitcoin/bitcoin.conf, and I know (thanks to this thread) that I need to change my .conf file to point to different data dirs and RPC ports, etc.
However there is only one .conf file.
How do I go about pointing my second bitcoind instance to a new bitcoin.conf file? I copied the directory with the compiled code to a new directory, I am making the assumption that compiled code can be copied into another directory and it will work without problems.

Change the -datadir flag to a new absolute location. Each instance will follow the bitcoind.conf in their respective directory.

There is little to no documentation on this topic, so I guess I'll just ask here: I specify a datadir flag by typing ./bitcoind -datadir /dir/location/here/, is that correct?

That's correct.

./bitcoind -datadir=/dir/location/here/ don't forget the =

Probably, better to add new user.
Simply create new user:
# adduser bitcoin1
# adduser bitcoin2
# su -l bitcoin1 -c 'bitcoind'
# su -l bitcoin2 -c 'bitcoind'

How to run two instances with same wallet
sudo su -
./xcoind stop
cp -r .xcoin xcoin2

cat .xcoin/xcoin.conf
---
rpcport=3776
port=3777
---

vi ./xcoin2/xcoin.conf
---
rpcport=3876
port=3877
addnode=127.0.0.1:3777
---

./xcoind &
./xcoind -datadir=/root/xcoin2 &


text:
When a transaction is split into two outputs, how does the network "know" you're the owner of the "change" address?
Reading this thread about how transaction outputs are split due to "change" made me wonder how the bitcoin network knows you own that second address. How does your wallet/client display the correct balance, if it's unknown to everyone else that the second address is yours?
I'm assuming it has something to do with the wallet and accounts... if so, how can you find the "account" that corresponds with that address?

The bitcoin network does not know who owns which address. The concept of an address doesn't even exist at the protocol level - it's just an authentication layer on top of the scripting logic in transactions.
And of course your own client does - because it has the private key for change addresses it generated itself. That's all that matters. When spending a transaction output, the client will prove that it holds that private key by creating a digital signature that matches the address. That's all the network cares about.

So when your client connects to the network, it takes all of the addresses it has the private key for, then tallies up each of the coins that have been sent to each of those addresses and haven't been sent to other addresses to arrive at the total? I just tried dumpprivkey on the change address generated by my last transaction, and it worked. However, getaccount returned nothing. I'm guessing an account is a separate thing, and the relation between addresses and accounts in your wallet is not 1 to 1?

That's entirely correct. Accounts have hardly anything to do with addresses - they are just virtual balances (they can go negative too, for example, if you send more from them than to them).

The network does not have any labels associated with any address, besides the address itself.
The wallet software being used manages change addresses and corresponding private keys to ensure that the user has control over any change addresses.
From a network perspective, there are no accounts/wallets that can be readily identified (though blockchain analysis techniques can be used to attempt this to varying degrees of success). A group of addresses (AKA a wallet or maybe even account if one wants to call it that) can only be definitively identified/associated by the wallet software used to create that group of addresses.


text:
How does Open Transactions solve the double spend problem?
OT is based on digital cash. From the article:

To tackle the double spending problem, the payee has to verify the
  coin with the bank at the point of sale in each of the transactions.
  This verification of the legitimacy of the coin requires extra
  bandwidth and is a potential bottleneck of the system especially when
  the traffic is high. The real time verification also means there is a
  need for the synchronization between bank servers.

This is not clear to me. Does the bank know who owns each coin? What exactly does the bank verify? If I try to send the same coin to both Alice and Bob, where exactly would this fail? What knowledge do any of the parties (Alice, Bob, the Bank) gain during this transaction?

How long before we need a OT.stackexchange.com ? (not that I don't want to see and learn more about OT.)

@StephenGornick - Yeah, I know. See http://meta.bitcoin.stackexchange.com/questions/236/is-open-transactions-on-topic

When I withdraw 10 clams, my client software generates a random ID:  lkjsdfoiu
It then chooses a random blinding factor, which it keeps secret.
It then blinds the random ID using the blinding factor along with the server's 10-clam public minting key, producing (say): 897345jh
This random, and now blinded, ID is then sent to the OT server along with my withdrawal request.
Once the server verifies that it has successfully withdrawn 10 clams from my account, it uses its 10-clam private minting key to sign the blinded ID:  897345jh SIGNED: Server.
The server returns this to me. My client unblinds it using its secret blinding factor along with the server's 10-clam public minting key:  lkjsdfoiu SIGNED: Server.
When you ask, "Ah-ha-ha, but how can the server's signature still verify, when the ID has changed from 897345jh back to lkjsdfoiu again?" (since it was unblinded) ==> The answer is, that is the whole point of blind signatures. They still work, even after they are unblinded. That is the whole magic of digital cash. (I encourage you to Google "homomorphic encryption" to learn more about the applications for this concept.)
At this point:
1. My client now has a random ID with a valid server signature on it.
2. The server has no idea what that ID is, since the ID was blinded when it was signed.
3. Therefore I and I alone am the only person who knows that ID.
4. When I give the token to Bob who redeems it at the server, the server can see that the token is good (since it has a valid signature.) The server also knows that it's worth 10 clams, since only the 10-clam public key can verify that signature. But the server has no idea where it came from.
Once the server redeems the token for Bob, it records the token's ID (lkjsdfoiu) in a spent token database. This way, if the token is ever redeemed twice, the server can see that it is no good, because it has already been used.
OT expires and rotates cash tokens and mints, in order to allow the server operator to erase its spent token database every few months. Otherwise, the server operator would be forced to store a growing database forever, which is not feasible for a server operator.

If I am the only one who has withdrawn a 10-clam token in some time frame, can the server use this fact to determine that I am the one who paid Bob?

Let's say the mint expires every 6 months. If you are the only one to withdraw a 10-clam token in 6 months, then the server will know that 10 clam token came from you. Not because it has any way to link the IDs, but simply because you are logically the only person who could have withdrawn it.

There is technically no need for any accounts at all. As long as the server can verify its signature on your cash token, then the server can exchange it for a fresh one. And at that point, no one else has a copy of that cash but you, and it will be untraceable when it is spent. If a server runs in "cash-only" mode, then the token exchanges of the total user base become an anonymizing mix, in addition to the untraceability of the cash itself. (I2P is an essential layer, as are timing considerations, etc.)

My favorite part of OT is how the decentralized architecture(*) prevents double-spends, even when the OTServer itself (i.e., the bank) isn't trusted. The way this works is that clients don't connect directly to the OTServer, but rather use a public Distributed Hash Table (DHT) (such as Freenet or Tahoe-LAFS) as a middle layer. This means any attempt at a double-spend would be detected, evidence would be preserved, and the OT server could be held accountable.
Let's suppose Debbie Doublespend has 1 "clam" (an arbitrary OT currency token) on DebServer, an OT Server that colludes with her. Her goal is to fraudulently purchase two T-Shirts (worth 1 "clam" each), one from Alice, and one from Bob. Since there's only 1 "clam", DebServer has to trick both victims into thinking they received the same coin. So, the server signs two conflicting transactions, "D->A" and "D->B."
Without the DHT layer, Alice connects directly to DebServer and sees "D->A" while Bob connects to DebServer and sees "D->B". They both ship T-Shirts, so Debbie's plan succeeds. Eventually Alice and Bob go to spend their "clams", but clearly one of them will be unable to do so. The server would likely feign network problems or "play dead" rather than admit it double-spent. Unless Bob and Alice get in contact with each other and combine their receipts, they'd have a difficult time proving the server cheated.
With the public DHT in place, the two conflicting transactions would be preserved and propagated. Signed copies of "D->A" and "D->B" are prima-facie evidence of DebServer's involvement in a double-spend. Alice and Bob shouldn't trust an OTServer unless A) it has something to lose (i.e., an insurance policy against double-spends) and B) they use a DHT layer so receipts/evidence are preserved.
(*) this diagram is from vouchersafe, which has the same architecture as OT

Just wanted to comment on double spending. This is not necessarily true as it depends on various factors that may affect consistency. For example, one of the goals of bitcoin's consensus approach is to fend off race condition attacks, which is not something a DHT is meant so solve on its own; depending on network size and distribution, finality will always be a problem. Lastly, I am not deeply familiar with open transactions, but transaction malleability will always be a problem when there is some value to gain; thus another problem that must be handled.

newsflash: OpenTransactions doesn't have a double spend problem, thus there is nothing to solve.
'double spend' is a problem for P2P decentralized systems not client server systems.  Open Transactions is a client-server system.
Guys: look around you.  Do you see any serious adults gathered here?  That's because FellowTraveller is a joke.  It seems as though in his response above he is actually taking credit for Chaumian e-cash?  Not only did he not invent it, he didn't even implement it. https://github.com/benlaurie/lucre

"One of the core challenges of designing a digital currency involves
  something called the double-spending problem. If a digital dollar is
  just information, free from the corporeal strictures of paper and
  metal, what's to prevent people from copying and pasting it as easily
  as a chunk of text, "spending" it as many times as they want? The
  conventional answer involved using a central clearing house to keep a
  real-time ledger of all transactions. The ledger prevents fraud, but
  it also requires a trusted third party to administer it."

Open Transactions adheres to this traditional 'central clearing house' model.  To say that Open Transactions solved the problem of double spending is just absurd.  It's like saying an automobile has 'solved' the problem airplanes have of getting off the ground.  Much of these misconceptions are due entirely to FellowTravellers 'creative' use of language, complete absence of any legitimate peer review of his claims, and total lack of any actual users.
http://www.wired.co.uk/magazine/archive/2012/01/features/the-rise-and-fall-of-bitcoin
so one could say that Open Transactions is neither:
1) community generated
2) 'just works'
3) makes sense


text:
Using QR codes for bitcoin giveaway
Suppose I wanted to have a bitcoin treasure hunt, where QR codes were used. The first person who scanned a given QR code should receive some preset amount of bitcoins. Is this possible? (Preferably with as little need for knowledge on the part of the recipient as possible.) As a bonus, is it possible to have a single QR code to have a "pool" of 5 bitcoins it is attached to, give 1 bitcoin away per scan, but only allow scanning by unique devices. (ie; so 1 QR code could be used to claim 1 bitcoin for 5 unique devices) or easiest just to create 5 QR codes? Essentially the same functionality as the "send to QR code" in the Android client, only in reverse - (Scan QR code, and receive coins)

The easiest way to do this is to have the QR code be a URL. For example, http://www.example.com/bitcoingiveaway/E34IKJ. Just assign a unique code to each location, the E34IKJ in my example.
What that web page does is up to you. It has to track how many times it has been accessed, of course. The first time, it can send a form that allows a person to fill in some kind of identifier, which can be a Bitcoin address. You then send them the coins (or if using some kind of account, credit their account).
Making this work without the scanners having Internet access is much trickier. It can be done, but it would require your to control the scanning devices such that they included a time stamp, and there would be no way to reliably inform people whether they were first right at the point of scan.
Another possibility for the "first come, get coins" model is to have the QR code be the actual private key used to claim the Bitcoins.

I would prefer the latter (have QR code somehow be actual private key used to claim the bitcoins). However, ideally it would not require any manual steps of behalf of participants other than scanning the code with their client on either iOS or Android. Maybe we aren't there yet with the clients...but would be nice to be able to use QR codes for a one step receipt of bitcoins rather than just a one step send.

Then probably the best solution is to have the QR code be the private key, but also offer a web page where people can enter a private key and their Bitcoin address to have the balance transferred.

Depending on your knowledge level / abilities it may also be possible to grab one of the open-source Android clients and modify it to allow private key import via QR code scan.

QR codes are completely passive. They do not collect any information about the devices used to scan it.
If you want to set this up using only the Bitcoin network, you can create QR codes with private keys of Bitcoin addresses. The device used to scan the code should be able to import the private key and send its bitcoins to another address chosen by the user. The user should destroy the QR code afterwards to avoid stealing attempts by other users.
Having a "pool" of bitcoins in a QR code is not possible in this scenario.

Since mobile clients currently can not import private keys, another easy way to do this would be with Instawallet. People would scan an Instawallet QR code, open the url, type in their address and cash out the bitcoins.
But again, this solution does not allow for a bitcoin "pool". If you really want that feature you should design a dedicated website, like David Schwartz suggested in his answer.

I suppose I should have been more clear and asked, is there any mobile client that would support the following scenario using QR codes. Not the codes themselves.

@lemonginger It shouldn't be hard to implement, but I don't know of any mobile client that currently supports this.

@lemonginger As an alternative, you could encode an Instawallet URL.


text:
What is the "blockchain"?
What is the blockchain? I keep hearing about other "blockchain technologies", does this mean other cryptocurrencies or what?

By simply searching for 'what is blockchain' on Youtube you will find a decent amount of videos explaining it in simple terms. This is one of the better ones https://www.youtube.com/watch?v=KP_hGPQVLpA

The bitcoin block chain is the record of every bitcoin ever generated and every transfer of bitcoins from one party to another. Each crypto-currency that is based on the same type of technology as bitcoins has its own block chain. When people talk about other blockchains, they mean other currencies based on the same distributed currency / published transaction model (namecoin, Ixcoin, and so on).
The phrase "blockchain technology" is a reference to this model of published transactions to implement currencies with no central authority.

The Bitcoin "blockchain" is in effect the general ledger of Bitcoin. It is a recording of all transactions grouped into blocks. Each block represents approximately 10 minutes of transactions, and chaining them together has the effect of adding layer upon layer of transaction history.
Chaining blocks of transactions together by requiring a new block to reference the most recent prior block makes it harder to alter blocks in the past, since all subsequent blocks up to the current one would also have to be altered. In the Bitcoin blockchain, this is combined with a 'proof of work' that each block must include (a very large amount of work at this point), to create an unalterable history of transactions that is definitive.
New transactions can be evaluated against this general ledger with complete confidence that it is current, complete, and unalterable. With the entire blockchain publicly available, anyone can do this evaluation and prove that a transaction is valid or not.
It is likely that someone referring to "blockchain technology" is talking about any system that has this type of public general ledger.

I would suggest you to stop getting boggled by technical terms like ‘decentralized distributed ledger’.Blockchain is nothing but a long chain of blocks with transactions details recorded and new blocks added after each transaction is validated and approved.
Blockchain allows transactions to take place in a secured, transparent and decentralized manner.
When a sender transfers the information, he/she uses their private key and at the same time announces the transaction information over the network. This is when a new block is created that contains information like a digital signature, timestamp along with the receiver’s public key.
This helps all transactions over blockchain technology highly secured.


text:
Test vectors for bitcoin core (blocks and transactions) needed
I am looking for test vectors to test edge cases of an implementation. For instance:

"Unusual" blocks that made it to the blockchain
Non standard transactions that made it to the blockchain

Anything else that will help in testing the implementation. I have already obtained test vectors for secp256k1, so those are not needed. (If anyone needs them please comment below).

Block 501726? (Block reward)

@MCCCS good one. Any other examples?


text:
Deriving the Bitcoin address from the raw block script
I'm just starting to write a bitcoin script parser and I am wondering how to get the address from the genesis block? blockexplorer.com shows the coinbase value to be

04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

in the raw block data. But it also shows the receiving address for this transaction to be

1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

How can I derive the address from the raw transaction? I found a page in the wiki that talks about creating an address, but this seems like it is going about the process in a back-to-front order. Surely the address must exist first before the raw block can allocate the mined coins to it? Otherwise, the blockchain would simply have to allocate mined funds into the ether. The receiving address must have been known to the mining algorithm before it generated the very first mining transaction.
Please could someone walk me through the steps of deriving the address from the raw transaction script.

Surely the address must exist first before the raw block can allocate the mined coins to it?

No. The network has no concept of addresses. When you send money, you're actually sending funds to a public key or public key hash. The Bitcoin address format you're familiar with is just a way of representing public key hashes in a human-readable way.
This is especially true of generation transactions, which typically send money directly to a public key. Bitcoin-Qt normally doesn't calculate or display the address in such cases, though it's still possible to calculate it.
The "coinbase" doesn't contain the address or public key. That's just mostly-arbitrary data. It contains the block height, extraNonce, etc. The address is in "scriptPubKey". In the genesis block's generation transaction, the scriptPubKey is:
04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG

This is a direct-to-public-key transaction, not a normal address transaction. 04678... is the uncompressed ECDSA public key. Follow the instructions on that wiki page to get the address, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. But again, this transaction doesn't contain this address, or even its base58-decoded (binary) equivalent. The address is just a way of representing the public key.

Small nit: signatures are encoded using DER, but public keys aren't. The standard for encoding public keys is described by SEC1 (http://www.secg.org/index.php?action=secg,docs_secg).

Another nit: from the point of view of the network rules, the output of the genesis block is actually unspendable (intentionally or due to a bug), so its address is really irrelevant.

@PieterWuille I fixed the DER bit, thanks. Even though the genesis transaction is unspendable, I think that its address is not totally irrelevant. For example, you can use it to easily see that people have sent BTC to the public key listed by Satoshi in the genesis transaction. This is interesting info.

i don't think my question "Surely the address must exist first before the raw block can allocate the mined coins to it?" was clearly phrased, so i have updated it to explain better what i mean.

The payout address is indeed known before block mining begins, by the way.

yeah, that's what i meant.


text:
Why have prices fallen so drastically around October 2011?
Any idea why bitcoin prices have fallen so in September and October of 2011?  It seems like back in August, one bitcoin cost about US$17, whereas in late October, it's just somewhat over US$2.

Possible duplicate of http://bitcoin.stackexchange.com/questions/1613/is-it-possible-to-pinpoint-what-caused-the-drop-in-value-between-july-and-septem

@Thilo, I agree that this is a duplicate but since there is just one close-vote I won't close it just yet. People who want to keep it, please add a comment here explaining why you don't think that it should be closed.

@D.H. I agree that these could be duplicates, but the other question seems to be more related to a manipulating bot while this is strictly about the price drop itself.

@nmat, Yes there is that slight difference. I suggest then that we keep both but that we edit the other one so that it's more clearly about just about the manipulating bot. Good?

Works for me @D.H.!

One thing a lot of people fail to notice is the decreasing volume at the exchanges. If we look at the USD volume - and not at the bitcoin volume, which is misleading because bitcoins are now worth much less - we can see a spike in June and a decrease afterwards:

The news reports in June attracted lots of people who were curious about bitcoin. A part of these people left and the market size is now coming back to April/May levels. As a consequence, there is much less money being traded. However, we still have 5 new coins being produced every minute and lots of miners who want their invested money back.
The current price is a natural consequence of high supply and low demand.

People are not holding their bitcoins as long.
I've speculated elsewhere that this might have something to do with the hedging mechanism implemented by Silk Road.
We all want people to use bitcoins for transactions; unfortunately they only have value in proportion to the length of time for which people hold them.  If everybody bought bitcoins (using fiat) the instant before they needed to use them to buy something with BTC and sold bitcoins (for fiat) the instant after they had sold something via BTC the demand for BTC at any given instant in time would be both (a) incredibly small and (b) very unstable, causing the price to crash and then fluctuate wildly (in percentage terms).
In one explanation, money has three roles: (1) store of value, (2) unit of account, and (3) mechanism for transmitting value.  People talk a lot about promoting the "bitcoin economy" (#3) but unfortunately without enough people using it as a store of value (#1) the price will crash and then fluctuate wildly, causing it to no longer be viable as a mechanism for transmitting value (#3).

Nice logic... +1'ed. I still think though that speculators that were in the game for short term profits were largely responsible for the movement over this period, so "Speculation" might be a more accurate answer to the question. Hopefully my answer will still be of value to some people anyway!

-1. Is there some reason you can't mention SilkRoad?  Many users would not know what "certain taboo website" refers to.  Silk Road is a reaility.  While questions on SR are offtopic for this board it can be mentioned in an answer especially when it is a central part of your theory.

+1 for the analysis. Please edit to include a reference to Silk Road (if that is what you mean) to avoid doubt.

theUnhandledException, feel free to edit my answer.

The answer to this other question summarises the factors that affect the price of bitcoins in a general sense. However, your question covers a specific period. According to Bitcoin Charts the price peaked at around US$30 around Jun 8th 2011, and was around the $17 mark in mid-July. It's certainly a substantial drop to now (Oct 20th) be under the $2.50 mark.
Speculators appear to be the primary driver for the peak at US$30. The purposes that bitcoins were created for are mainly for trade, but the growth in trade has been modest and couldn't explain the big spike in price prior to the peak. You could say that the underlying value of bitcoins as a currency (based on the number of people/retailers using it for trade) was exceeded and is resettling.
Though bitcoins are also intended to be useful as a store of value (which is why there will only ever be a limited number in circulation), most people probably don't have enough faith yet to put their life savings into Bitcoins, so I don't think that is affecting the price substantially.
The constant supply of 50 bitcoins per block to miners may help explain the steady decline since the peak, as many miners probably sell off their bitcoins regularly to pay for the investment in hardware. There have also been a couple of very large sell-offs of bitcoins on MtGox (9th Sep, 17th Oct in particular) which could potentially have been holdings of early adopters, or speculators that chose to reduce their investment.
As the price drops different factors come into play - less efficient mining hardware gets switched off, and perhaps increases the proportion of active miners who have faith in the future of bitcoins (and will hold on to them). If the price starts to trend upwards again, you might see speculation driving another high peak - this is normal for speculative markets and is likely to keep happening.
This question has some great comments on speculation.

Unfortunately "using bitcoins for trade" does not lead people to hold bitcoins; they exchange them for fiat, send the BTC, then exchange them back for fiat.  Net effect is that the number of BTC demanded at any instant in time is very, very small and very volatile.

You're right, but they do hold them for a short time. I wonder how long it will take until it become a major factor in the value?

@eldentyrell the length of time a person keeps wealth in bitcoins is directly linked to the utility of the Bitcoin currency.  Currently there are limited uses for Bitcoin and high volatility so people hold them for short periods of time.  There are costs to doing that.  Exchange fees can be 1% to 2% round trip and the fiat -> bitcoin -> fiat trip can be rather slow.  There will need to be more utility in holding bitcoins longer such as more merchants accepting bitcoin for that to change.

Speculative Bubble.
Simple like this:
I watch a lot of markets charts for years and the Bitcoin chart looks pretty normal to me. Oh, and the trend is continue going down right now.
And this blog have Bitcoin chart analysis that confirm what I am saying, just to give a second opinion. (I found this right now)

There's no information here, especially not anything that's not already in one of the other answers.

I disagree. Lots of information here, and the answer is focused. One image worst million words. No problem. I respect others opinions. =) Anyway, I tryed to improve a little my answer. Thanks for the comment and votes.

The BitCoin is made up currency and thus there is no trust in it.  The value will bop up and down based on whims and popularity.

Hello DarthDiggler and welcome to the StackExchange. Please try making your answers objective and related to the question asked.


text:
How to unlock private key of bitcoin

I need help on how to get the private key....i  have that much on my account and i want to cash out very soon

Where did you make your original bitcoin wallet? if you do not hold the private keys you do not own the bitcoins... just saying

People with 86 million dollars generally don't need to ask this.
People who have been tricked by con-artists are the sort of people that usually ask this.
That looks like a "blockchain" wallet.

How to unlock private key of bitcoin

If you have forgotten a password needed to "unlock" your wallet, you have lost all your bitcoins and will either never get them back or will spend many months and tens of thousands of dollars in the attempt.
If you are having problems with your account at blockchain.com you need to contact blockchain.com. They are a Luxembourg company. See https://support.blockchain.com/hc/en-us - If you have been tricked, they won't be able to help you.

I  need help on how to get the private key

You can follow the guidance on blockchain.com's support web-pages
Exporting the private key. The example given is for Ethereum but you should choose "Bitcoin" instead.
If your wallet doesn't have a private key for the bitcoin-address holding those 86 million dollars worth of Bitcoin, it means you have a watch-only address imported into your wallet.
If someone tells you that you need to pay them to release the private-key, it means they are a con-artist tricking you into giving them more money.

Backups
If you were not tricked but didn't make a backup of your wallet and a written backup of your password, private key or a written backup of your recovery phrase, and have lost or forgotten them -- you have been very negligent.
Recovery may be very very difficult, time-consuming, expensive, or quite likely, impossible.
Scams by con-artists
If an online friend/miner/consultant set this up for you, it means you are the victim of a scam.
If so, it is quite possible that the money you are looking at is money in the wallet of some innocent third-party whose bitcoin-address has been imported by a scammer into your wallet as a "watch-only" address. In which case it was never your money and any money you sent to the scammer was pocketed by them completely separately.

Useful Links
Some other questions whose answers might be helpful in understanding your situation.

Watch-only addresses

Watch only wallet
Reg: Watch only Address
I have watched addresses in my wallet..how do i use them?
Unlocking a Private Key from watch status

Private keys

i lost access to my bitcoin
Why were private keys made unrecoverable?
Where do I obtain private keys?
How to retrieve unclaimed BTC for wallets whose private key is lost

"Unlock private key"

Are there Bitcoin password crackers I can use to recover forgotten passwords?
I forgot my bitcoin core passphrase. Is there anyway I can recover?


text:
How are MtGox options going to affect Bitcoin price volatility?
MtGox plans to introduce Options, would Bitcoin price become more stable or it would just hedge risks?

probably off topic and too speculative for Q&A site. More a discussion question.

Probably both, though the effect may be pretty small.
Arguably, the most prudent use of options is reducing risk.  For example, a merchant with accounts receivable in Bitcoins would want to protect the value of the fixed amount of BTC he will receive.  Options can limit his downside risk.  At present the price volatility of Bitcoins hampers its use for commerce, since the value of an asking price in BTC varies so much from day to day.  With options to reduce risk, more businesses will be willing to accept Bitcoins, bringing more liquidity to the Bitcoin "ecosystem".
Increased acceptance of Bitcoins and increased "money supply" are more likely than options to stabilize prices.  They would reduce price fluctuations caused by thin trading.  The same effect is seen in the stock market where relatively unknown stocks undergo drastic price swings due to somewhat small trades.  Conversely, a widely traded stock exhibits much less volatility.