text:
Where does Coinbase buy coins from?
When we buy coins from Coinbase, where do they get the coins from?

I found a comment thread with speculative answers: http://www.reddit.com/r/Bitcoin/comments/1hb4df/coinbase_pricing_mystery/

Coinbase is built on top of Bitstamp. They may work with other exchanges now, but they are (and used to be) very tightly coupled with Bitstamp.
There was an exploit where someone discovered that Coinbase's price was set to the last sale price on Bitstamp.  Basically, this person would sell a small amount of Bitcoin for much lower than market value on Bitstamp.  Coinbases price would match that, where he'd buy again.
Coinbase does operate their own reserves as well, which (as others have pointed out) are used when Coinbase customers buy and sell within the site.  Their prices are set using a weighted average of multiple exchanges.

Thanks for solving the mystery. I had a bot running and noticed infrequent 30-60 second wild swings and was wondering why.

It's most likely that Coinbase keeps a reasonable reserve of both dollars and BTC on hand, to instantly provide either USD or BTC to clients.
They probably have a "treasury manager" on staff, whose job is to buy BTC at the lowest possible prices and sell BTC at the highest possible prices on various exchanges or dark pools, to keep the reserves topped up in cases when daily Coinbase usage is very one-sided. But in general I'm sure they greatly prefer to meet demand internally to replenish reserves vs. having to pay a third-party fee to get or sell BTC elsewhere, unless their treasury manager sees a "screaming deal" on an exchange (e.g. current coinbase price is $800 and they can get some for $600, or sell for $1,000).
In the past, you'd sometimes get the message that they're "tapped out", meaning trading was so one-sided they used up their daily reserves, and the EFT transactions of the Coinbase users hadn't settled yet. For example, say they have 1,000 BTC in reserves, but 1,500 users all want to buy 1 BTC each that day. Coinbase would fill 1,000 orders, but it wouldn't yet have the cash from the 1,500 user bank accounts to go buy more BTC on the exchanges. That is happening less and less often (as Coinbase gets deeper and deeper pockets).

From Brian Armstrong, Coinbase Agent, via the coinbase support site, 11 Nov 2012:

We integrate with a variety of exchanges and also hold our own reserves. When you sell your bitcoins for USD we usually sell them to other Coinbase users at some point down the line (this is where our reserves come from), but we may cash them out if needed. In general, our goal is to abstract away some of the complexity so it's a simpler process for our users. What we have now is a good start but not finished by any means. Hope it helps!

"Cash them out" has to mean selling them to someone.  Does it mean selling them to someone other than coinbase customers?

Yes they mean selling them out to someone else at one exchange.


text:
Can anyone explain me why I can not buy coins at the advertised price
Right now I see on mtgox the lowest price as 105$ and the last price 165$ but when I want to buy by the price of 105$ I can not do so, the only option is 165$.
Is there something I understand wrongly?

That was the lowest price in the past day, not the market price.

So, that number "low" and 'high' on top of the site is just showing the highest and the lowest price during one particular day. Can you help me to tell where can I find the market price?

"Last Price" is the market price on the Mt Gox site

@Ben, what do you mean by "past day"? Do you mean by GMT time, or the past 24 hours?

@Pacerier past 24h AFAIK

@makerofthings7 not exactly what he needs to know. If he means to buy bitcoins, for him the last price is irrelevant: what he needs to know is the lowest sell (unless the amount he means to buy is very high).

Look at this chart: https://data.mtgox.com/api/0/png/24hours.png?Currency=USD The bars represent the current buying price, and the current selling price.
Right now there's a big difference between the price that you can sell bitcoins at, and the price that you can buy bitcoins at. This is called the spread, and it occurs because people aren't sure how to value bitcoins right now.

Cool, thank you. I know that it sounds stupid, but I thought that this is a boxplot which summarize statistics about the selling price.

You can only buy Bitcoins at a price if someone is willing to sell them at that price. That a particular price is reported means something, but not necessarily that anyone is willing to sell or buy at that price.
In a healthy market, the buy and sell prices should be almost the same and there should be plenty of people willing to sell or buy at very close to the price at which the last transaction occurred. However, in this particular case, technical problems at Mt Gox caused the market not to be healthy and this general rule did not apply.
In any event, the "low" price just reflects the lowest price at which a trade occurred at a particular exchange in a particular time interval.

source: Stack Exchange

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

sort: votes


text:
What is the difference between a market and limit property in the MTGox API?
I'm using the MTGox API to get data about historic trades.
When I run https://mtgox.com/api/1/BTCGBP/public/trades?since={trade_id}, I get the latest 500 trades since that {trade_id}.
Now I have for example these two trades returned:
Trade #1
{
    "date":1342135345,
    "price":"4.77728",
    "amount":"5107.98029213",
    "price_int":"477728",
    "amount_int":"510798029213",
    "tid":"1342135345801755",
    "price_currency":"GBP",
    "item":"BTC",
    "trade_type":"bid",
    "primary":"Y",
    "properties":"market,mixed_currency"
},

Trade #2
{
    "date":1342136454,
    "price":"4.78",
    "amount":"0.02000488",
    "price_int":"478000",
    "amount_int":"2000488",
    "tid":"1342136454726203",
    "price_currency":"GBP",
    "item":"BTC",
    "trade_type":"bid",
    "primary":"N",
    "properties":"limit,mixed_currency"
},

Note the different properties: "market,mixed_currency" & "limit,mixed_currency".

What is the difference between a market and a limit property? What do both mean? (I couldn't find it here https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1)
what does it mean for a trade to be mixed_currency?
Bitcoincharts does seem to include all trades regardless of the limit/market/mixed currency, is this the right approach if you want to have a honest view of all markets?

A limit order is an order to buy or sell at a specific price or better. As in "sell these coins if I can get at least X USD per bitcoin."
A market order is an order to buy or sell at the best available price. As in "sell these coins for whatever people are willing to pay right now."
Not 100% sure about this, but I believe mixed_currency means the buyer and seller are using different currencies. If you buy bitcoins using EUR from someone selling for USD then MtGox will do a conversion.
And yes, the best view of the market would be with all trades included.

Actually, this doesn't quite answer the question in the given context. Yes, market vs limit is explained, but what does it mean in the context of a MtGox trade entry. Isn't there typically a market order and a limit order that are matched in order to create a trade?

@DustinGraham quite obviously it means that that trade was done with a limit order or with a market order. Limit orders stay in the order book if not cleared immediately, while market orders are always filled unless the market is empty.

Quite obviously. :)

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


text:
Transaction Records of MtGox?
When transactions are done on MtGox.com, MtGox Live will reflect the transactions by showing "popups" (top-right corner).
Does MtGox provide a "history record of transactions" which show us information of all transactions (timestamp and amount traded) done in MtGox?
I've looked into the HTTPv1 API but there doesn't seem to be an option to do so.

EDIT: I think I found what you are looking for here: https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Multi_currency_trades
Also you can consider following the Streaming API which lets you stream all activity in real time: https://en.bitcoin.it/wiki/MtGox/API/Streaming
If the API does not offer this option, I don't think they offer it in an other format.
Although, look at f.e. this page of BitcoinCharts.com: http://bitcoincharts.com/markets/mtgoxEUR_trades.html
They seem to have access to this data somehow. I see that MtGox publishes its full depth. Maybe BitcoinCharts just checks the depth at regular points of time and calculates the trade history from the difference.
You could consider doing the same for your purpose.

As said on https://en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Multi_currency_trades you can use:
https://mtgox.com/api/1/BTCUSD/trades?raw
or
https://mtgox.com/api/1/BTCUSD/trades?since=0
to get all the historical data.
There's also a non-official Python script (using this API) and a SQLite database with all the historical data, you can find it on:
http://cahier2.ww7.be/bitcoinmirror/phantomcircuit/
The 167MB SQLite database should already have all the data you need, and the Python script in the same directory allows you to update it in real time.

btw the wiki seems to be silent about the "properties" key. Do you know what "properties":"limit,mixed_currency" mean?

mixed_currency is about the kind of trades you want to get, for example only USD<->USD trades, or also trades that matched other currency orders ( USD<->EUR for example ) with the 2.5 % conversion fee added

does anyone know who the author of the SQLite mirror script is?

phantomcircuit developped the script long ago, I m just hosting a mirror of the script and updated database


text:
Is the "official client" crash-resistant?
I'm running the "official client" (12 MB zipped version) on a Windows platform.
What are the risks (to my wallet) when the computer crashes due to overheating, BSOD, power failure, etc?

Is the "official client" crash-resistant?

Yes, mostly, but there are some things you should know.
Your wallet is stored as a separate file. Your wallet file gets changes written to it as new blocks are received and transactions are made, etc. The chances of a crash occurring during a write to your wallet are probably minimal, but you should have a backup of your (encrypted) wallet anyway. This is by far the most important point. Once your wallet is encrypted with a very strong password (the client provides this function), you can store copies of it in insecure locations, so you always have a copy somewhere - store it in gmail, send it to your family etc. You should only need to make an additional backup every 50 transactions. Bear in mind the receiving address descriptions aren't encrypted though. Running the client with the -rescan option may fix minor issues.
The client will refuse to work if a failed attempt at double-spending is detected, but that's not really what you're asking. Besides, there appears to be a fix for the problem.
The block chain takes a long time to download, so there is a risk that a crash would required you to download it again. If the client is closed (gracefully) while it is downloading the block chain, it resumes where it left off with no issues; I would guess it would probably do the same thing in the event of a crash, but it's only your copy of the block chain that's really at stake.
Realistically, once you've got your wallet encrypted with a strong password and backed up in multiple locations, the biggest remaining risk is from theft through a virus or malware. Quote from Gavin Andresen: "If your computer is infected, then it cannot be trusted, and there is no software in the world that can keep your bitcoins safe if they are stored on it."

"I would expect your wallet file only gets changes written to it when you send bitcoins or create a new address".  The wallet also includes your address book and transactions affecting your balance.  So receiving funds or labelling addresses causes a wallet write too.

Have you got a reference for that? It would seem unnecessary to alter the wallet when funds are received; that information is already stored in the block chain.

@HighlyIrregular Hmm, I'm not afraid of my computer being affected (that's a different issue), but more of whether the client itself is built to be crash-resistant (like Chrome) or crash-means-good-luck (like MS Word).

@HighlyIrregular Did you ever hear of the -rescan option to bitcoin-qt?  It's used when the wallet is missing some transactions that are in the blockchain, and causes bitcoin-qt to rescan the blockchain, copying relevant transactions into the wallet.  http://bitcoin.stackexchange.com/questions/853/what-do-the-different-dat-files-contain/854#854 is written by one of the client developers, if you need a reference.

@ChrisMoore, thanks! I learnt something today! I've updated my answer too.


text:
What does this phishing website compromise?
Earlier this day, I have received an email saying that there is a buyer for my localbitcoins advertisement:

However, the https://localbitcoins.com/ads/37726/103702 link shown actually links me to:

http://mandrillapp.com/track/click.php?u=30106122&id=8f52703cd0ec4b2b81e069630069dbdc&url=http%3A%2F%2Fllocalbitcoins.com%2Faccounts%2Flogin&url_id=ad428ed9d64304239644387c1388db2f686a98ca

I've accidentally clicked it and it brings me to a phishing website which looks identical to localbitcoins. The phishing website is hosted on http://llocalbitcoins.com (whois record). Notice that there are two "L"s in the domain name.
Wwhat does the hidden link do? Now that I've clicked the link, what can happen to me?
I've changed my password since then. But what else can I do to protect myself?

LocalBitcoins provides two-factor authentication which protects you against all kinds of phishing attacks. Even if the attacker gains access to your password by phishing link or malware (e.g. infected Windows machine), they cannot access your one time codes needed to login and do transactions.
LocalBitcoins recommends you to enable two-factor authentication on your Wallet page (if you have bitcoins) and every time in your user profile navigation bar unless it is enabled.

There are two different methods for two-factor authentication

Mobile app (Google Authenticator) - works on iPhone, Android and other smart phones
Paper codes (you print a set of one time codes)

Both options can be enabled from the link shown in the screenshot above, or from this direct link. For both options, you need to also make sure you have a proper backup as in the case you lose access to your mobile phone with two-factor authentication app you cannot no longer login to LocalBitcoins.
To receive the email in the question the user probably has published email in an advertisement, LocalBitcoins forums or given it to a malicious trader. LocalBitcoins recommends you do not do communications or trade deals off-site outside LocalBitcoins messaging system.
In the case you have already given your password to a phishing site

Change your LocalBitcoins password immediately
Enable two-factor authentication as instructed above


text:
What's the advantage of using non-truncated mining targets?
Bitcoin Wiki (Difficulty):

The highest possible target (difficulty 1) is defined as 0x1d00ffff,
  which gives us a hex target of
0x00000000FFFF0000000000000000000000000000000000000000000000000000

It should be noted that pooled mining often uses non-truncated
  targets, which puts "pool difficulty 1" at
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

From what I know, using non-truncated targets puts the target at a higher number than the network would accept. In other words, we may end up finding a hash accepted by the "pooled mining" (lower than non-truncated), yet rejected by the network (higher than truncated).
Why do people use non-truncated mining targets?
Why not simply use the actual truncated targets so that we can have a more accurate picture of the network and avoid overheads incurred as such?

You are right, it could happen you are finding a hash that meets the pool target but not the highest possible target. But because the difficulty is way higher than one, and therefore the share wouldnt finish the block anyway, its not in their interest. You have done your work and you will get your share. They just make it a bit easier for you, by passing a higher target than possible.
Another possible reason:
Comparing a hash to the highest possible target would take more time, because you have to check the whole hash (checking the zeros at the end as well). With the non-truncated target you only need to check until the first F occures because than its at least equal or lower.

Right, but only a mere 0.00000001 of hashes  got the first "F" matching. Trivially speeding up this  0.00000001 of hashes is hardly going to improve running speed...


text:
What can an attacker who controls majority or all of the full nodes do?
What happens when a strong attacker has control of majority or all of the full nodes?
What damage can he do and would they be reversible?

"Completely Vulnerable" is a pretty bold statement.  Do you think full nodes could re-write old transactions? forge transactions?  replay previous transactions? Create new money?  You should clarify your idea of completely vulnerable

@abelenky, Right.. I've replaced "completely vulnerable" to "vulnerable".

Just full nodes, no mining power?

Here is an additional answer about what you can do if you control all fully validating nodes (but not necessarily all nodes that don't validate):
Anything
Bitcoin's security rests on auditing by full nodes. It is directly what prevents them from accepting fraudulent payments, and indirectly what makes it uneconomical for miners to produce invalid blocks (which in turn could be used to defraud non-validating clients).
If you have control over all fully validating nodes, you can effectively set the protocol rules at will. Including but not limited to theft and printing money out of thin air (beyond what the subsidy schedule currently permits).

how does the "printing money out of thin air" work? (Assuming the attacker gets to control all full nodes for 5 yrs.)

By creating a transaction that prints money out of thin air, and modifying all his nodes to accept it. As full nodes are the only ones that can validate, nobody else would even notice.

Assuming that you have majority control of full nodes and no control of mining. Here are few attacks that can be done:

Double spend even after confirmation: Don't relay the blocks that build upon the block (in which you spent coins). Instead relay any other forks on the blockchain to make them the longest chain
Fool SPV clients: SPV clients like electrum, multibit connect to full node for information. You can send them fraudulent transactions/chain by building headers on very less difficultly level
Force miners/users to pay you: Relay only those blocks/transactions that send your address some bitcoins. Non paying blocks/tx will be delayed through the network or will be orphaned. People wanting fast transactions will be forced pay you a bribe

During the moment of control, they can do at least the following:

relay transactions selectively.
this means they can choose to not relay transactions which are valid and therefor censor users of the network.
relay blocks selectively.
this means they can choose not to relay valid blocks by miners, as well as choose to relay invalid blocks, or blocks containing invalid transactions. it allows them to deny new nodes the current blockchain and the history it carries, and could even supply new nodes with an entirely different chain.

if 100% of all full nodes and all non-node storage of the current chain is lost, then they effectively control the current chains history.
however, since bitcoin is open to participation and holds decentralization as one of its core values, it is practically impossible to gain control of 100% of the nodes without new participants entering the network.
if less than 100% of the full nodes or all non-node storage of the current chain is compromised, the netwok can revert back to its last non-compromised state as new participants set up new, uncompromised, nodes.
attacking the network by controlling the nodes and taking actions that hurt users would also lower the utility of the network and that would lower the value of the tokens on the network, so it might not be economically feasable to do in the first place.

Re "without new participants", but there aren't many full nodes in the world. The cost is prohibitive, and will get even more so as time passes.

there is thousands of full nodes online right now, and as far as I know, computer hardware has so far gotten cheaper faster than cost of a full node has gone up.

What can an attacker who controls majority or all of the full nodes
  do?

TL;DR Nothing dangerous.

Eclipse attack

Can you please share more info eclipse attack? @MCCCS


text:
How are mutated transactions prevented from getting relayed?
Quoth Bitcoin release-notes-0.9.0.md:

This release contains a few fixes for transaction ID (TXID)
  malleability issues:

-nospendzeroconfchange command-line option, to avoid spending zero-confirmation change
IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions
Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they
  spend the same outputs.
Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.
New option: -zapwallettxes to rebuild the wallet's transaction information

What does "transaction rules tightened" mean and how does it prevent relaying and mining of mutated transactions?
Since mutated transactions are also valid transactions, how can the client tell original transactions apart from mutated ones?
Are powerful adversaries still able to abuse this feature after the update?

Transaction malleability is prevented by selecting one canonical representation of every transaction and making every other representation nonstandard. That is, of all possible transactions one transaction can be mutated into, exactly one is considered "original", and other representations are not relayed.
Originally, Bitcoin could accept different representations of the same data. For example, it were possible to represent the same number both with and without leading zeros, producing equivalent transactions with different binary representations. Now, a transaction would only be considered standard if those numbers are represented using a specific number of digits, so it is now impossible to write the same number in different ways.
However, this rule is not enforced on transactions that are already in a block (since otherwise it would be a fork), so a powerful adversary can still push a mutated transaction into the network by mining it himself.

How can all the clients agree on which transaction to be considered original?

@Pacerier Originally, the rules for representation of signatures were pretty lax. For example, it were possible to represent numbers both with and without leading zeros. This means that the same number could be represented in several different ways. New rules require all those numbers to be represented using a specific number of digits, so now there is no leeway. Other rules are similarly tightened.

Is it merely a reduction in the probability of possible representations, or does the update ensure that only one representation is possible?

There is only one "canonical" representation for "standard" transactions. Unfortunately, not all current clients create canonical transactions. So, it is not possible to check for some transactions are they malled from canonical representation or created by old clients.


text:
What is the point of SIGHASH_NONE?
If I understand correctly, SIGHASH_NONE in the output input signature means that spender of this output doesn't sign his outputs. But doesn't that mean that the spending transaction is by design insecure? E.g. a malicious miner could switch the outputs to his addresses and put a modified version in the block.
Am I missing something? What is SIGHASH_NONE intended for?
Edit: Now I understand why I was confused! The SIGHASH_NONE is in the input signature, not in the output. Somehow I thought it's an attribute of the output, and it didn't make sense to me why the previous spender would be able to decide how the next transaction should be signed.

note that the sighash byte appended to the signature cannot be modified by the miner. eg the miner cannot change a sighash_anyonecanpay into a sighash_none. this is because even though the signature itself does not form part of the message (txhash) to be verified, the sighash byte actually does form part of the message and so it is verified in the signature. more detail here

The bitcoin wiki OP_CHECKSIG page describes the behaviour of SIGHASH_NONE like this:

The output of txCopy is set to a vector of zero size.
All other inputs aside from the current input in txCopy have their
  nSequence index set to zero
Think of this as "sign none of the outputs-- I don't care where the
  bitcoins go."

The contracts page also talks about SIGHASH_NONE:

SIGHASH_NONE: The outputs are not signed and can be anything. Use this
  to indicate "I agree to put my money in, as long as everyone puts
  their money in, but I don't care what's done with the output". This
  mode allows others to update the transaction by changing their inputs
  sequence numbers.

If I sign a transaction where all the inputs are SIGHASH_NONE then a miner can change the outputs to whatever he likes.  If any of the inputs are SIGHASH_ALL then the miner can't change the outputs.  So a group of people can each sign their own SIGHASH_NONE input to a transaction, send them privately to the coordinator who signs his own SIGHASH_ALL input before publishing the transaction.  That way the individual contributors don't need to know the destination address so long as they trust the coordinator.

One should note that the ability to add additional inputs depends on the SIGHASH_ANYONECANPAY bit being set as well.

This is discussed here.

http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/11/15/2#l2156425

i.e., that would require AnyoneCanPay to be vulnerable as you describe it.

So... as long as the spending transaction has other inputs, it's safe. But a spending transaction with only one input would be vulnerable, even without AnyoneCanPay, right?


text:
Why do some generation transactions use pubkey, instead of hash?
At BlockExplorer I can see that (edit: some) generation transactions use a pubkey in the script (<key> OP_CHECKSIG), while ordinary transactions use address/hash (OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG). Why don't generation transactions use hash as well?

Pubkey transactions use a little less space in the block chain overall (if no pruning is used), so you might as well use them when you can.
I think that Satoshi's main reasoning was as follows, though:
Satoshi originally expected that most transactions would be pubkey transactions: the sender would contact the recipient directly and retrieve a public key to send funds to (the protocol has commands for getting this info from recipients, but it's almost never used nowadays). Bitcoin addresses were just a "hack" useful for sending BTC to offline recipients. You know your own public key for use in generation transactions, so addresses aren't necessary and Satoshi avoided using the "hack".


text:
How to encrypt an existing BIP-39 mnemonic with a password without changing the seed?
I know that you can create a Mnemonic + PW to encode a seed to derive keys. What I want is to encrypt an existing mnemonic with a password that generates the same seed as the unencrypted mnemonic.
Background is, that I have an existing seed sentence that I want to encrypt into an new mnemonic without changing the underlying entorpy.So I can replace my existing paper copy with an encrypted one.
Is this possible already? Or any reasons why it does not make sense at all?
Update
I came up with an proposal implementation:
https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go
It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic. I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.

Why not encrypt it normally, then decrypt before use?

Since there is no "normally" - when encrypting it into some random looking data, it does not have the same backup properties (e.g. error correction). I want to store a mnemonic which needs an additional password to get the "real" mnemonic.

I came up with an proposal implementation like this: https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go
It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic.
I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.

Your use case is unclear to me, it seems you want seed(phrase) == seed(enc(phrase, pw))?

@RedGrittyBrick I guess yes. Take a look into my implementation, it solves what I want.
More like: seed(plainPhrase) == seed(decrypt(encPhrase, pw))

First things first. There are 3 values in play;

The entropy
The mnemonic phrase
The seed

The entropy is just random data.
The mnemonic is the same random data, but mapped to a wordlist plus a checksum.
The seed is derived from the mnemonic and a password.
A mnemonic can be converted back to the entropy that was used to create it.
But it is the seed that is used to generate your wallet addresses.
When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2.
It is impossible to find the mnemonic+password for a given seed, and therefor it is impossible to find the mnemonic for a given seed and password.
It is what pbkdf2 was explicitly designed for.

Hey, I do understand this. There is a specification to add a "passphrase" to the mnemonic phrase, but as you said, it changes the seed. What I need is to encrypt my mnemonic phrase for a paper backup that someone might find, with a password I have in mind without changing the already used seed.
That's what my implementation does.

"When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2."
That's why the existing password scheme in BIP39 does not work for me.

You can encrypt the mnemonic whichever way you want, but it is not BIP39 compliant and can only be decrypted by your own implementation.
I would rather encrypt the mnemonic using an industry standard cipher and store the ciphertext instead of the mnemonic. Store it as an qrcode instead of text for easier recovery.

Well, you are right. One would need to extend BIP39 which probably will not happen. But I like the idea of having the result at least look like BIP39 so you have plausible deniability and someone who finds my backup can just access some empty wallet (could even be filled with some small amount of coins). In the end my implementation does use industry Standard cipher.

Thats exactly the design of the current BIP39 passphrase; generate a new mnemonic. Use one passsword to generate a wallet with a tiny amount of coins. Use another password for your actual wallet. Should you ever be required to give up your password, give the first one.  But the result of this design is you can not change the passsword afterwards.

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


text:
Will it be possible to buy shares online using bitcoins in a financial market?
Do you foresee people one day people trading  securities,bonds,stocks or currencies with bitcoins.I would like to buy a share lets say from Microsoft with bitcoins and have the value of it remain in  bitcoins instead of normal currency.
Will that be feasible?
Are there any sites or tor sites that offer such a platform.If so could you provide me with the such link.
Thanks.

Likely, but this is a speculative answer.

Anything that can be done with a traditional currency can be done with Bitcoin. Be it buying groceries, shares, stocks, bonds, or anything else.

"I would like to buy a share lets say from Microsoft with bitcoins and have the value of it remain in bitcoins instead of normal currency."

Well, in that case you would be trading MSFT/BTC, so if the value of BTC keeps rising with comparison to MSFT and you're holding MSFT, then you will lose BTC. For now it doesn't seem like it will be worthwhile to do such a thing.

If everybody knew that the value of bitcoins was always going to go up, then everybody would be buying as many as they can and the exchange rate would skyrocket. That's not happening.

@HighlyIrregular I didn't say that the value of bitcoin will always go up, but for now it's looking like it will continue to go up. At the end of the day it's just a matter of speculation I guess...


text:
Who is Satoshi Nakamoto?
Who is Satoshi Nakamoto? I have heard about him and read his paper.
Why is he no-longer publicly involved in Bitcoin?

Voted to close as off topic. David Perry's answer covers pretty much all we realistically can know about Satoshi. This forum deals with issues arising from Satoshi's creation, not the person.

There's also a history of bad things happening to people who invent or promote disruptive technologies. Phil Zimmerman, for example.

Nobody knows who is Satoshi yet

Satoshi Nakamoto is the elusive and private creator of bitcoin. In October 2008 he published the paper Bitcoin: A Peer-to-Peer Electronic Cash System (pdf warning) which is the basis of the bitcoin client/protocol. He has stated his nationality as Japanese and published a PGP key, has a sourceforge page and aside from that not much is known. It sort of follows that someone interested in creating a distributed pseudonymous online currency would be a very private person.
It is also suspected that Satoshi may be a pseudonym for any of a number of people involved in the original development - a mask used for safety and protection against legal persecution for the creation of such a potentially disruptive product. To that end, Satoshi may still be involved in bitcoin, although as you stated, not publicly. As with everything else about Satoshi, the reason for his lack of current involvement is unknown.

He also has a bitcointalk profile with a few hundred posts.

Are there public chat logs written by Satoshi?

Seriously isn't it common sense that one (or more) of the core developers is or knows who is Satoshi Nakamoto? E.g. Gavin Andresen, Pieter Wuille, Nils Schneider, Jeff Garzik, Gregory Maxwell etc

@Pacerier You may think so but, since Satoshi contributed under his alias there is no need for him/her to contribute otherwise.

Also, Satoshi sent the paper to the cryptographic mailing group on Oct 31, 2008. In your answer you mention it to be 2007

The two of the most important clues we have are:

Based on observing messages sent by Satoshi Nakamoto, he(/she/they) appear(s) to sleep at about the same time most Americans sleep
Satoshi Nakamoto owns about million bitcoins that have been worth over 64 billion dollars at one point of time, yet sees no reason to (and hasn't seen any reason to ever) convert that to an investment that has inherent yield, such as by selling bitcoins and buying diversified index funds. Most likely this is due to the fact that ever converting these bitcoins to something of value would risk revealing the identity, or it being pocket cash to whoever is Satoshi. Theoretically it could be of course that Satoshi Nakamoto has lots the crypto keys to access those bitcoins, however.

The two non-clues we have are:

Satoshi uses British English and has embedded references to British newspapers in the start of the blockchain
Satoshi uses a pseudonym that sounds like it's of Japanese origin

The reason these are non-clues are that anybody can use any language or dialect of a language, and anybody can invent any pseudonym. So most likely Satoshi wants that we believe he's British or Japanese in an attempt to conceal the identity.
Also there is some speculation based on Satoshi's code that Satoshi is not necessarily a single person but could rather be a team. This agrees excellently with clue (2), since a large team might have less incentives to convert the million bitcoins to something of an inherent value than a single person would. But it would have to be a pretty large team, though (otherwise the bitcoins in there per person would favor converting that to real money), and every member of that team would need to keep that same secret. Most plausible is that the team is in fact a state actor, since something that once was 64 billion dollars wouldn't be unused even if the team would be a large company for example. As an example, if we assume Satoshi is Apple (the most valuable company in the world), that company could have paid an extra dividend for one year (edit: an extra dividend for over 4 years, as Apple seems to pay less than 15 billion/year in dividends) by converting the bitcoins to cash. So claiming that Satoshi was Apple doesn't make sense. In a civilized world people working for a company wouldn't hide the existence of something that was once worth 64 billion dollars.
This leaves two most plausible explanations, the largest state actors in American time zones:

United States
Canada

Considering that United States has done a lot to improve encryption (and in some cases embedding backdoors to encryption algorithms), this is by far the most plausible explanation. 1 million bitcoins is pocket cash for United States. However, this theory would mean there's some reason for the state actor to conceal the identity of Satoshi, and we can't know (we can only speculate) why United States for example would create bitcoin in secret. At least the United States intelligence services seem to be capable of keeping information secret at least to some extent -- true, there has been an Edward Snowden but only one Edward Snowden.
But it wouldn't be impossible for Canada to be involved, however; after all, Canada is part of the Five Eyes alliance with United States and many other countries.
Personally, I think it would be an excellent idea for for example NSA to create a cryptocurrency that the majority of the world's population consider more private than cash, but that actually is far more public than for example any bank transaction. The claim that Satoshi = NSA is entire speculation, though, but the incentive is there. If you want to access all Internet traffic in the world (presumably to identify something illegal from it), doing something that might give you a view to a large portion of illegal financial transactions would be very useful. After all, those contain most of the interesting transactions, the ones you want to access anyway (plus a lot of "investors" wanting to be rich by buying Bitcoin and then end up losing a lot of money on that speculation).
Also, an observation: Tor has been created by United States, but publicly. Wouldn't be impossible for Bitcoin also to be created by United States, but this time privately.
But that starts to be more speculation and less facts, so I'll end the wild theories here.

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


text:
Does a full Bitcoin API reference exist with examples?
I know that all Bitcoin API methods are listed on the wiki: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list. However, some of the methods are very poorly documented.
F.e. the lockunspent method is only documented as taking the parameters <unlock?> [array-of-objects]. No clue about what type of objects. And there are more examples like this.
Is there a good API reference that specifies what parameters are expected and what result they give back?
This would so much lower the bar for new developers!

I hate to say this, but the source code is probably the ultimate reference.

Unfortunately more developers lend their time towards making new exchanges or arbitrage bots than actually making Bitcoin more useful. Those who put together Bitcoin.it did a wonderful job but there needs to be an updated spec sheet with examples as you outline in your question.

The 'help' RPC was improved a lot in 0.9.0 (you can currently download rc3). Parameter names, types and examples are now included.

@wumpus see my answer; rpc reference definitely improved

Apparently, a full API reference just got published on the Bitcoin website:
https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs

Here is a complete API reference that has a pending pull request for bitcoin.org

http://bitcoindev.us.to/en/developer-reference#bitcoin-core-apis

More information:
https://bitcointalk.org/index.php?topic=511876.0

I've used macros and pulled the full RPC documentation from Bitcoin Core 0.9.2.1 (rough formatting, help appreciated!)
Full code won't fit here (80000 chars>30000 limit), but here's the help commands I entered and copied the returned data from:
help addmultisigaddress
help addnode
help backupwallet
help createmultisig
help createrawtransaction
help decoderawtransaction
help decodescript
help dumpprivkey
help dumpwallet
help getaccount
help getaccountaddress
help getaddednodeinfo
help getaddressesbyaccount
help getbalance
help getbestblockhash
help getblock
help getblockchaininfo
help getblockcount
help getblockhash
help getblocktemplate
help getconnectioncount
help getdifficulty
help getgenerate
help gethashespersec
help getinfo
help getmininginfo
help getnettotals
help getnetworkhashps
help getnetworkinfo
help getnewaddress
help getpeerinfo
help getrawchangeaddress
help getrawmempool
help getrawtransaction
help getreceivedbyaccount
help getreceivedbyaddress
help gettransaction
help gettxout
help gettxoutsetinfo
help getunconfirmedbalance
help getwalletinfo
help getwork
help help
help importprivkey
help importwallet
help keypoolrefill
help listaccounts
help listaddressgroupings
help listlockunspent
help listreceivedbyaccount
help listreceivedbyaddress
help listsinceblock
help listtransactions
help listunspent
help lockunspent
help move
help ping
help sendfrom
help sendmany
help sendrawtransaction
help sendtoaddress
help setaccount
help setgenerate
help settxfee
help signmessage
help signrawtransaction
help stop
help submitblock
help validateaddress
help verifychain
help verifymessage
help walletlock
help walletpassphrase
help walletpassphrasechange

And a few egs:
addmultisigaddress nrequired ["key",...] ( "account" )

Add a nrequired-to-sign multisignature address to the wallet.
Each key is a Bitcoin address or hex-encoded public key.
If 'account' is specified, assign address to that account.

Arguments:
1. nrequired (numeric, required) The number of required signatures out of the n keys or addresses.
2. "keysobject" (string, required) A json array of bitcoin addresses or hex-encoded public keys
[
"address" (string) bitcoin address or hex-encoded public key
...,
]
3. "account" (string, optional) An account to assign the addresses to.

Result:
"bitcoinaddress" (string) A bitcoin address associated with the keys.

Examples:

Add a multisig address from 2 addresses
> bitcoin-cli addmultisigaddress 2 "[\"16sSauSf5pF2UkUwvKGq4qjNRzBZYqgEL5\",\"171sgjn4YtPu27adkKGrdDwzRTxnRkBfKV\"]"

As json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "addmultisigaddress", "params": [2, "[\"16sSauSf5pF2UkUwvKGq4qjNRzBZYqgEL5\",\"171sgjn4YtPu27adkKGrdDwzRTxnRkBfKV\"]"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

addnode "node" "add|remove|onetry"

Attempts add or remove a node from the addnode list.
Or try a connection to a node once.

Arguments:
1. "node" (string, required) The node (see getpeerinfo for nodes)
2. "command" (string, required) 'add' to add a node to the list, 'remove' to remove a node from the list, 'onetry' to try a connection to the node once

Examples:
> bitcoin-cli addnode "192.168.0.6:8333" "onetry"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "addnode", "params": ["192.168.0.6:8333", "onetry"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

backupwallet "destination"

Safely copies wallet.dat to destination, which can be a directory or a path with filename.

Arguments:
1. "destination" (string) The destination directory or file

Examples:
> bitcoin-cli backupwallet "backup.dat"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "backupwallet", "params": ["backup.dat"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

PS. C++/QT formatting at Pastebin file so formatting may need changing and there's still time stamps I didn't edit out.

One of the recent additions to the API is:
bitcoind getnetworkhashps

This is not documented in the wiki to which your question links.
While the source code is indeed the ultimate reference, in practice, bitcoind help is the shortest path to most answers.
Here is the entry for lockunspent:
root@blockchainer-test:~# bitcoind help lockunspent
lockunspent unlock [{"txid":"txid","vout":n},...]

Updates list of temporarily unspendable outputs.
Temporarily lock (lock=true) or unlock (lock=false) specified transaction outputs.
A locked transaction output will not be chosen by automatic coin selection, when spending bitcoins.
Locks are stored in memory only. Nodes start with zero locked outputs, and the locked output list
is always cleared (by virtue of process exit) when a node stops or fails.
Also see the listunspent call

Arguments:
1. unlock            (boolean, required) Whether to unlock (true) or lock (false) the specified transactions
2. "transactions"  (string, required) A json array of objects. Each object the txid (string) vout (numeric)
     [           (json array of json objects)
       {
         "txid":"id",    (string) The transaction id
         "vout": n         (numeric) The output number
       }
       ,...
     ]

Result:
true|false    (boolean) Whether the command was successful or not

Examples:

List the unspent transactions
> bitcoin-cli listunspent

Lock an unspent transaction
> bitcoin-cli lockunspent false "[{\"txid\":\"a08e6907dbbd3d809776dbfc5d82e371b764ed838b5655e72f463568df1aadf0\",\"vout\":1}]"

List the locked transactions
> bitcoin-cli listlockunspent

Unlock the transaction again
> bitcoin-cli lockunspent true "[{\"txid\":\"a08e6907dbbd3d809776dbfc5d82e371b764ed838b5655e72f463568df1aadf0\",\"vout\":1}]"

As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "lockunspent", "params": [false, "[{\"txid\":\"a08e6907dbbd3d809776dbfc5d82e371b764ed838b5655e72f463568df1aadf0\",\"vout\":1}]"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Below is a list of all methods you can call on bitcoind, for reference:
root@blockchainer-test:~# bitcoind help
addmultisigaddress nrequired ["key",...] ( "account" )
addnode "node" "add|remove|onetry"
backupwallet "destination"
createmultisig nrequired ["key",...]
createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,...}
decoderawtransaction "hexstring"
decodescript "hex"
dumpprivkey "bitcoinaddress"
dumpwallet "filename"
encryptwallet "passphrase"
getaccount "bitcoinaddress"
getaccountaddress "account"
getaddednodeinfo dns ( "node" )
getaddressesbyaccount "account"
getbalance ( "account" minconf )
getbestblockhash
getblock "hash" ( verbose )
getblockchaininfo
getblockcount
getblockhash index
getblocktemplate ( "jsonrequestobject" )
getconnectioncount
getdifficulty
getgenerate
gethashespersec
getinfo
getmininginfo
getnettotals
getnetworkhashps ( blocks height )
getnetworkinfo
getnewaddress ( "account" )
getpeerinfo
getrawchangeaddress
getrawmempool ( verbose )
getrawtransaction "txid" ( verbose )
getreceivedbyaccount "account" ( minconf )
getreceivedbyaddress "bitcoinaddress" ( minconf )
gettransaction "txid"
gettxout "txid" n ( includemempool )
gettxoutsetinfo
getunconfirmedbalance
getwalletinfo
getwork ( "data" )
help ( "command" )
importprivkey "bitcoinprivkey" ( "label" rescan )
importwallet "filename"
keypoolrefill ( newsize )
listaccounts ( minconf )
listaddressgroupings
listlockunspent
listreceivedbyaccount ( minconf includeempty )
listreceivedbyaddress ( minconf includeempty )
listsinceblock ( "blockhash" target-confirmations )
listtransactions ( "account" count from )
listunspent ( minconf maxconf  ["address",...] )
lockunspent unlock [{"txid":"txid","vout":n},...]
move "fromaccount" "toaccount" amount ( minconf "comment" )
ping
sendfrom "fromaccount" "tobitcoinaddress" amount ( minconf "comment" "comment-to" )
sendmany "fromaccount" {"address":amount,...} ( minconf "comment" )
sendrawtransaction "hexstring" ( allowhighfees )
sendtoaddress "bitcoinaddress" amount ( "comment" "comment-to" )
setaccount "bitcoinaddress" "account"
setgenerate generate ( genproclimit )
settxfee amount
signmessage "bitcoinaddress" "message"
signrawtransaction "hexstring" ( [{"txid":"id","vout":n,"scriptPubKey":"hex","redeemScript":"hex"},...] ["privatekey1",...] sighashtype )
stop
submitblock "hexdata" ( "jsonparametersobject" )
validateaddress "bitcoinaddress"
verifychain ( checklevel numblocks )
verifymessage "bitcoinaddress" "signature" "message"

I was more looking to an official reference that is maintained by the devs and that also contains formatting information of parameters and return values.

Also, most people use bitcoind through RPC and some may not have an instance available to use the help command on. There should be an online reference somewhere IMO.


text:
What does "Network Unroutable" means?
I just started running bitcoin core on a dedicated laptop.  I wanted to see if my node is connected to my Wasabi wallet so I sent some sats from Strike. In the peers list Wasabi shows up but under Network it shows Unroutable. Is that normal?  What does that mean? Is my node connected? Am I sovereign?
I looked in my Wasabi logs and it showed that the block was acquired from a local p2p connection. I'm guessing that my node is connected.  I just wonder about the Network being Unroutable.  I appreciate the feedback.  Thanks

Yes, this helps. Thank you

From the Wasabi docs:

There are two ways to confirm that your Wasabi client is connected to
your own full node.
First, in the Wasabi logs. Once you receive a transaction Wasabi
downloads the block containing that transaction from your node, and in
the logs you should see: Block acquired from local P2P connection.
Second, by checking the connected peers inside your full node. Wasabi
will show up as one of the connected peers while it is downloading a
block. You can check this in the Bitcoin Core / Knots GUI by clicking
on Window -> Peers. During the period when Wasabi is fetching a
block, it will show up in the User Agent column. Alternatively, you
can use the Bitcoin RPC call bitcoin-cli getpeerinfo and see the
Wasabi client listed.
https://docs.wasabiwallet.io/using-wasabi/BitcoinFullNode.html#using-an-already-existing-remote-bitcoin-full-node


text:
What is the maximum of receive addresses the default wallet can handle?
I guess there is no limit. But on tests, what is the maximum before the bitcoind start to slow down in a specific machine?

Well... test it, I would say. There is no way we can know this, unless we do some proper bench marking, which you can do better for your specific needs.

I will do it, thank you @Jori. I just post here to see if anyone have done this test before. It is a nice test to do.

authors: Олег Медвідь


text:
What does the text strange or nonstandard type mean in the output of a transaction?
I am trying to learn bitcoin by writing a script that finds a balance of a set of addresses by scanning all raw transactions.
In the following link, the output at index 1 has no address and is marked as strange. What does that mean? Does it mean that the .1 testnet coin is destroyed?
http://blockexplorer.com/testnet/tx/c08053db370893765c88c93e2fe4db0aa8ebc02c70b2c91109a6081b06b5e060

It's just a script blockexplorer.com doesn't seem to understand and consequently marks as "strange". Bitcoin scripts determine who is able to claim the bitcoins. Transfering them to an address is just one of many possible options.
If the coins of a transaction A are spent in a transaction B two scripts are involved: The "ScriptPubKey" of transaction A and the "ScriptSig" of transaction B. The two scripts are combined and executed as a whole.
Normally, the scripts check if the spender can identify itself with a private key corresponding to the address specified in transaction A. But not in this case:
Have a look at the column ScriptPubKey: It says OP_WITHIN. This command checks if a number is in a given range. The transaction claiming these coins puts the arguments -1 -100 and 100 on the stack. Since -1 is between -100 and 100 the transaction is valid.
Obviously, this doesn't make much sense, but it's just a testnet transaction.
For more information about scripts have a look at this wiki page.


text:
Bitcoin charts for websites
Does anyone know of any good paid or open source software solutions for displaying Bitcoin charts on a customer facing website?
There are three main types of charts we want to offer at this stage:

MtGox Live style (not sure what this type of chart is called but would love to know if someone does?)
Candlestick Charts like at http://bitcoincharts.com/charts
Basic line graphs like at http://blockchain.info/charts

I have to date found the following:

Google charts https://developers.google.com/chart/ These unfortunately don't really cut it.
StatsMix http://www.statsmix.com/ The pricing a little higher than I wanted to pay for this solution.

As for where to get the data feeds I am okey with this. It's only the web facing charts that I need to find a solution toif anyone has come across before?

If you're wanting charting software, then you might like to try asking on stackoverflow (or searching, as it's probably already been asked). You're aware of bitcoincharts.com I presume?

Will close this as the question is just about finding a charting library and not about getting Bitcoin data to display. Please follow Highly Irregular's advice and ask a question on Stack Overflow. Good luck!


text:
How can I mine bitcoin faster?
I'm curios what kind of PC, I need to mine bitcoins. What OS system, what GPU, CPU, etc...
my current specification are:
CPU: Xeon e3-1230v3
GPU: GTX 780
RAM: 24gb
OS: Windows 8.1(64bits)
So what do u think about that spec, and what do u think i can change for faster mining?

For Bitcoin mining, you need a Bitcoin miner, not a PC.


text:
Can I use single address for all my transactions?
Can I always use single public key (addr1) for all my transactions and when I spend every time protect it with different scripts / keys (key2, key3, etc.), so that spending requires at least two keys ('key1', and 'key-n') but addr1 remains the same for receiving bitcoins.
example.
(transaction, output script): (input address, amount) --> (output 1); (output 2)
--------------------------------------------------------------------------
(trxn1, script1): (addr1, 10 BTC) --> (addr2,  5 BTC); (addr1,  5 BTC)
(trxn2, script2): (addr1,  5 BTC) --> (addr3,  1 BTC); (addr1,  4 BTC)
(trxn3, script3): (addr1,  4 BTC) --> (addr4,  1 BTC); (addr1,  3 BTC)
(trxn4, script4): (addr5, 12 BTC) --> (addr1, 10 BTC); (addr5,  2 BTC)
(trxn5, script5): (addr1, 13 BTC) --> (addr6,  2 BTC); (addr1, 11 BTC)

Is it possible to make script 1, 2, 3 and 5 would require different keys (at least 2; key1 and key-n) to spend bitcoin from this address?
Is it possible with Script? Is there any other ways in which I can keep single address for all my transactions?
addr1 is my address; transactions 1, 2, 3, 5 are my spends and transaction 4 is receiving transaction.

Motivation: To use same address for all my transactions. Reason is, I own firstbits address '1vijay', and I don't want to loose in case of my private key compromised. I am looking for any solution that would solve my problem, particularly scripts.
pseudo-script would be something like,
scriptPubKey: <pubKey1> OP_DROP <pubKey2> OP_CHECKSIG
scriptSig: <sig>

I would like to use 'pubKey1' as my receiving address always, but my spending would depend on private key corresponding to 'pubKey2'.

Looks like, it is too tricky, and not for everyone. It would be better if different addresses used every time.

If you can't spend your bitcoins with just key1, then you're not really receiving bitcoins with that address, are you? I suspect you could do something similar to your question using key splitting.

No, looks like, key splitting is about private keys. But, split keys are going to be the same always..

If you are to receive a transaction with address A, you need A's private key in order to spend it and nothing more.
If you want to require two or more addresses to be used to spend money you receive, you would need to use a multisig address. After that, you would need to use m-of-n private keys to spend the coins, with m and n being predefined when you create the multisig address.
There are other ways one could restrict coins from being spent - say requiring a password or allowing anyone to spend them, but they are a lot more obscure and generally not used by anyone.

by keeping receiving address the same with every transaction, is it possible to make spending would require private key + extra details (like, another key), through scripts?

@vi.su. The way one can redeem the transaction is determined by the sender, not the receiver. They can specify what data is needed - signature or password. You could, however, just send all of your incoming transactions from one address straight into a multisig address and thus require that extra data. Asides that, there isn't much you can do.

I don't really understand what you're asking, but I think the answer is no.
In every such scheme, there would be two pieces of information - a secret part/key, and a public address. You can split the secret key to n pieces (multisig), and the implementation of this is underway, but the basic observation remains.
Now, if the private key is leaked, the bitcoins are spendable. If you need to receive bitcoins on a system without the ability to spend them, just delete the private key from that system, and only keep it elsewhere.

My question is, how to allow an address to receive bitcoins without worrying about primary key compromised. Through script, is it possible to prevent the spend using another key (by keeping my address same).

@vi.su. - perhaps this is what you meant to ask? http://bitcoin.stackexchange.com/questions/8142/can-you-generate-bitcoin-addresses-without-storing-a-private-key

I have completely rephrased my question. please check.

What you ask is impossible. The scriptPubKey determines the conditions under which the bitcoins can be accessed. For a different set of conditions (e.g. first (key1,key2), then (key1,key3)...) you need a different scriptPubKey. And a different scriptPubKey means a different address on which you receive the bitcoins.


text:
Will an approved Bitcoin-like system replace Bitcoin?
What is the chance of another Bitcoin-like currency system to replace Bitcoin? Will Bitcoin still coexist with such systems? Will it affect then-current Bitcoin exchange rate?
By Bitcoin-like, I mean, government and banks approved, more privacy, some other means of mining, special purpose (only to buy cars), with different benefits, etc.

It's near certain that other Bitcoin-like currencies will continue to be introduced from time to time. Some of them will likely gain some traction.
Over time, more and more deficiencies of Bitcoin will become apparent and newly-designed competitors will be able to fix them. While Bitcoin can certainly make some changes, it will always have a trade-off because significant changes risk shaking to confidence of current users. At some point, Bitcoin's accumulated deficiencies will be too much and it will lose significant share to some competitor.
Of course whether that will be next year or next century, I don't think anybody knows.
Some such systems will likely coexist with Bitcoin without much interaction. Others may design in interaction with Bitcoins directly into their fundamental design. Nobody has a crystal ball though.
Some have imagined high-speed, high-volume systems that would move Bitcoins outside the regular blockchain with the existing Bitcoin system used only to "settle up" large transfers between smaller, faster systems. Will that be what happens? Who knows?

Even if new bitcoin-like systems introduced, Bitcoin will have it's advantages, like, user base and first system to scale to this level.

A currency controlled by a single individual, company or government would not need to work like Bitcoin. It would be centralised - there would be no need for mining, running special clients and so forth. Those are only a key feature of some decentralised internet currencies similar to Bitcoin.
It is possible that such a currency would replace Bitcoin, but it would be done most likely by law and force, rather than because of its benefits. A currency like that might exist alongside Bitcoin, but how much it is used would depend on the appeal and use of it. Should it for example be the only currency you could pay taxes in, it might as well exist for a long time.
There is also an idea of Digital Coin, where many such currencies might exist at the same time because they would be beneficial for the companies and their customers. It has space for Bitcoin-like currency - as a measurement of standard of value, as well as last resort for trading.
All in all, Bitcoin won't probably be replaced, it might be outlawed, and other currencies might exist alongside it.


text:
Is it technically possible to create and use dynamic private key - public key pair and use it with bitcoin?
Is it technically possible to create and use dynamic private key - public key pair and use it with bitcoin?
I am not sure anything conceptually similar to this already exists. Yet, "dynamic" private - public key pair can be defined as ordinary key pair with 2FA capabilities. Both the keys regularly change per generated 2FA token.
Basically I hope the following,

create dynamic private - public key pair, combining 2FA (like, google authenticator) and a passphrase
this key pair can only be used for a short defined duration, or as long as 2FA token is valid
receive funds
chronologically old key pairs can be used to check / receive funds (or, not)
In future, private key generated from passphrase and 2FA token can be used to spend the coins

BIP 38 is not anyway related to this.

please feel free to edit / comment, if anything is not clear.

I don't understand the question. In step 2, you say "this key pair can only be used for a short defined duration". Used to do what?

Can you explain the purpose of "dynamic keys"?

@Eyal, I was looking for a way to make spending possible by some combination of private key + two factor authentication (like, google authenticator). I thought, it is possible through script, but I was never able to solve this.

The idea behnd second-factor is that it changes.  There are three factors in auth: who you are, what you know, and what you have.  "what you know" is password.  "who you are" is a fingerprint.  "what you have" is maybe a smartphone.  But since the password is only ever useful once, because you can only spend once, there's no need for a changing key.

No, it is not possible to do what you are suggesting.  Here's more info about cryptography.

You can create create an ECDSA keypair with almost any random data (it must a lower than a certain value, but go check ECDSA specs) and then generate an address... But a keypair will always be valid to receive bitcoins or send them (if you still have the private key).
The thing is that a other party will not be able to know what is your next address since you need the private key to do that.
So yeah you can create keypairs with almost any data, but I don't think it'll be dynamic in the way you think.

"The thing is that a other party will not be able to know what is your next address since you need the private key to do that." - this is expected, and this also prevents others from checking my balance.


text:
What are the advantages and disadvantages of 24/7 Bitcoin trading?
What are the advantages and disadvantages of 24/7 Bitcoin trading over traditional stock market which operates only 6 - 8 hours a day and 5 days a week? Any threats?

The 24/7/365 bitcoin trading market is pretty unique in financial markets. Here are the advantages and disadvantages as I see them.
Advantages:
- more convenient: bitcoin can be bought and sold at any time and on any day.
- truly international: bitcoin can be traded during business hours in every country and every timezone.
- increased profitability: more trades means a good trader can make more money.
Disadvantages:
- increased risk: important market movements can occur while you're sleeping, causing trading losses.

I would say that with out the regulated trading times such as a stock market you have a chance to lose everything while your sleeping, also with no set times you can't regulate a real price and the sell price becomes what ever who ever your selling them to wants to pay. The up side is no matter where in the world you are you can buy and sell them just as easily.

You "risk losing everything" only if you're careless. Just post some orders at a low price, and you're done.

That's not true unless you can actually place a stop order which aren't widely supported.

I see only advantages now.
Here can be risks but here is the rebuttal for them:
http://cryptodetail.com/page/the-advantages-and-risks-of-cryptocurrency

Exchanges have hard time to make upgrades/maintenance as they are always live... Nasdaq have 12+ hours a day to do that.

While the linked page may contain great info, it's generally better to capture the main salient points in your answer in case the page "goes away".


text:
What's the maximum possible utxo growth rate now? Can that be turned into an attack?
Now bitcoin unspent transaction output growth rate (not total size) can be, 260k utxo/day (3×60×60×24). With 8MB blocks, that's 2.8 million.
Single 1 bitcoin output can be split into 1000 x 1 mBTC outputs, within 100 minutes (10 blocks). Then, those 1000 outputs can be moved individually, as required..
Does this kind of utxo bloat attack work? Anything wrong with my calculations?

https://statoshi.info/dashboard/db/unspent-transaction-output-set

@amaclin, sorry, I was not clear. I wanted to know maximum possible rate at which utxo can grow, and whether that can be turned into an attack..

There is no limit on the size of the UTXO other than the block size as you've described, but your reasoning isn't correct. There is no minimum size of a transaction output, nor maximum number of outputs per transaction. The bulk is limited by the Bitcoin block size of 1MB, or about 50GB per year total additions if the only thing being added was spam outputs.
Volume of outputs is another matter entirely. The smallest possible output is 0 BTC (8 bytes), 0 length (1 byte), null scriptPubKey. If we make a maximum sized transaction (1MB) of these it will have somewhere in realm of 110,000 outputs, with some loss included for inputs and structure. 6 blocks per hour, 24 hours gives 15.8M outputs per day. Note this does not include any indexing overhead, which would be non-negligible for this many entries.
Some of the proposed solutions include expiring unspent outputs after a particular amount of time, or significantly moving the cost towards creation and incentivising removal of entries. Changes in core operation like this however aren't fast to implement or uncontroversial, and are not a complete solution against an attacker.
It's one of the drawbacks of the system as implemented and something that needs to be seriously considered before making alterations which could make the problem even worse.  Lots of things become unpalatable in Bitcoin when you change the constants, this is one which is already pretty terrible to begin with.

I'm not suggesting there's minimum/maximum transaction size. My question is about at which rate utxo can grow?

The rate is bounded by how much you can grow it per block, so most efficient ways of bloating the database is completely what you want to be looking at. There's no other limit. Put directly, 50GB per year + indexing overhead if every transaction is intended to bloat it.


text:
How would segwit help bitcoin services like, blockstream profit, and miners to loose?
Segwit in the current form,
How would it affect miners except, asicboost?
How would blockstream (other than miners) kind of companies benefit from it, in such a way that miners can't?
I'm looking for a technical answer, and please avoid opinion based answers.

i'm voting to close this question as it tends to solicit opinionated comments related to blockstream/miners as oppose to factual unbiased comments related to bitcoin as is. In fact, I cannot see how segwit is related to blockstream other than it being implemented and proposed by an employee of Blockstream.

Blockstream is an example as it's the only company getting criticized much more than any other companies.. generally, my question is how someone other than miners profit from current segwit implementation..

I don't know the answer, but I'm glad the question is raised. Segwit seems to me an overcomplicated way of increasing the block size. Technically, it is a softfork, but I don't see how the effect on the network will be softer than just increasing block size, as it creates a quite extreme situation where old nodes view the new transactions as "anyone can spend", and also cannot relay the full information of a transaction.

Disclaimer: I'm a Blockstream co-founder and the primary author of the SegWit proposal.
I believe SegWit benefits everyone in the Bitcoin ecosystem. It solves several long-standing problems that hurt future evolution and scalability:

Transaction malleability complicates multi-transaction contracts
Lack of script versions makes introduction of new opcodes complicated
O(n^2) signature hashing makes worst-case block validation unnecessarily costly
Lack of input amounts in signature hashing complicates hardware wallet design.

As a side effect, it also gives a moderate capacity increase without forcing the whole ecosystem to adopt new consensus rules, and improves the incentives for UTXO growth going forward.
More information about the benefits can be found here
Of course there are costs as well. They are mostly related to the size of the change. However, it has been a community effort with dozens of contributors that reviewed and tested the changes over the course of several months, with deployments in several test networks, later the Bitcoin testnet, and eventually adopted in Litecoin. A large part of the ecosystem has indicated support or readiness for SegWit.
More information about the costs can be found here.
So to answer your questions:

How would it affect miners except, asicboost?

I don't know. Given the level of industry support, I don't know why they would be opposed to it except for political reasons. The only thing I can come up with is that a sudden increase in capacity may temporarily reduce fee income, but that is expected for any kind of capacity increase.

How would blockstream (other than miners) kind of companies benefit from it, in such a way that miners can't?

Blockstream has no direct business interest in seeing SegWit activated. All its own products (including Elements and Liquid) have had SegWit-like systems built in for years, and work fine with or without it being available on the main chain. Blockstream pays me and others to work on Bitcoin development, including SegWit and Lightning, because it believes that is valuable to the ecosystem we all depend on.
There are other companies that may have a direct interest in SegWit. This includes wallet providers who pay transaction fees for their users, especially multisig wallets, as the benefits of SegWit are largest for those. Hardware wallet creators may like SegWit because it simplifies proving the amount of fee paid to the hardware. Companies whose business model relies on payment channels (which doesn't include Blockstream) may depend on SegWit activating in the near future.


text:
When we can agree on mempool sorting order, we can just confirm first n-transactions that are at least 10 mins old. What's missing?
When we can agree on a mempool sorting order, we can just confirm first n-transactions (or 80% of transactions) that are at least 10 minutes old.  Then, we can transfer (broadcast) the block header and a hash to the set of all confirmed transactions.
Just consider this as an aggressive version of BIP152, compact blocks.
This kind of method will work for transactions of any size; both confirming 10 transactions and 1 million transactions are the same.
What's missing? Why are we not doing 'confirmation' like this?
For example, if we have 1000 transactions in a mempool (sorted), 900 transactions are at least 10 minutes old, and we're confirming the first 720 transactions.
This may not be a perfect or complete solution, but we just need to find,

Sort order; fee, size, etc.
Transaction age; say, 10 min
Confirm size; say, confirm first 80%

Note:
Sort order is based on f(trxn-meta-data; fee, input, output, etc.), transaction age is used as a filter. Another filter is first x% of the set.

its up to the node to sort it in anyway he likes. Perhaps a sorting based on fee would make more sense to them.

@abeikverdi I'm asking for sorting order consensus, and get rid of block size debates forever.

What advantage do I get if everyones mempool is sorted based on a certain criteria? What does it have to do with block size limit?

By sorted you mean two nodes have the same transactions in mempool or you mean transactions are listed and sorted based on a factor?

When all mempools are sorted, most likely all mempools are in sync with unconfirmed first n-transactions. This fact can be then be used to announce these transactions are confirmed, along with block header and a hash to all these newly confirmed transactions.

Idea is to get first n-transactions in every mempool the same, so that we can auto confirm first 1k, or 1M transactions without building and broadcasting blocks.

You made me confused with "sorted". First of all there is no may to make sure that everyone has received the broadcasted transaction, therefore always there are some transactions missing for each node. IBLT could help them to sync the mempool and stuff. But in general what your saying is basically what a blockchain is trying to do. We create the blockchain and all the proof of work and consensus to agree on the transactions that cant simply be synced.

What happens if there are double spent in the list of first n transactions in mempool?

it is not possible to have 'sorting order consensus' or 'mempool synced' because of https://en.wikipedia.org/wiki/CAP_theorem

@amaclin interesting. I'll look into it. :)

Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history.
The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a simultaneously-created transaction tx2 broadcast in Alaska cannot be both included in a block. However, nodes in the rest of Asia will see tx1 first, and nodes in the rest of North America will see tx2 first. Which of those two is legitimate?
There is no solution to that problem, as due to general relativity, the concept of 'first' depends on one's frame of reference. A proof-of-work controlled blockchain solves this problem by accepting that not all nodes need to immediately agree on which of those transactions is accepted, and instead make economics force miners to make a choice between the to candidates.
Despite not having a guarantee for consistency between mempools, there is of course a very strong overlap. This overlap is exploited in many of the proposed efficient relay protocols, including the Relay Network, IBLT, Block network coding (and Compact Blocks which you reference).

Thanks for the answer. May be, my question is not clear. We still need blockchain to distribute rewards, and every 10 mins we still need to broadcast blocks (header only).

I understand, everyone's frame of reference will be different, but my assumption is, a sorted set, that's at least 10 mins old should be the same across all miners.

If you have a consistently synchronized mempool across the globe, it means you can use it as a single shared synchronized database. You don't need blocks anymore to distribute updates - just use the mempool as the state of everyone's account directly.

@vi.su If the top 80% sorted mempool you refer to is not guaranteed to be exactly the same across the world, your idea does not work (and physics dictates that this can't be the case). What does work is protocols that find the (small) differences between mempools, and transfer the differences (which all of the linked proposals in some form or another do).

transactions can be sorted without time, if they could include previous transaction (any tx) from mempool. Just as a proof of, our transaction was created after a specific unconfirmed transaction. Just like, previous block in blocks header..

You don't really need general relativity here (and most of earth is in the same frame of reference anyways) – just the finite propagation speed of information (which is a consequence of general relativity, but is also consistent with Newtonian Physics).

There are a few issues with this proposal:

No transaction could ever be confirmed in less than ten minutes.
We already have plenty people up in arms that choose to rely on zero confirmation transactions. Waiting at least ten minutes would increase confirmation times.
Every node has their own mempool and they don't necessarily match.
Every node receives transactions at different times and perhaps in different orders, so some transactions might not have come to the attention of all nodes yet. Especially, the age of transactions would not be the same in all mempools. There also might be some doublespends floating around, which could make it impossible for two nodes to match their mempools.
A single hash is insufficient to reconstruct the confirmed transaction set.
As soon as there would be any difference in the mempools the recipient node would fail to reconstruct the block. Besides, if a single hash were sufficient the block header already includes the Merkle root of the transaction tree.

These related ideas come to mind:

Gavin Andresen proposed an Invertible Bloom Lookup Table based set reconciliated a few years ago. It was based on a fixed transaction order in blocks.
The weak block proposal has miners also broadcast unsuccessful blocks to announce what transactions they are working on.

Thanks, I've heard about IBLT, but never understood it properly. I'll look into it.

10 min is arbitrary, it's chosen as an example to have matching block reward cycle. When someone can process 0-conf with blocks, then they can also process with conf-set from mempool.

Still, I couldn't understand why from a sorted set, first 80%, transactions that are at least 10 mins old goes async.

Single hash (not Merkel root) is used here just to verify the set, not to reconstruct, as the transactions accross all mempools are the same..

Let's say, you heard about transaction X at 14:10, I got it at 14:11. When you find a block at 14:20 you include transaction X, but for me it's not available for inclusion yet. Transactions don't have a timestamp, so there is no universal information how old they are. – If you just want to verify the set, you can do that with the Merkel root as well, both the Merkle root and a single hash over all transactions are a digest of the complete transaction body. Neither is sufficient for reconstruction, both are for verification.

We're not sorting mempool based on transaction received time, so our time when we receive the transaction doesn't make any difference, unless the difference is >10 mins. Sorting order may be, a combination of utxo sort, fee, bitcoin days destroyed, oldest first, from address, to address, trxn amount, etc.

Actually, you can think of the 10 minute age as a second dimension of sorting: You sort into the two buckets "older than 10 minutes" and "younger than 10 minutes". As I said before, there is no other time information attached to transactions than the time our node first saw it. Therefore, every node will sort differently in the time dimension, even if they all sort the same way in your proposed mempool order. It follows that you cannot guarantee a matching set of transactions ready for inclusion.

no two buckets. I mean, sort irrespective of time and then filter it by top 80%, then remove new transactions. This is just an example, but we need a method that would not conflict accross miners.

"remove new transactions" as explained multiple times above, this can't be done, because "we need a method that would not conflict across miners", but blocks and the blockchain are what resolves the conflict.

understand now. Remove is not possible. Some will not remove 10 mins old trxn, that could be 9 mins old in my mempool.


text:
What is OP_CODESEPARATOR used for?
Looking at the Bitcoin source (https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/script.cpp#L843-L847, specifically), I ran into the use of the OP_CODESEPARATOR. Am I right in interpreting this code that it is not always the case that the whole scriptPubKey is signed, but really just the part that is later than the most recent OP_CODESEPARATOR? What happens if an OP_IF causes an OP_CODESEPARATOR to be skipped?
It seems strange to me that the entire scriptPubKey isn't used for signing in all cases, so I'm guessing there is some use case for this that I haven't thought of. Does anyone know what this use case is?
I've read through this bitcointalk thread, but didn't really find any conclusion there.

The really telling thing about the usefulness of OP_CODESEPARATOR is that all of the results in Google are people asking what it's used for. ;)

Looking at this diagram of OP_CHECKSIG steps and the Bitcoin Script wiki, OP_CODESEPARATOR is used to make OP_CHECKSIG check only part of the scriptPubKey. Essentially, only the script that goes after the last OP_CODESEPARATOR is used to sign the transaction and hence evaluated by OP_CHECKSIG.
In theory, a spending transaction could change the part of the scriptPubKey before the last OP_CODESEPARATOR  of the input transaction.
However, there's a problem. Since scriptPubKey comes from the input transaction, you can't actually modify any part of the scriptPubKey (even the part before the last OP_CODESEPARATOR) without changing the input transaction hash. Changing the input transaction hash breaks the link for any transaction trying to spend outputs from the unspent input transaction, making it impossible to use OP_CODESEPARATOR in practice.
I wasn't able to find any cases in practice where people have successfully used OP_CODESEPARATOR for a useful purpose, although it does show up in the blockchain. See this, this and this (and the thread you referenced) for core developers commenting on or discussing possible uses for OP_CODESEPARATOR.

What happens in the script evaluation if the OP_CODESEPARATOR is inside of an if else block? Does the part being signed always go right to the end of the scriptPubKey?

I can't be certain, but it looks like based on the bitcoind tests here that OP_CODESEPARATOR within IF statements shouldn't be evaluated as the last OP_CODESEPARATOR if the IF condition is false.

But it will allow everything in the else block to be signed, in that case, which seems strange. Haven't looked at the links you sent yet, but can't envision a case where the OP is useful yet, even if it were possible to use... Thanks for your answers.

I think it would sign everything after the last OP_CODESEPARATOR, so unless there was a OP_CODESEPARATOR in the ELSE block, everything would be signed. But yes agreed, can't find a useful case yet, especially with the problem of the input tx hash changing. If you find one, please post it here for the community. Great question @StephenM347.

OP_CODESEPARATOR is a leftover opcode from a previous version of the scripting language and was found to contain pretty dreadful bugs; it is no longer used in Bitcoin scripts, and except for probably some very low-level edge-cases safely ignore its existence.
For more details on the potential attack vectors it resulted in, see
https://bitcointalk.org/index.php?topic=255145.msg2757327


text:
Different redeemScript for the same scriptPubKey?
Most transaction outputs to P2SH addresses have the following scriptPubKey:
HASH160 f45d94733d430261962932e0c847075195916a04 OP_EQUAL

As I understand it, this transaction do not need to be signed. Is it true?
The user just needs to provide a redeemScript whose HASH160 is equal to f45d94733d430261962932e0c847075195916a04.
So, if we know that:
HASH160(data1) = hash1
HASH160(data2) = hash2

and the user creates two transaction outputs to P2SH addresses with the scriptPubKeys:
HASH160 f45d94733d430261962932e0c847075195916a04 OP_EQUAL

then the scriptPubKey is the same for both transaction outputs, but why is the redeemScript is always different?
HASH160(data1) = hash1
HASH160(data2) = hash1
....
????

Can you provide an example of two different redeem scripts with the same hash?

A P2SH transaction will execute whatever redeemScript you provide, which must be a standard transaction:

Transactions that redeem these pay-to-script outpoints are only
  considered standard if the serialized script - also referred to as the
  redeemScript - is, itself, one of the other standard transaction
  types. See BIP16

Those standard transactions, like a P2PKH does require a signature, so even though you provide the right redeemScript, if it doesn't execute successfully, the entire tx will become invalid.

Just to note, Bitcoin Core 0.10.0 and later no longer require that the redeemScript is one of the standard transaction types. See https://github.com/bitcoin/bitcoin/pull/4365.


text:
I sent bitcoins to my wallet before it had synced. is there ANY way i can get my coins back?
I downloaded Bitcoin. qt and started the sync (which was going to take about 6 days UGH) so about 4 days into it i tried to open the app and Now the app shows "error loading blkindex.dat" So i cannot access my wallet on my computer and never really got a chance to backup or encrypt anything...
I've tried using blockchain.info's desktop sync function but literally nothing happens when i press "download address list" on step 3...????
I have also tried MtGox but i can't find anywhere to upload my wallet.dat file...
Is there ANY WAY i can get my coins?
I'm running Mac OS X. Be as specific as you can please :)

You are running Bitcoin-Qt on iOS?   Wow!
(Did you mean Mac OS X?)

As long as your wallet.dat file is uncorrupted/unstolen, your coins are fine. Try backing up the wallet.dat file, uninstalling Bitcoin, then reinstalling.

Blockchain.info/wallet has the ability to import individual private keys as well.   The private keys can be exported now right from the Bitcoin-Qt client (v0.7 and higher) directly without the need for pywallet or any other utility.


text:
I'm trying to compile bitcoind on Windows but build_unix for db-4.8.30.NC is empty. What do I need to do?
I've been working on setting up the proper environment to compile litecoin, and have been following the instructions from this:
https://bitcointalk.org/index.php?PHPSESSID=1dl8pkva2oqpjsd3h455k7hrj7&topic=149479.0;all

2.2 Berkeley DB: http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz
We'll use version 4.8 to preserve binary wallet compatibility.
From a MinGW shell unpack the source archive, configure, edit line 113 of db.h then make:
Code:

cd /c/deps/

tar xvfz db-4.8.30.NC.tar.gz

cd db-4.8.30.NC/build_unix

../dist/configure --disable-replication --enable-mingw --enable-cxx

after configuring make sure to edit your build_unix/db.h by replacing line 113:
Code:

typedef pthread_t db_threadid_t;

with
Code:

typedef u_int32_t db_threadid_t;

I was all set to do it, but this happened:

I've tried getting db-4.8.30.NC from multiple sources, but no luck—the build_unix folder is always empty.
So what's the deal?

I just downloaded Berkeley DB from the link and had no problems.  The db-4.8.30NC.tar.gz is 21.7MB.  Is this the size of your file?

I have no problem downloading the file; can you tell me what's inside your build_unix directory? I only have an .IGNORE_ME file.

There are 793 files, one of which is .IGNORE_ME.  There is also a .libs subdirectory.  Sounds like your tarball wasn't unpacked correctly or it was truncated.

Can I have your link? I tried both mingw and 7zip to open it. I tried the windows zip viewer for a zip version.

I mislead you because I have already built Berkely DB.  I went back and looked at the .tar.gz file again and it does contain just the .IGNORE_ME file.  You just need to run the configure and make commands to create all of the files in the directory.

The build_unix directory contains just the .IGNORE_ME file in the distribution.  The directory is populated by the make command.
../dist/configure --disable-replication --enable-mingw --enable-cxx
make

You do not need to edit db.h in the latest distribution since they have already corrected the typedef.

../dist/configure --enable-cxx
make
this will also do

im trying to build this on windows, i dont see a configure file. can someone point out

I can't believe I missed this answer. I'll see if I still have that stuff on my laptop, maybe I can get it going when I have time!


text:
How can I convert a SHA256 hash into a Bitcoin base58 private key?
How can I take the output of sha256sum
sudofox@ubuntu:~$ echo -n 'Hi guys!' | sha256sum
7542fb6685f9fd8f37d56faf62f0bb4563684a51539e4b26f0840db361e0027c  -

and turn it into a Base58Check encoded private key?
I need to be able to do this with a list of SHA256 keys. Is there a script I can download, or must I spend a few weeks making it just so I can make my temporary addresses?
In response to first comment:
No, I must input a string, like "fluttershy", for example, into sha256sum and then I must encode the output of sha256sum into a base58check private key.
string -->sha256sum --> some automagic process, which is the purpose of this question --> bitcoin private key.
Update: For anyone wanting to use Grondilu's Bitcoin Bash Tools: You need to source the bitcoin.sh file after extracting it into your directory to use the functions.
source ./bitcoin.sh
Update 2 (Aug 2017): Rewrote script to go from step 1 to WIF in one go. You can just add the declaration of base58 and the encodeBase58 functions from bitcoin.sh if you want to skip the rest of the lib.
#!/bin/bash
#Tool to convert bitcoin privkeys into WIF keys
# by sudofox

source ./bitcoin.sh

KEY=$1 # first arg

# add 0x80 to beginning
EXTENDEDKEY=$(echo 80$KEY)
FIRSTHASH=$(echo -n "$EXTENDEDKEY" |xxd -r -p |sha256sum -b|awk '{print $1}')
SECONDHASH=$(echo -n "$FIRSTHASH" |xxd -r -p |sha256sum -b|awk '{print $1}')
CHECKSUM=$(echo $SECONDHASH|cut -c1-8)
FINAL=$(encodeBase58 $EXTENDEDKEY$CHECKSUM)
echo $FINAL

The usage would be
./sha256_to_privkey.sh key
where in my example (see Stephen Gornick's answer), key would be
807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027CCD5C4A8E

Do the same thing for the various functions, modifying as needed. Hope this helps anyone struggling to use the tools.

Yes, this is possible. But I have a strong feeling this is an XY problem

Clarification (well, stating in explicit terms) above.

Is there some reason why you want to send your bitcoins to an unspendable public key?

@Nick ODell "Unspendable public key?" I'm generating a bitcoin private key. That means it would be spendable as long as I still have the key I generated.
You changed the title of my question so that it looks like I want to hash the private key and then try to turn that into a bitcoin address. Why would I want to do that?          I'm changing the title to "How can I convert a SHA256 hash into a Bitcoin base58 private key?"

What you are requesting is described as computing the Wallet Import Format for that private key:

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

Using your example:
1.) Take a private key (Below is the HEX representation of binary value)

7542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C

2.) Add a 0x80 byte in front of it

807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C

3.) Perform SHA-256 hash on the extended key
$ echo -n '807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C' | xxd -r -p | sha256sum -b

7DE4708EB23AB611371BB778FC0C8BDE80394AB2D8704D7129FB5771E2F1730D

4.) Perform SHA-256 hash on result of SHA-256 hash
$ echo -n '7DE4708EB23AB611371BB778FC0C8BDE80394AB2D8704D7129FB5771E2F1730D' | xxd -r -p | sha256sum -b

CD5C4A8E03DFBB0E3AA021C2D74A9EAA43CE4C9CB1B20FC88729A7A5834141CA

5.) Take the first 4 bytes of the second SHA-256 hash, this is the checksum

CD5C4A8E

6.) Add the 4 checksum bytes from point 5 at the end of the extended key from point 2

807542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027CCD5C4A8E

7.) Convert the result from a byte string into Base58 to get it into the Base58Check format. This is also known as the Wallet Import Format
(Converted from point 6 to base58 using https://bitcointools.appspot.com, or using encodeBase58 from https://github.com/grondilu/bitcoin-bash-tools)

5JhvsapkHeHjy2FiUQYwXh1d74evuMd3rGcKGnifCdFR5G8e6nH

A handy utility that does each step: http://gobittest.appspot.com/PrivateKey

This looks pretty good! I'll give it a shot Sunday (we're going 'cross state to see frozen waves tomorrow). Expect an 'accepted' soon! Oh, and very useful links.

Thank you very much. Everything's working really well now.
For future reference to anyone wanting to use Grondilu's Bitcoin Bash Tools: Source bitcoin.sh after extracting it into your directory.

The wording of step 7 is a little misleading.
You've already added the checksum in step 6, so in step 7 you should convert the hex to Base58, not Base58Check. Brainwallet.org has a converter. You can download the brainwallet source code from github and run it offline.

on Step 7 Convert the hex string back into bytecode before running it through base58...that step isn't very clear...Also I found that I had to decode my hex values back into bytecode for the sha digests but to then encode them back into hex so they were readable to my console (using python)

Something is wrong, here or at lenschulwitz.com/base58, where I use the input 7542FB6685F9FD8F37D56FAF62F0BB4563684A51539E4B26F0840DB361E0027C and the output for "enconde from hex" was 8tjwWnNgm3DrBEwCsPqbSAPkCspRRmA8ftHjQTycL3gw, not "5JhvsapkHeHjy2FiUQYwXh1d74evuMd3rGcKGnifCdFR5G8e6nH"


text:
bitcoins can use different algorithm, how and implications
I read that if sha-256 was compromised at some point in the future, or for any other reason, bitcoin could switch to a different algorithm
can someone detail how exactly that would work, and what the implications to existing blocks would be?
from my understanding, everything is hashed with sha-256, then another algorithm would be incompatible with all previous blocks....
can someone elaborate on this?
if bitcoin, or any cryptocurrency, switched algorithms, what would happen to people's current addresses and the ledger of transactions? In theory it should be very simple for major pools to switch to the new client, as has been done numerous times in cryptocurrency land, but I've never seen it done with a different algorithm.

It's a fair question to ask since Bitcoin could in theory switch to use the SCrypt Litecoin algorithm.  (hence there is no reason for Litecoin to exist)

thank you @makerofthings7 , scrypt or even something else.

The only way to do this would be to announce a new version of the protocol well in advance. It would need to co-exist in the same blockchain with the existing keys and transactions and be adopted over time.

First, the client software with support for the new scheme needs to see widespread adoption before anyone can use the new algorithm
Once that has happened, early adopters (probably mining pools) can start creating keys in the new format and the blockchain will accept them.
If that worked well, the standard client will default to making new keys
Some more time down the road, everyone can agree that transactions can only be done to new keys, forcing the "old money" out of the system eventually

Bitcoin could in theory switch to use the SCrypt Litecoin algorithm. (hence there is no reason for Litecoin to exist)

I don't think that would be a good move. If people decided that the Litecoin algorithm is better, they can just use Litecoin. Bitcoin should stick with its algorithm, but make adjustments to parameters such as key length when those become necessary.
Choice of algorithm should be choice of blockchain (Bitcoin vs Litecoin) and can be left to the "market" to decide.

obviously bitcoin vs litecoin or sha-256 vs scrypt is a false dilemma, so I think that can be ignored.