text:
What will happen, if transaction's rate becomes very high?
Let's imagine, that the bitcoin network becomes very responsive in the future. So, that the time of exchange of transactions between peers is comparable with a time of evaluation of a bunch of hashes. The bad situation comes, when the transactions rate is so high, that even if someone finds the new block, it becomes invalid with a very high probability due to the new accepted transactions.
Can this possibly slow down the finding of the new blocks? May this even be a problem, or do I miss something?

Transaction could not be added to already mined block: once the block is found and broadcast, it is set in stone and can not include new transactions --- they all go to the new block. The number of transactions in the block and their rate do not affect block difficulty. Besides, what do you mean by "verification": the check for tx validity or the time to "establish" transaction in blockchain by mining several blocks after it was included?

@aland No, I misused term "verification" - I mean the process of an appending of transactions to the current top block.

Please feel free to use the edit link under your question in order to clarify your question.

@Murch Done so. According to your current answer - I think, we don't clearly understand each other.

Ah, I see. A block doesn't become invalid because a new transaction came to pass. A block can verify any amount of transactions between 0 and block size limit to be valid. So, the miners could just change the dataset they are mining on only every minute, without any problem.

This will not slow down the finding of a new block, because it is not necessary to include every new transaction in the next block. Miners can decide which and how many transactions to include and can only update the transaction set they mine on at arbitrary times. They could for example only update the data set every time they receive a new block, or every minute.
below line is the answer to the previous edit of the question.

The scenario you describe cannot come to pass.
The Bitcoin network is self-regulating and automatically resets the difficulty every 2016 blocks to sustain an expected time of 10 minutes between blocks. The difficulty will be adjusted by up to factor four.
Extremely fast verification cannot be sustained
If a new block would be found every second in average (still magnitudes slower than your scenario calls for), the difficulty would be reset after 2016 seconds (33.6 minutes). The difficulty would quadruple, so in order to sustain that verification speed the networks hashing power would also have to increase four-fold in the same time! I am sure it is obvious, why the hashing power of the Bitcoin network will not quadruple every half hour for a significant frame of time.
Between blocks transactions are collected and verified together in the block
Every miner will collect all transactions transmitted to him, and whenever he tries to find a new block, he will try to include all unverified transactions together in that same block.
Once somebody finds a block, it will be broadcasted to the network and any receiving miner will check if it is valid and increases the length of his blockchain. If both is the case, he will accept it as a parent for the block he is trying to find. He will remove any transactions that have now been verified from his "unverified transactions" pool and will recommence to find a new block to verify the remaining transactions. Whenever more transactions are relayed to him, he will add them to his "unverified transactions" pool and will adjust the parameters of the block he is trying to find.
Blocks cannot be changed after they have been found! However, there can be several blocks that compete with each other to be accepted into the blockchain next, but such races will eventually be decided when a successor is found for one of the competitors. These "mini-forks" happen every once in a while, but is very unlikely that competing blockchain ends find new blocks several times in the row at the same time. Eventually, one will definitely be first and all other competitors become invalid.
Block size limit
There is some concern that the current block size limit will become a problem, because it cannot handle a sufficient amount of transactions. Should this come to pass, however, it would not change the amount of time between blocks, but rather that every block would be filled with transactions and transactions that didn't make it into the block to be on a waiting list for a future block. There is currently an ongoing effort to adjust the blocksize limit in order to support a bigger number of transactions per time.


text:
How can I prove control of HD wallet through message signing?
If I sign a message with one of the address from an HD wallet, does that prove control over the rest of the addresses created and will be created inside that HD wallet?

It proves that you control all children of that address (i.e. the ones further down the chain). It does not prove that you own the parents of that address (i.e. the ones further up the chain), since it's not possible (AFAIK) to go from a child to a parent key.

Thank you! Do you know how I can figure out the first address in an armory hd wallet?

Double click on the wallet to open it; the addresses are listed, with a "#" column. The one with a # of 1 is the first.

source: Stack Exchange

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

sort: votes


text:
How can I use multi signature addresses with Bitcoin Core?
Using the instructions on the debug window, I created a multi signature address as below:
addmultisigaddress 2 "[\"Address1\",\"Address2\"]"

MultiSigAddress

My understanding is that one needs the private keys of Addres1 and Addres2 to be able to spend from MultiSigAddress. Is this correct?
I sent some btc to MultiSigAddress, both Adress1 and Adress2 belong to me and I can go to coin control panel select MultiSigAddress as input. It will send the transaction without any problems.
What if one of the addresses belonged to someone else? How could I use the funds on MultiSigAddress using Bitcoin Core in that case?
Thirdly, the address I created in this case is 2 out of 2. What if I wanted to create an address that is 2 out of 3? How can I create that using Bitcoin Core? Or is that only possible for multi-sig transactions?

My understanding is that one needs the private keys of Adres1 and Adres2 to be able to spend from MultiSigAddress. Is this correct?
Yes that is correct
What if one of the addresses belonged to someone else? How could I use the funds on MultiSigAddres using Bitcoin Core in that case?
You will need the private key for both addresses (public keys) in order to redeem funds from the multisig address.  So you will either need to have the owner of the other address sign the the redeeming transaction or have them give you the private key so you can sign it.
Thirdly, the address I created in this case is 2 out of 2. What if I wanted to create an address that is 2 out of 3? How can I create that using Bitcoin Core? Or is that only possible for multi-sig transactions?
The following bitcoin core command will create a 2-of-3 multisig address,
createmultisig 2 '["key1","key2","key3"]'

You can view the full list of commands here

Re: the second point, this would be a way of using multisig to share funds between two people / wallets?

@Geremia that's right!

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


text:
BitcoinJ without PeerNetwork
I am writing a system which generates wallets on a per user basis. It must be capable to receive and send payments.
So I have to keep the private keys encrypted on the system.
Generating the private and public key with bitcoinj worked like a charm. At the moment I am struggling a bit with the Wallet class in bitcoinj.
I do not want to have any threads or connections "outside" of my application. So I want to avoid the usage of the PeerGroup.
I would like to create an offline transaction and then broadcast it myself. For example via blockchain.info or other services.
How can I do this with bitcoinj? I am reading a lot through the API, but I am missing deeper tutorials for my case.


text:
Are the outputs of an unconfirmed transaction part of the global UTXO pool?
Well basically that. If a transaction is in the memory pool, that is, it is not yet in a block but nodes and miners know about it and validated it, Can I send another transaction that double-spends the outputs? that is, are the outputs considered unspent?

It is not clear to me whether you are suggesting to doublespend the inputs or the outputs of the unconfirmed transaction.

Let's assume that there are two UTXO under your control, U1 and U2.
You use U1 and U2 to create a transaction T1 that would create U3 when confirmed. U1 and U2 therefore are inputs of the unconfirmed transaction T1 and U3 is an output of T1.
U1 and U2 are unspent, however another transaction T2 spending either or both of them would be considered a doublespend by any node that knew about T1 before.
Meanwhile, until T1 is confirmed, U3 is not part of the UTXO pool. Since the transaction is yet unconfirmed, the newly created output doesn't exist yet.

The transactions are considered spent from the nodes that already have the transaction in the mempool, that is, if you try to double-spend the transaction, they will reject the new one. However, if the transaction ends up not being included in a block, they will be dropped from the mempool after a certain time. After that, you will be able to create a new transaction that spends the same UTXOs, since from that point on it won't be considered double-spending.

Thanks. How much would taht time be? Because I sent a tx with such a low fee that it's taking too much time to get into a block and my last hope is for it to get dropped from the mempool of the nodes.

It could last a while, I don't know exactly how much, honestly. However, if you are in a hurry, you can use the solution from this answer: http://bitcoin.stackexchange.com/questions/51524/i-sent-out-a-payment-over-a-day-ago-and-its-still-not-confirmed/51534#51534


text:
About changed address
I am using electrum.
First, I had a bitcoin address and I used it once to receive BTCs and then it changed.
Will I be able to receive Bitcoins now, even if someone sends them to the old address?

Yes, you will still receive Bitcoin if someone sends to your old addresses.
Electrum uses mnemonic seeds to generate private keys which has corresponding public addresses (keys) - the ones you need to provide someone to send Bitcoin over to you. This means every transaction to addresses which are generated by your mnemonic seeds will still go to your Electrum wallet even when your receiving address is now changed.
Just in case you wonder why the receiving address keeps changing time to time: the ideas of changing public address every time you receive some Bitcoins is to keep your balance info private as with a public address since one can look up and list all transactions related to it using Bitcoin explorers such as blockchain.info.

Yes, you are still able to receive money sent to that address. Your Electrum wallet doesn't forget the private keys to addresses it displayed to you in the past and you can receive arbitrarily many payments to the same address. It just discourages using a single address to receive money more than once.
Receiving money several times to the same address causes privacy problems because people (or their computers) may be able to gain information about the payments someone receives and may even be able to identify you using additional information.
Electrum will always provide new addresses if you used the old ones. On a desktop computer (you can use the same Electrum wallet on different devices), you can see the used addresses by switching to the tab Addresses and expanding the Used category.


text:
Bitcoin cross trading from Bitstamp to Bitfinex
Bitstamp exchange price for Bitcoin is right now 1056.07 USD
https://bitcoinaverage.com/en/exchanges/bitstamp/btc-to-usd
while Bitfinex is 963.41 USD
https://bitcoinaverage.com/en/exchanges/bitfinex/btc-to-usd
Is it possible to exploit such a big difference to extract value? Probably this is a well known strategy on markets, but my finance knowledge is quite limited.
Is there any bot doing that kind of operations without human intervention? Thx!
Refs.:
Bitcoin trading at bitstamp
How Does One Make Money from Bitcoin Trading?
Need help understanding how to profit from bitcoin trading (like forex?)
Is there a forum-like exchange for trading Bitcoins person-to-person?
http://en.wikipedia.org/wiki/Order_book_%28trading%29

Nobody knows whether Bitfinex is insolvent or not. As a result, dollars at Bitfinex are worth less than dollars at other exchanges. This accounts for the price difference you see. To exploit this difference, you would have to send dollars to Bitfinex and command them to make what appear to be fraudulent transfers on your behalf.
See this article for more details. Some excerpts:

Bitfinex has imposed a haircut on all of their depositors.
For those whose deposits were not held in segregated accounts, there is no question that the deposits constituted general obligations, payable on demand, on the part of Bitfinex. To justify making anything less than a full payment on a general obligation that is payable on demand, a company would have to be insolvent or illiquid.
By definition, if you don't have sufficient assets to make the payments you are obligated to make, you are insolvent. There's no reason to think Bitfinex has assets that are not liquid. They imposed a haircut because they don't have assets to cover the funds their depositors have every right to demand from them. They are insolvent.
When you deposit funds at Bitfinex, they have your funds. You have a promise that they will repay you the funds you deposited. But you're just another creditor on their list of creditors. You get funds if they have them and not if they don't. Your deposit is another general obligation of Bitfinex, a company that is insolvent.

An insolvent company cannot make full payment to a junior creditor without court approval (or consent of all their creditors) -- such a transfer would be fraudulent. We know Bitfinex has not gone to court as they would have to have given notice. When you deposit money at Bitfinex, you become a junior creditor. When you command a trade or withdrawal, you are commanding full repayment of yourself, that is, you are ordering them to make a fraudulent transfer on your behalf.
Fraudulent transfers are subject to clawback. That is, if you trade at Bitfinex, you may eventually get a letter from a trustee or receiver demanding you repay the money you made or even the full value of the assets you withdrew.

But at kraken.com xbt/usd is 1057.58 and Bitfinex rate is 963.41, similar to Gdax 967.42. Any problem with kraken too?

Kraken is fine. That's why the rate at Kraken reflects the rate at other reliable exchanges. Bitfinex is (was) the outlier. When you see a rate at an exchange that's far out of whack, something is almost certainly wrong with that exchange. (If you don't know why it's out of whack, trading to exploit that difference is very risky.)

So, are you saying that Bitfinex is fraudulent? What makes you say that other exchanges are not?

I'm not saying Bitfinex is fraudulent, just that there happened to be an incident at that time that caused people to value money at that exchange differently.

I've just found the concept for this practice and wanted to share:
https://en.wikipedia.org/wiki/Arbitrage
In economics and finance, arbitrage is the practice of taking advantage of a price difference between two or more markets: striking a combination of matching deals that capitalize upon the imbalance, the profit being the difference between the market prices.

Interesting... https://www.cryptocoincharts.info/arbitrage


text:
BTC transaction cost vs fees
According to https://ethereum.stackexchange.com/questions/11/how-do-ethereums-transaction-fees-compare-to-bitcoin current BTC transaction fees vary anywhere from $0.01 to $0.09 USD.
But according to https://blockchain.info/charts/cost-per-transaction and Can it really be true that the Bitcoin system consumes almost $1.000.000 in electricity per day? BTC costs $14 per transaction.
That's a huge difference, 3 orders of magnitude. Shouldn't be the same (or similar at least) transaction cost and transaction fee? What I am doing wrong?

Miners also get a 12.5 BTC reward per block, which is roughly $7,500 at current prices. This is the main reason miners are willing to spend so much to mine a block. The transaction fees themselves don't add up to very much when compared to the actual block reward, usually.
The mining subsidy slowly fades away, however. Every 4 years, the amount of new bitcoins created in a block gets cut in half. At a certain point, either there will be more transactions paying fees, more fees in the same amount of transactions, or mining will become less expensive (or some combination of the three).
I should note that the cost of a transaction is not really $14. The actual cost to send the transaction bytes to peers and save the data on disk is fairly minimal for any individual miner.


text:
Are there clients that manage several alts?
E.g. a desktop client that can manage, in a unified UI, Bitcoin, Namecoin, Litecoin, PPCoin...?

https://bitcointalk.org/index.php?topic=264219.0

@LittleBobbyTables - my situation - I am writing a product that deals with various alt currencies. My problem - how to deal with various alt currencies (receive, send) using a simple API. Stack Exchange close reasons are beyond me, if the consensus decides to close it, so be it.

possible duplicate of Is there a wallet for different cryptocurrencies

I don't see this question as seeking a product recommendation; it's asking whether a product exists.

Ufasoft open source client can manage different alt-coins, most of them with same private keys.
https://bitcointalk.org/index.php?topic=58821.0
PD: be careful, some users have reported malware in Ufasoft mining software.


text:
Does Satoshi Dice owe its customers money? How come?
From this analysis thread:
SD Profit after fees:       22476.66146080 BTC (1.688%)
Pending Liabilities:         6821.78965204 BTC
Final SD Profit:            15654.87180876 BTC

...

From now on my reports will include this 'pending liabilities' figure
  since it's really getting out of hand.  There are bets going back 5
  days which haven't been paid out, almost all of them are winning bets.
  In total SDICE currently owes its customers around 6800 BTC, or around
  $91,000 US in unpaid bets.

How come there are unpaid bets going back 5 days? Does Satoshi Dice always pay immediately?

SatoshiDice pays most bets instantly, but for whatever reason sometimes bets get 'stuck'.
The issue you're referring to in your question happened during an exceptionally high volume period for SatoshiDice.  They received over 70,000 BTC worth of bets in a 24 hour period, which is much higher than usual.  The high turnover apparently causes issues with paying out in a timely fashion.  This was compounded by a bug which caused too much of SatoshiDice's BTC holdings to be transferred into cold storage.
As of this morning there is only one bet that hasn't been paid out.  It was a bet for 0.35 BTC, and it lost.  So to answer your question "No, they don't currently owe their customers money.  But sometimes they do fall behind for a few days".


text:
How do Javascript-based wallets generate random numbers and is this cryptographically secure?
Hybrid wallets and some paper wallet generators create private Bitcoin keys using Javascript inside the browser. Which source of entropy do they use? How do they make sure the PRNG is suitable for long-term security?


text:
What’s prevents people from appending useless blocks to very old blocks in order to revert new transactions?
As far as my understanding goes, nodes in the network should accept the longest branch of blocks and disregard any other branches (excuse my terminology if it’s not what’s normally used - I hope it is clear what I mean).
If this is correct, I am wondering what would prevent me from creating my own node in which I append blocks to very old blocks. These appended blocks could contain transactions from my address to another one of my addresses for example (just to make sure the block is valid - I’m assuming there are some constraints on what makes a block valid, like amount of transactions or bits in a block). After probably a long while I would have a branch that has outgrown the current branch, undoing all transactions from the block my node started with to the current active block, and instead replacing all of those by my useless transactions.
What is preventing me from doing this? I know that I would still have to mine these blocks, and understand that this would probably be a the main thing preventing me from doing this right now.
However, as I understand, mining difficulty is determined by the amount of blocks mined in a certain time. Say that the BTC network becomes useless one day for some reason, and almost no new blocks were created, would it then be possible to execute this (after a long while to keep the difficulty of my own mined blocks low)
Thanks for any answers in advance. If BTC does ever become obsolete and unused it’d be cool to magically be able to erase everything (if there are still nodes around that is)

The short answer is that "the longest chain" is just a simplification; the actual criterion is "the most-work chain that passes all validity rules". Just adding blocks does not help, if those blocks have a low difficulty ("work" is informally defined as the sum of all difficulties in the chain).

That makes a lot of sense! Thank you :)

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


text:
Who earns transaction fee in Ripple?
In Bitcoin, fees are earned by the miners. Who earns the transaction fees in Ripple?

The transaction fees in Ripple are simply destroyed. There is no mining.
We had to use ripples because we couldn't use dollars, both because dollars in Ripple can only be represented as debt (Who would owe them to the system? Who would they go to?) and because Ripple is intended to be cross-currency (How would you manage exchange rates?).
The beauty of ripples is that the network can destroy them and they require no central authority. In the future, if ripples become unusually scarce or plentiful, the XRP cost of transactions can be adjusted by consensus.

"... the XRP cost of transactions can be adjusted by consensus." Is this the same consensus process that is used to process transactions? Exactly the same, or some variation of it?

@Manish: It's the same except that there's an extra step. Validators publish (in selected validations) what they want the fee to be. Then validators can introduce a pseudo-transaction into the transaction set that changes the fee. If the pseudo-transaction makes it into the consensus set, the pseudo-transaction is applied and the fee changes. The same process is used for changing reserve levels, and an almost identical process is used for enabling new features or making rules changes.

Technically XRPs have no counter-party risk as long as no single entity (including OpenCoin, Inc) does not have enough of them to corner the market.  Perhaps a better name for this would be Systemic Risk ?


text:
Move all coins from an address via RPC
Let's say I generated some coins with a given address and I want to send a specific amount of coins to a specific addresses, and move the remaining balance to another specific address. I want to do it all using bitcoind and an RPC call. It would be easy if it wasn't for the variable fee, based on the size of the transaction; just calculate the difference between what is in the first address and what needs to be paid out, and send the rest to the other address.
Is there some way to set an address in bitcoind that is to receive all the change, or to get some information on what the fee for the given transaction should be?

Given that you only want to spend outputs received to a specific address, you would start by retrieving all unspent transaction outputs received to that address with listunspent.

bitcoin-cli listunspent 1 9999999 "[\"your_address\"]"

Then you can use the output of the listunspent call as the inputs of send, set a feerate, specify the specific recipient and amount, and define a change address.
Let’s use the syntax with named arguments to skip the positional arguments we don’t care about.

bitcoin-cli -named send outputs='{"specific_address": specific_amount[BTC]}' fee_rate=[sat/vB] inputs=[{"txid":"a08e6907dbbd3d809776dbfc5d82e371b764ed838b5655e72f463568df1aadf0", "vout":1}, "txid":"d3d809776dbfc5da08e6907dbb82e371b764ed838b5655e72f463568df1aadf0", "vout":2},…] change_address="your_change_address"

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


text:
Pros and Cons of using HDD or USB Flash drive (script mining)?
Could someone share his/her experience of using USB flash drive over HDD?
I know that the only purpose of both is to store the OS. I am going to use Ubuntu 13.10 which I believe will fit 8 GB USB since it is said to required 5 GB free space.
I am looking for best practices of choosing USB flash drive since like storage and speed requirements(brand may be) and is there any factors (like not enough storage for update/performance/burn/block that can make it clever to chose the HDD instead.

How can HDD and USB be related? One is a physical computer component and the other is a peripheral protocol. Mind clarifying?

@JacobTorba Yeah, you are right - I mean USB flash drive. The question is corrected.

This question appears to be off-topic because it is about OS storage and hardware; probably better asked/moved to a different SE.

@dchapes it is about which is the better one when you are mining - this is the right SE.

Assuming the rig is dedicated to mining, it is best to use a USB flash drive because it is much less expensive than a hard drive, making your mining rig much more profitable.
It also uses less power and generates less heat, both of which also make your rig more profitable.
Then there's always the point of having no moving parts, making breakdown less likely.  Again, that relates to profitability.
Again, all of this assumes that you're going to use the rig exclusively for mining.  If you want to use the rig for other purposes, such as occasional gaming, then using a hard drive might make sense.

It's best to choose the HDD because it's easier (all computers should have one), and faster than the USB drive in most cases. But it shouldn't really matter.
Why it doesn't matter
Mining is not storage intensive, you aren't storing massive amounts of data when mining. You aren't even storing data when mining. It's all stored in computer memory, think RAM. A faster storage could only help with downloading the block chain in faster time, which won't improve your mining as it is only done once and finally.
But don't go buying up RAM as well. You mainly mine Scrypt coins with a graphics card and those have plenty of on-board memory. And if you are CPU mining you shouldn't be.


text:
Are public keys and their corresponding hash values both added to a BitcoinJ Bloom filter?
The paper, On the Privacy Provisions of Bloom Filters in Lightweight
Bitcoin Clients has this to say about Bloom filters in SPV:

...Indeed, in current implementations of SPV clients [BitcoinJ], both
  the addresses and their public keys are inserted in the outsourced
  Bloom filter. As such, if the adversary knows both the address and
  its public key, then she can trivially test whether an address is a
  true positive of the filter by checking whether both the address and
  its public key are inserted within the filter. If not, then it is highly
  likely that the address is a false positive of the filter. We believe that
  the inclusion of both the address and its public key in the Bloom filter
  is a severe flaw in the current SPV client implementations—and
  can be easily countered; we thus do not exploit this flaw in our analysis.
  In fact, more than 99% of all Bitcoin transactions consist of
  payments to Bitcoin addresses (or the public key hash); moreover,
  only 4587 out of 33 million total addresses in the system received
  transactions destined for both their public keys and their public key
  hashes. This means that for the vast majority of Bitcoin clients,
  there is no need to include both the public keys and their hashes
  (i.e., the Bitcoin addresses) in the Bloom filters; inserting one or
  the other would suffice (in more than 99% of the cases). [my emphasis]

The idea behind this attack was re-iterated in Privacy in BitcoinJ:

The vulnerability is that if a pubkey is truly in the filter then querying both pubkey and pubkeyhash must return true. Because the pubkeyhash is just another almost uniformly random string, the probability of a false positive for the attacker is fp' = fp^2 = 0.0000000021555. I obtained around 56 million pubkeys from the blockchain (mid-January), which theoretically results in 56 million * fp' = 1.29 expected false positives when scanning the blockchain.

In other words, a simple attack is enough to pick out all of the public keys from a BitcoinJ Bloom filter.
Does the current release of BitcoinJ add both a public key and its hash value to its Bloom filters? If not, which release stopped it from occuring?
Also, why were both public keys and hashes added in the first place?

Does the current release of BitcoinJ add both a public key and its hash value to its Bloom filters? If not, which release stopped it from occuring?

Yes. The following code implements it:
/** Inserts the given key and equivalent hashed form (for the address). */
public synchronized void insert(ECKey key) {
    insert(key.getPubKey());
    insert(key.getPubKeyHash());
}

(Source.)

Also, why were both public keys and hashes added in the first place?

I'm not the guy who wrote this (Mike Hearn). That said, I would guess that it's difficult to tell whether deposits to an address will be in P2PKH or P2PK form. Pay to Public Key is really uncommon, but it is legal. Given the choice between having some of his customer's money go missing for mysterious reasons, or reducing their privacy, he chose the latter.
Now, if you're asking why filterload doesn't just take the HASH160 of a key before comparing it to the bloom filter so that a thin client can look for both the hash and the key at the same time, I don't know. That seems like it would fix the problem mentioned in that paper for a pretty reasonable amount of CPU time. I would blame the author of BIP37, but that was written by the same guy.

If a SPV client wants to monitor its wallet balance, it has to track both incoming funds - transactions with outputs containing the wallet public key hash (the bitcoin address), as well as the outgoing funds - transactions with inputs having the wallet public key in their signature script. (Of course the SPV client has to monitor all the pub keys / addresses that the wallet has generated.)
One could say that tracking the outgoing funds duplicates the auto-updating functionality of the bloom filter, but I guess the use case here is a SPV sync from an arbitrary block height.


text:
How Do I Fix: "Safe mode: Warning: Displayed transactions may not be correct!"
While trying to retrieve the private key from satoshi bitcoin client i'm getting this error code:
Safe mode: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade. (code -2)
Does anyone know how to fix this?
It is QT VERSION 4.8.2 & v0.7.2-beta in the lower right hand corner it says it is catching up but has not added any blocks for a really, really, really, long time, it sitting on 90.13% . What else do you need to know?
I am Technically inept so I need to be clear so I dont screw up. I NEED THE PRIVATE KEYS for 2 ADDRESSES generated by this bitcoin-qt, when I type in dumpprivkey address I get the above error message. Will upgrading cause a conflict?  What is the proper way to upgrade as I dont see that as an option?

Are you sure this is the bitcoin client and not some other coin? What version of the client do you have?

If it is about Freicoin, this message was showing up because there was a malevolent hard fork (didn't followed freicoin rules) that has been actually longer than freicoin's chain for some time. When the client sees a longer chain that doesn't follow the rules it enters in safe mode, disabling some features such as sending coins.
The attack seems to have stopped, but you may need to run the client disabling the auto-safe-mode stuff.
Is it about Freicoin ?

Before anything: make a backup of wallet.dat, by using the backup function in the menu. Then, just install 0.8 and let it rebuild its database.

Typically, this is caused by a corrupted block chain database - it causes your client to consider the real chain invalid, and try to find another one. Since the real chain remains the longest obviously, it shows this warning, as it notices its opinion differs from the rest of the network.
The solution is deleting blkindex.dat/blk000?.dat and let redownload the chain. In case you're running 0.8 (if not, upgrade), you can just use -reindex to rebuild the database (no downloading necessary in that case).


text:
Mediated transfer of funds between three parties
Alice wants Bob to transfer 10btc to Carol, and is willing to pay Bob 11btc for the transfer.
They both entrust Trent to mediate the transaction, and Alice is willing to pay Trent 1btc as commission.
What is the correct and most secure protocol for performing this contract?

Edit: does the following protocol make sense?

Alice broadcasts a transaction (Tx1) with 2 outputs:

11btc with an output script specifying 2-of-3 multi-signature verification, specifying Alice, Bob and Trent as recipients
1btc to Trent (commission)

Bob verifies Alice's transaction:

Verified: Bob broadcasts a transaction (Tx2) sending Trent 10btc
Rollback - Bob is unsatisfied or fails to transfer the funds to Trent: Trent broadcasts a transaction (Tx3) sending Alice her 11btc back, specifying Tx1's first output as an input and signs the input. When Alice wants to spend Tx3, adding her signature to the input satisfies the 2-of-3 requirement (and the process stops here)

Trent broadcasts a transaction (Tx4) sending Bob the 11btc, specifying Tx1's first output as an input. When Bob wants to spend Tx4, adding his signature to the input satisfies the 2-of-3 requirement
Trent broadcasts a transaction (Tx5) sending Carol 10btc, specifying Tx2 as an input

Why doesn't Alice pay Carol 10 BTC herself, then pay 1 BTC to Bob?

Theoretically, Alice wants plausible deniability regarding the transfer of funds to Carol.

The Bitcoin protocol can do M of N transactions, but the clients don't yet support it.  The solution will be coming.

Thanks Stephen. What I'm looking for is the best security protocol for fulfilling the contract (preserving the plausible deniability of Alice, making sure Alice and Bob transfer funds, and enabling Trent to rollback the transaction), regardless of client implementation.

For clarification, as far as "plausible deniability", it should appear that the final decision to transfer funds to Carol was made by Bob and/or Trent, not Alice?

Also, is Bob supposed to front his own 10btc to Carol and then be reimbursed, or does it have to come out of the coins he gets from Alice?

Your protocol makes sense, but i would modify it as follows

the 1btc sent to trent should also be mutlisig with Alice's signature as the 2nd one, so that if Trent fails to do what he promised he gets no commission. ((the 1btc will stay in limbo, unless Alice and Trent can somehow work this out)
The Tx2 should also be multisig and Carol's signature should be added, that way Trent can't run with the money.

There is BTCrow (http://btcrow.com/) and ThruCoin (http://thrucoin.com/create), which both look like they will perform the services you need.

Thanks @cjastram, but I'm not looking for a service that implements it but for a description of the best information flow between parties. Also note that Carol is an uninvolved 3rd party, if that makes any difference.


text:
Is BitcoinJS under active development?
I love the idea of a powerful alternative to bitcoind, and especially the ability to subscribe on blockchain events and easily process them on the server side.
However, I see the last activity on the BitcoinJS code is 7-10 months ago.
Does anybody know the status of the BitcoinJS projects or can suggest alternatives?
Update: I'm now looking into bitsofproof supernode, a project that looks really promising.

I don't know the answer, but I just asked the same question in bitcoinjs google group: https://groups.google.com/forum/?fromgroups=#!forum/bitcoinjs

Not sure but I think those guys started working on the Ripple project instead. They are skilled JS developers and they want to do something of their own with Ripple.

It seems like BitcoinJS had one major developer, justmoon. He's now contributing to the ripple client repository; I think that's accurate.


text:
Closed wallet in MultiBit, is it gone for good?
I have just installed MultiBit and transferred my bitcoins into it.
I closed the wallet using "close wallet" in the file menu, thinking that it would save it, but it seems to have not just closed it but removed it from existence.
Is this just a lesson not to be so stupid in future?
I still have a record of the wallet address, but that's it.

The user crowther had his wallet stored in:
C:/Documents and Settings/"user name"/AppData/Roaming/MultiBit


text:
Converting satoshis to bitcoins issue using PHP
I am having PHP calculation problems (I think - i am reasonably new to PHP).
I am using
function convertToBTCFromSatoshi($value){
    $BTC = ($value / 100000000 );
    return (float)$BTC;
}

If $value = 10000 the result is correct of "0.0001"
Yet if $value = 5000 the result is "-5.0E-5"
Any ideas please :-)

why the -1 ? it was a genuine question!

Please note that one should never use floating point in money calculations, as it may lose accuracy. http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

This question appears to be off-topic because it is about php programming.

You really should not use floating point math for precision decimal values.  It is a little-regarded truth of computer programming that when you're dealing with money you should avoid the usual IEEE floating-point math like the plague.
This is the reason why Bitcoin transactions store values as 64-bit integers.  Because storing them as floating point numbers is error-prone.
For example, in your interactive PHP shell you can do something like this to find out where your math begins to break:
php > echo 10000.00000001 * 2;
20000.00000002
php > echo 100000.00000001 * 2;
200000.00000002
php > echo 1000000.00000001 * 2;
2000000

I'm running 64-bit PHP, too.  If you are running 32-bit PHP the situation becomes pretty dire.
The take-away here is that overall precision of floating point numbers is limited.  The bigger your number, the fewer meaningful decimal places it can have.
The correct way to address this problem is to use PHP's BC Math functions.  You keep your data as strings, and BCMath will let you perform arbitrary-precision computations.  It isn't as fast as floating point math, but it isn't exactly slow either.
/** Convert Satoshis to a string that can be displayed to users.
 *  input: $value Integer or string that can be parsed as an int.
 *  output: string (eg: "1.00400000")
 */
function convertToBTCFromSatoshi($value){
    return bcdiv( intval($value), 100000000, 8 );
}

If you want to trim the zeros from the end of the output, you can use the trim() function:
rtrim($value, "0"); // trim zeros from the right-hand side

Is that really a serious risk? Are you really afraid that someone will get 1 million BTC together - to steal 1 satoshi from you?

It's also about small rounding errors, and decimal values that can't be precisely expressed in binary.  And don't forget, Bitcoins are meant to be infinitely divisible.  It is generally accepted that the protocol can be changed to support smaller units, if required.

You should use bcmath, because PHP's native calculations won't fit your needs.

Or GMP

The calculation is correct, but it becomes wrong when it shows the result to you.
Code:
function convertToBTCFromSatoshi($value) {
    $BTC = $value / 100000000 ;
    return $BTC;
}
function formatBTC($value) {
    $value = sprintf('%.8f', $value);
    $value = rtrim($value, '0') . ' BTC';
    return $value;
}
echo formatBTC(convertToBTCFromSatoshi(5000));

Outputs:
0.00005 BTC

works perfect! sent a small BTC Tip

The valid range for satoshis won't fit into an int on php32bit. so you need to use strings, and bcdiv, NOT native division as this answer indicates.

Satoshi to BTC
(Mathematical formula: Value * 10 ^ -8):
$satoshi = 5000; //Satoshi to btc
echo number_format(($satoshi)*(pow(10, -8)), 8, '.', ''); //Returns 0.00005000

BTC to Satoshi
(Mathematical formula: Value * 10 ^ 8):
$btc = 0.00005; //Btc to satoshi
echo ($btc)*(pow(10, 8)); //Returns 5000

Explanation
pow() - Exponential expression
number_format($var, 8, '.', '') - Returns a number eight decimal places

The standard mathematical operators in PHP are limited by the system's build - 32 or 64bit. This means your Satoshi to BTC conversion will be wrong on a 32bit system for values larger than 2^32. It's advised to use bcmath to convert between BTC & Satoshis. I typically use GMP on the satoshi amounts after, since it's faster.

I am pretty sure you have found an answer by now, but for the sake of others. here is a pretty good way to solve that using bcmath's bcdiv

(PHP 4, PHP 5, PHP 7, PHP 8)
bcdiv — Divide two arbitrary precision numbers Docs

$value = 5000;
$convertToBTCFromSatoshi = (function ($value): string {
  return bcdiv((string)$value, '100000000', 8);
})($value);

Easiest way
sprintf('%.8f', $amount); // 0.00000000

webdev1, please use code formatting when posting code. You can click edit on your own post to see how I did it.

Since you have not picked an answer, can I suggest a function? It is sufficient to handle your BTC transactions
function btc_output($x) {
    $f = sprintf('%0.08f', $x);
    $f = rtrim($f,'0');
    $f = rtrim($f,'.');
    return $f;
}

$v = 5000/100000000;

echo btc_output($v); // 0.00005


text:
How much should I charge a client if they pay me in bitcoins?
The price of bitcoins fluctuates rapidly against other currencies. If I were to go to a restaurant and pay for a meal in bitcoins the price at the start of the meal would almost certainly be different by the end of the meal. In fact I have heard of this behavior happening in countries undergoing hyperinflation.
So how should I charge a client for a service when price of bitcoins change?  How should you pay employees an hourly rate in bitcoins when the price changes for each hour?

For many years here in israel rent was quoted in dollars but paid in shekels at the current day's exchange rate. So you could quote the price in dollars and ask to be paid in bitcoin at the rate on some well known exchange

For the scenario of a retail or ecommerce purchase, one approach is to have an expiration on the price quotes.  For example, when a merchant uses BitPay, the invoice is good for 15 minutes.  If the funds aren't received, then the payment is recalculated as-of the time it arrives and if it overpaid, the customer gets a refund and if it was underpaid the customer has to send more funds.
Also, you can pad the exchange rate to your favor a little so that while some transactions lose value because of a change in the exchange rate, others will be in your favor but when you net it (overall gains minus losses) it ends up about a wash or a small gain.
Coming up with the pad amount can be aided by using a calculation that looks at recent volatility.
As far as contractors, you would want to contract that in advance.  So if both parties agree to a contract at a certain rate quoted in BTCs, then that is the agreed upon rate that is paid.
For salaries, you probably want to establish that in terms of fiat, and only after withholding for taxes and other deductions only them convert the net check amount into bitcoins at the prevailing rate at the time.
A company that has BTC-denominated contracts may want to hedge against exchange rate risk by either acquiring sufficient coins in advance, or using derivatives (e.g., CALL options or futures contracts).

In a perfect world, and if you consider Bitcoin a true currency, then the only price that matters is the amount you value your work in relation to what you can buy and do with the currency.  But of course, since you currently can't use Bitcoin to pay the necessities of business like rent, electric bill and phone bills, the problem you mention is real.
The only real advice I can give is to watch the market for points of stabilization and price your coins according to what you believe the real market value of a coin is going to be at the time you will need to convert them to pay your bills.  Also, you should carry enough cash reserves in a more liquid currency to cover you in times when coins are lower than expected.  In those months, use your cash reserves.  When coins are high, sell extra to replenish cash reserves.
A safe bet right now IMO would be to value a coin at about $10. That seems to be a recent plateau that makes sense and with adequate cash reserves, you should be able to float the spikes and dips without a problem. Of course, keep your eye on the exchanges for movements and if there seems to be a longer plateau and your reserves are getting low, then you will probably have to revalue your work.

If you're still valuing BTC at $10 I'll pay you $12.50 for each one.  ;)

@makerofthings7 Wait a day or two, and we are there again...

Put the price in USD (or local currency). Let them pay in BTC at true rate in the moment they pay. In some occations it may be wise even to give a discount when paying with BTC.


text:
Apart from the official bitcoin client what other clients are there?
Apart from the official client found at the bitcoin.org site what is the list of alternative bitcoin clients? And what OS do they work on?

As far as I know the official client is currently the only client capable of doing full transaction validation. (BitcoinJ, libbitcoin, and Armory don't do full validation. Some other clients rely on bitcoind or the partially-validating clients.)

There is a current list of clients here
http://en.bitcoin.it/wiki/Category:Clients
There is development discussion around alternative clients here
http://bitcointalk.org/index.php?board=37.0
Currently the "Official Client" (more specifically, the Satoshi client) is the most widely used and has implementations that run on Windows, OS X, and Linux. However, multiple alternative clients have been developed, including ones that run on Android, and this is currently a high priority for the bitcoin community.
The current most popular alternative clients are BitcoinJ, written in java
http://code.google.com/p/bitcoinj/
and BitDroid, which runs on Android
https://github.com/cdecker/BitDroid-Network

I upvoted this but I feel it's worth noting that BitcoinJ and BitDroid aren't really "clients" per se - more like engines. I know technically they satisfy the criteria in the same way that bitcoind.exe does, but when most folks say "clients" they're probably expecting a fully functioning app with a GUI.

yes, that is very true. Perhaps worth noting that they are still more suitable for developers to build GUIs and other features around than useful on their own for the average user at this point.

I found this site which has an alternative client http://multibit.org/

The list of current clients is quite useless. It does not say which clients are desktop versions, etc and some links are dead

yes someone should submit a new answer, or re-ask the question and answer it. Unfortunately, lots of questions like these are going to be time-limited in the bitcoin world.

LoveBitcoins.org has a list of clients for various platforms.

It's missing a lot of more common clients.


text:
Are there any hosted online store solutions (a la Shopify.com) that are compatible with bitcoins?
Are there any hosted online stores that can be set-up easily to take bitcoins?

AFAIK there are no publicly available out of the box solutions for setting up a store that uses Bitcoin. Although; there are many viable solutions using Bit-pay, their system integrates well with most platforms. If there is a platform you want to use their system for, their sales team can surely help you do that.
I have no affiliation to Bit-pay but spoke with one of their founders in length at the Bitcoin conference.
I would recommend looking into setting up a wordpress site (hosted, not wordpress.com), using ecwid shopping cart, and asking bit-pay to integrate the store into ecwid for you.
This setup is a 99% one size fits all, and you would be pioneering the way for others to follow. Bit-Pay may have an alternative solution, but I have developed several online stores (10+) for clients - and use wordpress/ecwid for both of my personal stores (after trying many others).

I created an osCommerce module that can enable you to setup a full webstore that accepts Bitcoin. It enables osCommerce to talk to your own Bitcoin daemon with orders being updated once payment is received. Then the funds can be sent on to an address off your webserver to reduce risk of storing too many bitcoins on the server. Also keeps your BTC prices updated from prices set in USD.
The module is here: https://github.com/weex/oscommerce-bitcoin


text:
Upper limit on the blockchain file size with pruning?
If blockchain pruning is implemented is there a theoretical upper limit on the blockchain file size?
My thinking is something like with "pruned" blockchain you only store the details of the unspent bitcoins, so even if every satoshi was sent to a unique address then the file to store this information would have a finite upper size limit. Is this correct? And ballpark what file would the file size be?
If there is a reasonable upper limit and with likely continuing reduction in storage costs (i.e. Kryder's law, similar to Moore's law but for storage) then the criticism about the size of the blockchain file may become irrelevant.

As transaction outputs are allowed to have amount 0, there is unfortunately no upper bound. That is one of the reasons for making such outputs non-standard in 0.7.0.

OK, thanks for that clarification. Can we assume that in the future all outputs will have non-zero outputs after the 0.7.0 changes?

Non-standard certainly doesn't mean outlawed. It just means that an (unmodified) reference client will not relay or mine such transactions, but if some miner puts it in a block, the network will accept with without problems.

Assuming all remaining transaction outputs are 0.00000001 BTC (1 satoshi), with one single ouput per transaction left, and all assigned to standard pay-to-pubkey-hash addresses, I'd say the minimal upper bound on the pruned blockchain size is 21M * 10^8 * 54 bytes, or about 113 petabyte (100 pebibyte).
The 54 bytes per transaction, is calculated as 32 txid bytes, 1 info header byte, 1 byte to store the amount, 20 bytes to store the pubkey hash (address).


text:
How much of BIP 62 ("Dealing with malleability") has been implemented?
BIP 62 lists nine source of malleability:

Non-DER encoded ECDSA signatures
Non-push operations in scriptSig
Push operations in scriptSig of non-standard size type
Zero-padded number pushes
Inherent ECDSA signature malleability
Superfluous scriptSig operations
Inputs ignored by scripts
Sighash flags based masking
New signatures by the sender

...and proposes new rules that would fix the first seven. How many of these fixes have been implemented in Bitcoin Core?

Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules.  Here are some details:

Non-DER encoded ECDSA signatures

These are currently non-standard, so Bitcoin Core nodes (since 0.8.0, IIRC) by default won't relay or mine them.  When the BIP66 soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.

Non-push operations in scriptSig

These are also currently non-standard, and are completely forbidden for signature scripts spending a P2SH output.  I don't know when they were first made non-standard, but I suspect it was 0.8 or before.

Push operations in scriptSig of non-standard size type

These were made non-standard in 0.9.0, where they're called "non-canonically-encoded serialization sizes".

Zero-padded number pushes

This will be non-standard in 0.10.0.

Inherent ECDSA signature malleability

This is currently allowed, and several popular Bitcoin programs still do create full-range signatures.  Getting those programs to update to using only low-S values before BIP62 is implemented would be nice, but it isn't critical because the new BIP62 validation rules will only apply to version 2 transactions.  Programs that don't update will still be allowed to create version 1 transactions even after the soft fork.
The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.
Edit: an earlier version of this section incorrectly said getting programs to create only low-S signatures was critical.  Thanks to @PieterWuille's comment below for pointing out my error.

Superfluous scriptSig operations

Non-standard since 0.6.0.  In master, this test has moved here.

Inputs ignored by scripts

This is partly addressed in 0.10.0, but see the note below.

Sighash flags based masking
New signatures by the sender

Per BIP62, "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable."
In short, rule 7 doesn't have a complete solution and rules 8 and 9 don't have any solution.  (Indeed, the malleability from 8 is a feature, and fixing 9 would require a different signature scheme.)

Excellent answer, thanks! I especially appreciate the references.

One comment about 5: it's not actually required to have other wallet software use the low-S range before BIP62 can be deployed, as this rule is only planned to be enforced for transactions with an increased version number (making it completely opt-in, even after the 95% threshold for BIP62 is reached).

@PieterWuille oh, bugger, I forgot about that.  I'll update the answer.  Thanks!

@DavidA.Harding, did you mean v3? I thought v2 was being skipped as a transaction version to avoid confusion with the upcoming v3 blocks.

@RichApodaca I believe the current plan, as discussed on the mailing list and seen in this pull request/commit is to enforce the BIP62 rules on v2 transactions.

According to statuses of proposed BIPs implementation into Bitcoin Core #62 is in status Draft. This means that none of the seven proposed "fixes" have been implemented, yet.
Source: https://github.com/bitcoin/bips

Thanks for the info. Do the new rules apply only to confirmation, or relay/mempool as well? For example, new rule #2 (non-push operations in scriptSig) appears to part of the IsStandardTx check in v0.10.0 RC3: https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L678

That doesn't mean a lot. BIP42 is still in draft stage too.


text:
How can I find out if a transaction used a specific vout as its input?
I want to know if a certain output is spent. I am not using bitcoind, I do not have a gettxout RPC call available. How can I learn if a vout is referenced as an input somewhere in the blockchain or accepted mempool?
I don't mean just for my wallet, I want to know if an output has been spent on the network somewhere.

You need a way of querying the unspent pool in order to do this. A workaround is to lookup the transaction that is being referenced via some public api, blockchain etc, and check the referenced output as they usually mark them as spent/unspent. You can do this programatically by querying for all unspents for the addresses referenced by the output in question and filtering it for the one you want.


text:
How to tell which account an unspent output is in?
When I go to send coins, I want the transaction to ignore the unspent coins in a certain account.
I think I can do this in wallet.cpp, but I'm not sure how.
Maybe in the AvailableCoins() function? Make it continue if the coins are in this account? I guess I need to create a function like:
bool isInAccount(string strAccountName, CWalletTx *wtx)

How can I go about doing this?

Your question is based on a misunderstanding of the account system. It's a very common misunderstanding, though.
Unspent outputs are not associated with accounts.
Incoming transactions credit the balance of the account associated with the address the transaction is received with. But accounts only have a balance - they don't 'own' the coins sent to them. Account balances can go negative, and can be modified through the move command, without changing the coins.
The unspent outputs belong to the wallet as a whole, and accounts just keep track of who/what owns which amount of them - not which ones specifically. It is like keeping a wallet around with money that both belongs to you and to a friend. You keep track of how much you owe your friend, but you don't keep track of which specific notes or coins in the wallet belong to them.
To do what you want, you either need to use separate wallets (which keep the coins separately entirely), or use coin control or the raw transaction API, which allow you to specify manually which coins to use.

Pieter, wouldn't it be better if the accounts feature did function this way, associating UTXOs with specific accounts, and then only spending from an account's UTXOs? If no account is specified, then the software could take that to mean spend from any/all accounts' UTXOs. It seems that's how most people expect/want it to work. Maybe the issue with doing this is with backwards compatibility?

That's a completely different model, and no, that won't happen. The accounts feature will likely just be deprecated and removed somewhere in the future.

What you're describing just sounds like having support for multiple wallets. Nobody disagrees with that, but without people actively developing the Bitcoin Core wallet implementation, that will take a while.

Are you looking to be able to do this with the bitcoin daemon? You might check out the getaccount RPC call. The help for this method is:
getaccount "bitcoinaddress"
Returns the account associated with the given address.
Arguments:
1. "bitcoinaddress" (string, required) The bitcoin address for account lookup.
Result: "accountname" (string) the account address

Examples:
> bitcoin-cli getaccount "1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getaccount", "params": ["1D1ZrZNe3JUo7ZycKEYQQiQAWd9y54F4XZ"] }' -H 'content-type: text/plain;' http://localhost:8332/

I know this is for a given address and you are looking for a particular vout, but the two probably correspond in your case I'm guessing?

No, I want to do this from within the Bitcoin core itself. Let's say I have an account called 'reserved'. Whenever I send coins, I don't want coins from the 'reserved' account to be used. I might have 1 or 100 addresses in 'reserved', but I never want any unspent received coins in that account to be used when I send coins.


text:
Where and how can I buy shares in bitcoin?
Where can I buy shares of bitcoin? I have exhausted all due diligence as to where I can invest in Bitcoin.

It sounds like your due diligence has not lead to an understanding of what Bitcoin actually is.

I am not sure what you are asking. If you mean to ask where you can buy bitcoins you might want to take a look at How do you obtain bitcoins?. If you actually want to buy shares in Bitcoin, you might want to google "Winklevoss Bitcoin ETF", I think it is supposed to do something along that lines. If my trouble understanding your question's intent still seems odd to you, you might want to read What is Bitcoin?. If it is just me being dense, carry on.

And actually the "due diligence" also did not make him go to google, or use WIkipedia, both would have let to at least a basic understanding. No wonder society goes down if that is the level of due diligence these days. Hint - tell me where I Can buy some "shares in US DOllars".

If you're looking to "invest" in Bitcoin, there are a few places you can do it.

Buy bitcoins themselves. Arguably the easiest option
Buy hashing power and/or hardware. This can make you money in the meantime and has a very small chance of selling for more than you bought it, depending on hardware
Invest in the companies building hashing power(ASICs)

MtGox is most likely your easiest route. Buy bitcoins. I don't recommend mining at this point unless you're feeling technically competent and risky. You can also try tranfering funds from Dwolla to CampBX.
https://www.mtgox.com/
https://campbx.com/

authors: Андрей Дубровский


text:
BIP 38 Implementions for Altcoins?
Trying to identify implementations for creating BIP 38 encrypted private keys for alternative coins to spark collaborative open source discussions to standardize BIP 38 to support altcoins. Please share any BIP 38 implementation URLs you are aware of that support one or more altcoins for investigative purposes.

Ran across LTC generator, but prefix is locked 6P.

The most capable working implementation for extending BIP 38 to altcoins (having strong Bitcoin heritage) is provided by bitcoin-explorer's (bx) Key Encryption Commands (with working examples applied to Dash) that supports both BIP 38 modes:
1. AES256Encrypt, AES256Decrypt - a paper wallet use case
2. EC Multiply - a Casascius use case
A backwardly compatible Proposal and a Table are provided to have deterministic leading base58check encoded characters, apart from the "6P" allocated to Bitcoin, to distinguish BIP 38 encrypted keys from those belonging to different altcoin blockchains. See the BIP 44 Altcoin Version Mapping Table to apply proposed BIP 38 extension to support cryptocurrencies other than Bitcoin (BTC). Also worth examining the BIP 38 Security Considerations wiki page.


text:
Getting bx to create a private key from known chain code and a private EC WIF key?
I was trying to get strong feedback that I really understood a portion of the Mastering Bitcoin Book concerning HD wallets. The picture below is the reference for the question.

I checked out the functionality exposed by a Javascript Brain Wallet. By entering "123" (is a very poor secret) into a field for a HD brainwallet and the following extended private key emerged: xprv9s21ZrQH143K2hYgcmBxsUfRw3Kbu3eEGXFJrM8Cqtewuqa6Y6nXbB7tv9HnrBajqjptPsRjL9FmnwLa317jHWJ5dpwTc99C2AiPztPRaxk.
Clicking the button to the right of the private key got me to another page indicating the master private chain code is 40675733fc35303c1c75bc598716f24af225528da686192ceb567c88313f8885 and the master private key is L4h3ZSQ3yfFNbovQjTGumvUGEfB1a7oFAhbkhMMFGsdDKoTSwwU8.
Given these last two pieces of information and an index of 0, is it possible to issue a number a number of bx commands and concatenate their output results to feed a HMAC-SHA512 hash to arrive at private WIF key of KwMsDozFYQG7SZFwfvFRwWDhfuMJjkE669WxP6SqrpDPsCBrPV4p public address 15jbcT7wE81s8n2dbEGRFGf65zp7PHrjxh?  If so, how is this accomplished or does bx need to be complemented by some other command that renders HMAC-SHA512 functionality?

% echo "L4h3ZSQ3yfFNbovQjTGumvUGEfB1a7oFAhbkhMMFGsdDKoTSwwU8" | bx wif-to-ec
deec675df1bc1d395c6098ee63eacb45036fad781717548f4b8cc00709f5d834

% echo "L4h3ZSQ3yfFNbovQjTGumvUGEfB1a7oFAhbkhMMFGsdDKoTSwwU8" | bx wif-to-ec | bx ec-to-public
02430aca0779d7ca52441ee9de2f7b73408ee8229d6c2e42a5c81b65028efc803f

No need for an external program at all:
$ KEY=xprv9s21ZrQH143K2hYgcmBxsUfRw3Kbu3eEGXFJrM8Cqtewuqa6Y6nXbB7tv9HnrBajqjptPsRjL9FmnwLa317jHWJ5dpwTc99C2AiPztPRaxk
$ echo $KEY | bx hd-public -i 0 | bx hd-to-address
15jbcT7wE81s8n2dbEGRFGf65zp7PHrjxh

Or, because this is non-hardened, you can use the extended public key:
$ KEY=xpub661MyMwAqRbcFBd9iniyEccAV5A6JWN5dkAuejXpQEBvnduF5e6n8ySNmP8uWeqNbwFXLHEQkV1shXbNtBV8YCUJPMSuE7bGCvDaZJfUBuP
$ echo $KEY | bx hd-public -i 0 | bx hd-to-address
15jbcT7wE81s8n2dbEGRFGf65zp7PHrjxh

Most excellent...


text:
How long does it take for a SPV to intermittently sync (order of magnitude)?
Say I have a device that is mostly offline, with a SPV on it.
Say once in a while (for instance once a week) I go online for about 20 minutes, and make a large number of transactions (which are based on transactions I might have received while I was offline).
How long, would you say, does a SPV (e.g., BitcoinJ, bitc or  others) need, upon getting online, to be fully operational in these circumstances?
I confess: I am not yet familiar with SPVs (although I did read about them, I have not had time to fully understand them yet). The steps a SPV follows to sync are outlined here, but no timeline is given.
Thanks

SPV syncing depends entirely on the SPV servers that you're connected to. They may not have that much bandwidth and you might have a very slow sync, for example.
That said, you only need 80 byte headers per block you haven't seen (about 1000 blocks per week, or 80Kb for every week that your device is offline) and about 500-1000 bytes per UTXO you have (obviously this is highly dependent on how much new UTXOs you've received).
So assuming about 5 tx's per week and 1000 blocks per week, it's less than 100kb download to catch up once a week, which by any measure should be very quick. On most connections it shouldn't take more than 10 seconds.


text:
BIP 65 - how standard is it?
I read in this great thread that which BIP are standards is not always obvious.
What about BIP 65? To which extent is it standard?
Currently, all I know is that "Miners following the developers of the "Core" Bitcoin client have been adopting BIP-65, with approximately 25% of the last found blocks claiming to be ready for the soft fork on the version string in the block header. " ... not very precise.
Thanks

I updated the thread you linked to, since it only contained information up to 0.10.

The softfork defined by BIP 65 activated in december 2015. This means that the whole network enforces the new rules proposed by BIP 65, and it is safe to use CLTV opcodes in scripts since then.

hey @Pieter, BIP65 also includes a section called "Replace nLockTime entirely", has this been enforced as well? is nLockTime now deprecated?

That section is under motivation, and explains one of the things that become possible to do (with more changes) due to the BIP65 rules. It does not describe BIP65 itself.


text:
micropayment channels, n-m addresses, interoperability
I just read bitcoinJ's working with contracts tutorial and I am puzzled as:

it seems to me that n-m addresses are implemented in Bitcoinj using plain multisig (as defined in this bit of the developer's guide, and discussed here)
I looked for implementations of addresses controlled by more than one private key with pybitcointools (tutorial on that here) and on libbitcoin's wiki. It seems to me that these two libraries use P2SH.

Most libraries seem to use P2SH, but bitcoinJ chose the other way it seems (or is it?)...
In an implementation of micropayment channel with bitcoinJ on one side and, say, libbitcoin on the other ; will the two sides be able to interoperate?
(edit: I m talking here only about unidirectional payment channels)
Thanks

Not necessarily interoperable.
Firstly, libraries have to agree on what kind of parameters to exchange and how they are exchanged. There's no guarantee that the parameters required by bitcoinj and libbitcoin are the same.
Secondly, it is now considered standard practice to create P2SH transactions regardless of what kind of transaction you're setting up, unless it is P2PKH. In the case of P2SH transactions, you then have to assert that the payment channel protocol would also be able to parse/recognise/understand the redeem script provided by service provider of the payment channel (assuming that you're talking about a single-direction payment channel).

Thx for this answer. With regard to your bit on the parameters required by each library...: is it correct to say that there is a standard in terms of the transaction protocol itself (viz. what on bitcoin.org) but not for its implementation into APIs by libraries? Isn't it a significant issue for a p2p network like Bitcoin where nodes cannot be expected to use the same clients?

To my knowledge, I am not aware of a standard for payment channels. I do recall however seeing an attempt in the bitcoin-dev email to formalise a standard for payment channels, but I've yet see it written in the form of a BIP yet. On top of that, Payment Channels is more of an application layer protocol on top of Bitcoin, therefore it is not consensus critical.


text:
What hardware requirements does a SPV client have?
I read about SPVs here that:

[A SPV] client downloads a complete copy of the headers for all blocks in
the entire block chain. This means that the download and storage
requirements scale linearly with the amount of time since Bitcoin was
invented.

but being new to Bitcoin, I don't know how to quantify this in terms of :

bandwidth
storage
ram

requirements I need for running a SPV (on an embedded device).
Can someone please help?

Bandwidth - You need to receive an 80-byte header about every 10 minutes. In addition, if you want to spend, you will get SPV proofs that range about 500-1000 bytes per utxo. In other words, the bandwidth requirements are really tiny.
Storage - Each block header is 80 bytes, as of this writing, there are less than 430,000 blocks, so 80 * 430,000 = 35.4 MB. 100 MB should last you another 15 years.
RAM - The main usage of RAM is to do SHA256 and ECC signing/verification operations. A minimal CPU with not much RAM (512 MB) can do both without a problem.

Thanks. In terms of RAM/processing power, would you say a router with 32 MB flash and 300 MHz would do?

If you don't mind it being a little slow, that should be fine.


text:
What's the difference between MtGox streaming API hosts?
I'm trying to find out what the difference is between websocket.mtgox.com and socketio.mtgox.com for the MtGox streaming API. Looking at the Connecting section it looks like there are several combinations to be used:
websocket.mtgox.com/mtgox
socketio.mtgox.com/mtgox

both with http or https.
As far as I can see, there is no mention that they are different, however, I know from trying out things myself that they do behave differently. I've also seen in forums that other people have similar questions/problems as I have related to this.
Does anyone know what the differences are? Also are these differences expected and documented somewhere?
Further, the code snippet uses https as the protocol. Excuse my ignorance, but shouldn't we use ws or wss instead of http and https? Can someone explain that difference?
Thanks in advance for any information related to my questions!
UPDATE:
Actually, it looks like the URI scheme for websockets should be ws: or wss: and not like in the example http: or https:. Maybe this is a typo in the example or what's the deal for MtGox?
UPDATE:
So testing things in the browser, {ws,wss,http,https}://socketio.mtgox.com/mtgox all work and I don't see any difference. On the other hand, {ws,wss,http,https}://websocket.mtgox.com/mtgox all result in HTTP 400 Bad Request. Looking in the browser console I got the following error:
XMLHttpRequest cannot load http://websocket.mtgox.com/socket.io/1/?t=1367857246057. Origin null is not allowed by Access-Control-Allow-Origin.

Any ideas what might be going on?

Let me know if this question should have been posted somewhere else like on stackoverflow.com. Thanks!

OK, so after playing around with this for a while in the browser I have found out a few things that probably were somewhat obvious. :)
So even if there is no mention that websocket.mtgox.com is different from socketio.mtgox.com it really is, and the difference is that the former is a real WebSocket endpoint while the latter is a Socket.IO endpoint. Of course not very surprising looking at the names ;) Now for a beginner like me that wasn't completely obvious as I assumed Socket.IO could speak WebSocket and thus the endpoints were the same. Hence, this question. This was no the case here.
The Socket.IO endpoint accepts all URI schemes {http, https, ws, wss} while the real WebSocket endpoint only accepts the expected {ws, wss}.
At the moment I have all combinations working.
http://socketio.mtgox.com/mtgox
https://socketio.mtgox.com/mtgox
ws://socketio.mtgox.com/mtgox
wss://socketio.mtgox.com/mtgox

ws://websocket.mtgox.com/mtgox
wss://websocket.mtgox.com/mtgox

It's unclear it the http and https URI schemes are at all meaningful or if they just happen to work. Probably just that.
In short, there are two hosts: one for Socket.IO and one for WebSocket and both work with or without TLS.

Origin null is now allowed.

Your Origin header is not being set.
Try running your code in the browser from an actual domain name other than something like about:blank.
In chrome running:
var ws = new WebSocket('ws://websocket.mtgox.com/mtgox');
ws.onmessage = function(e){ console.log(e); };

results in failure from about:blank. However from an actual domain name results in success.

Thanks! Yes, that is the case. However, this header is not necessary unless you're a browser according to the standard. MtGox however, enforces this for all.

This solved my problem! Thank you so much. I have been stuck for hours!


text:
how can I hardcode a private key in bitcoinJ - ECKey constructor?
Can someone please explain how to use the following constructor (listed here):
ECKey(BigInteger priv, org.spongycastle.math.ec.ECPoint pub)

Say my private key is: priv = "L4...5".

How do I get the big integer representation of it (in other words, and if I understood correctly, is there a function to go from check58 to biginteger?) , and

what about the second parameter?

Thanks

If all you are after is getting an ECKey object for that private key, then Bitcoinj has a DumpedPrivateKey class for just such an occasion.
import org.bitcoinj.core.ECKey;
import org.bitcoinj.core.DumpedPrivateKey;
import org.bitcoinj.params.MainNetParams;

public class Example {

    public static void main(String[] args) {
        String priv = "L4...5";
        ECKey key = DumpedPrivateKey.fromBase58(MainNetParams.get(), priv).getKey();
    }

}

If you would like to use an ECKey constructor explicitly, then you should be able to get the code you need from here:

https://github.com/bitcoinj/bitcoinj/blob/release-0.14/core/src/main/java/org/bitcoinj/core/DumpedPrivateKey.java#L70-L91

With respect to the constructor you listed, it is a protected constructor, so it's probably not one you would be looking to use. It lists a private key and public key parameters. The private key may be null if the ECKey instance is only going to be used for verifying signatures, not actually producing them. The public key must not be null, and it saves time by not needing to re-compute the public key, which is a CPU intensive operation.
Note that most of the public ECKey constructors are deprecated. The preferred way of creating the ECKey objects now is to use the static factory methods.

Thank you very very very very much... worked fine for me...

You can call the public static method of ECKeyclass,  fromPrivate(byte[] privKeyBytes, boolean compressed). The public key is calculated from it (this is slow), either compressed or not. Eg.,
        String privateKey = "Your Private Key";
        byte[] b = privateKey.getBytes();
        ECKey key = ECKey.fromPrivate(b, true);

or
BigInteger privKey = Base58.decodeToBigInteger(privateKey );
key = ECKey.fromPrivate(privKey);

https://bitcoinj.github.io/javadoc/0.13/org/bitcoinj/core/ECKey.html


text:
What is my incentive for sending old blocks?
If I am a miner, it makes sense for me to broadcast recent blocks since I want my chain to be the longest (see What encourages Bitcoin miners to relay blocks?).
However, what is my incentive for broadcasting old blocks? Deep blocks are very unlikely to be orphaned, so it seems that I get no gain from relaying them, despite it costing me bandwidth.

Why does there need to be an incentive? I mean, strictly speaking, there's no incentive for the people who operate archive.org to keep that old data around.

There is no incentive to serve historical blocks beyond altruism, generally that applies to all facets of participating in the p2p network. Nodes without incoming connections will generally not be requested to send any old blocks, and this is a standard operating mode for people who have disabled listening or are behind restrictive NAT with no ability to hole punch through port 8333.

Miners have spent money on mining hardware. The value they are able to get out of that mining hardware is tied directly to the price of Bitcoins and the mining difficulty.
If the price goes up, that will incentivize some additional miners and if the price goes down, more people will mine. But this doesn't happen immediately nor does it cancel out perfectly. Miners benefit from an increase in the price of Bitcoins and are harmed by a drop in the price of Bitcoins.
Your incentive for sending old blocks is that the utility of bitcoins drops if it's more difficult for new nodes to join the network. While this effect on the price of bitcoins is slight, the amount of old blocks you need to send is also slight.

And this is true not only for miners: anyone invested in Bitcoin (for example by owning a few bitcoin) stands to gain from an increase in price.

If one really can't upload old blocks, they can consider running a full node in pruning mode, which actually deletes old blocks from your harddisk as well. It's a bit crude in the current version, but upcoming versions will be quite flexible.

Yes miners have a stake in the health of bitcoin in general, but surely this is a free-rider problem? I don't have to relay any blocks so long as someone else does.

@sdgfsdh The cost of relaying is so low and the benefits so great that there is no free rider problem.


text:
How can a block be considered more difficult to solve/hash than another one?
In this answer: https://bitcoin.stackexchange.com/a/760/28219
It is said:

Because of all this work, when a Bitcoin client signs on to the
  network it can trust the block chain that was most difficult to
  produce (since this is evidently the one that was being worked on by
  the most miners).

There is nothing evident there :)
Can someone explain how can a block be more difficult to solve than another one? Does it have to do with the number of transactions it contains?

All blocks have a field for their 'difficulty'. This is a parameter that determines how many hashes have to be calculated (on average) before you find a block. Higher difficulty means the block will be harder to solve.

How can a block be considered more difficult to solve/hash than another one?

Think of it like flipping coins, where the difficulty number is the number of Heads you have to flip in a row. So, With difficulty 8, you have to get 8 heads in a row, etc. Difficulty 9 is harder than a difficulty 8.
This difficulty number is used to increase/decrease the number of blocks solved on the network, according to very specific rules, in order to keep blocks solved at an average of 10 minutes. If the network is solving too many blocks, say a block every 9 minutes on average, then the network will increase the difficulty. Similarly, if the network is only solving blocks every 11 minutes at the current difficulty, then the difficulty is lowered. This re-adjustment process happens every two weeks in Bitcoin.
The tricky part is what can happen if a fork takes place at the same time as the difficulty adjustment. Let's say our blockchain looks like this:
                X_8
              /
-> X_8 -> X_8
              \
                X_8

(Where 8 is the difficulty of each block). Since the top fork and the bottom fork have different time fields in their block header, they result in a different difficulty re-adjustment calculation (difficulty re-adjustment is based on number of blocks in a given time, trying to keep it at a block per 10 minutes). Now the next blocks on either side of the chain, which have the newly calculated difficulties, at not given the same weight.
                X_8 -> X_9
              /
-> X_8 -> X_8
              \
                X_8 -> X_7

Since the difficulty re-adjustment in the top fork ended up with a higher difficulty, any block solved on that half of the chain (X_9) will override a block solved on the bottom side of the fork (X_7). However, if X_7 had been solved significantly before the X_9 block, then that would be the chain with the most work (8 + 7 on the bottom chain is better than just 8 on the top chain).
The network essentially looks for the chain of blocks with the highest sum of difficulties, i.e. the chain that took the most work to produce, and would be the hardest for an attacker to try to override. Nodes on the network choose this highest-difficulty-sum chain as their correct chain, and the great thing about this is that when everyone follows the simple rules, they arrive at consensus about the history of transactions.

Does it have to do with the number of transactions it contains?

No.

Block difficulty is determined only by the sum speed of miners working on that chain particular chain, kept track of by evaluating the the spacing of the timestamps of blocks in a 2 week period. It's worthwhile to think about the block chain as a tree that just happens to have a very strong main branch, where branches are weighed by how much work went into creating them rather than their length.

           +---> 9 +---> 9
9 +----> 9 |
           +---> 1 +---> 1 +---> 1 +---> 1 +---> 1

Here we have two competing tips of the chain, one with a cumulative difficulty of 36 (9+9+9+9, and one with a cumulative difficulty of 25 (9+9+1+1+1+1+1). Although the top section of the fork has less blocks, it has a higher difficulty than the bottom fork and so is regarded as the current "best" side of the chain.

"by the sum speed of miners working on that chain particular chain" => do you mind explaining that better, for the mere mortal?

The time between blocks is made to target 10 minute intervals on average. If the miners go too fast, the difficulty of making blocks is raised in the next period. If they go too slow, the difficulty is lowered.


text:
What is the BIP-44 Coin Type for Dash?
BIP-44 compliant HD wallet trees use the m/purpose'/coin_type'/ account'/change/address_index convention to derive private keys and associated addresses. For coin_type, BIP-44 makes a reference to registered coin types.  Will the Darkcoin index of 5 work for Dash?
Compressed DASH private WIF key (Darkcoin v0.6+ stores public keys in compressed format.):
% echo 'very complex gibberish' | bx base16-encode | bx sha256 | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 5 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | sed 's/$/01/' | bx base58check-encode -v 204
XH2Yndjv6Ks3XEHGaSMDhUMTAMZTTWv5nEN958Y7VMyQXBCJVQmM
Compressed public address:
% echo 'very complex gibberish' | bx base16-encode | bx sha256 | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 5 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx ec-to-public    | bx ec-to-address -v 76
Xb9HJy46M9u3SLAWVitS4eV6gEMuVFfZX2
Uncompressed DASH private WIF key:
% echo 'very complex gibberish' | bx base16-encode | bx sha256 | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 5 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx base58check-encode -v 204
7rrHic4Nzr8iMSfaSFMSXvKgTb7Sw3FHwevGsnD2vYwU5btpXRT
Uncompressed public address:
% echo 'very complex gibberish' | bx base16-encode | bx sha256 | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 5 | bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | bx ec-to-public -u | bx ec-to-address -v 76
XiEsuvDERQJT5S9RF7qcKGrm4omMsJ1PPg

Yes, Dash should continue using the same HD index as Darkcoin. Only the coin name is changed.
So 5h is the correct HD index for Dash.


text:
What user data has been leaked from MtGox's database during June 2011 hack?
What user data has been leaked from MtGox's database during the June 2011 hack? Is the database still available for download anywhere, like it was almost a year ago?

It was details of 61016 user accounts as a CSV file with fields UserID,Username,Email,Password.  The passwords are hashed, and most of them salted too, but some (the oldest) are simple md5 hashes.
I just tried searching google for it and was unsuccessful.
I have a copy, and could make it available for download but don't know if that would be legal.  I'm guessing not.


text:
How to clear invalid transactions from one's wallet?
I've recently been testing double-spend attacks against myself using a couple wallets, and the standard client does not appear to clear conflicting transactions from its transaction list, even if the other ones have already become a part of a block. How do I get rid of invalid transactions from my wallet?

possible duplicate of What is the best way to recover from an accidental double-spend?

For future reference, use a throwaway wallet for this type of activity.

@StephenGornick I did, but I'd like to recover any remaining balance from those addresses and the standard client tends to calculate its balance based on all transaction it sees, even the invalid ones, so I'm not sure how many Bitcoins I have left.

This question was answered before for someone to clear a too low fee transaction that wasn't accepted by the network. https://bitcoin.stackexchange.com/a/2415/1461


text:
What files one should backup when running a pool or other Bitcoin service?
There was a big problem with Bitomat at some point where that Bitcoin exchange lost its data due to some data being lost. To prevent such problems from occurring, what files should one backup? Which files need to be backed up only once, and which should be backed up regularly? For example, should a mining pool backup its wallet.dat often, or is once enough, as the data contained in it will never change?

You should back up all of your files.

You need to back up your wallet.dat regularly. If your pool uses "getwork" for generating work and later generating blocks, then each block is generated with a new crypto key. Also, when you send coins out to pay your miners, the "change" is always sent to a new address. So your bitcoind is always generating new crypto keys, and you must back them up so you don't lose any coins.
So any bitcoin service that sends coins or generates new blocks with "getwork" must back up wallet.dat regularly. A bitcoind that only receives coins can be backed up only once. A bitcoind that doesn't handle coins obviously needs no backup (rare case, but can be useful).
Apart from that, of course back up your database and anything else you don't want to lose.
Update: I just want to add that bitcoind has a pool of unused keys. It makes new keys when the pool runs out. Most of the time it just takes fresh keys from the pool - and you backed those up. So you don't have to run backups once per minute to be safe. If you want to do this the best way possible you could give bitcoind the "keypoolrefill" command (and wait for that to finish) before backing up wallet.dat. This way you always back up a full pool of unused keys, and the backup will "last" as long as possible. That is to say, it will take as long as possible before the pool runs out and bitcoind generates new keys for the pool that you don't have in the backup.
There is some info on the key pool here: https://en.bitcoin.it/wiki/Key_pool.
Update 2: I'm actually unsure if "keypoolrefill" only has an effect if you resize the keypool. If you don't change the size of the pool, I think bitcoind generates a new key for the pool each time it takes a key out of it. Someone correct that if it's wrong.


text:
Why isn't importing wallet.dat as straightforward as it seems it should be?
In most of computerdom, an app's File dropdown menu has an Import item that permits selection of a file to import into the application.  This would seem to be an obvious feature to include in a Bitcoin GUI, yet when searching for how one imports the wallet.dat file, no such straightforward import option appears.
What is the technical reason for this?

It is not so easy to "open" a wallet, because it requires rescanning the blockchain to find the outputs that are relevant. This can take a very lock time, especially if you do not have an SSD. Because the performance is so poor, it would be disappointing for a lot of users to use this hypothetical feature.

I see.  So is there client software geared toward those running a full node with SSD, many GB RAM and many cores?  I understand this is a different kind of question from the original.

@user5652 you could run an electrum-server like electrs or electrumX and then use any electrum-protocol wallet, and configure it to use your local server. the server will need a few hundred gigabytes to index everything.


text:
Who is in the Bitcoin Business Alliance?
I have stumbled upon the Bitcoin Business Alliance, and heard it includes some of the most influential people in the Bitcoin space.
What businesses or individuals are known to be a part of the BBA?

side-note: if they don't list their members, they must be irrelevant.

@Lohoris - not necessarily, they might just want to keep their privacy.

yeah, but... no. If you own a business, do you think you would really care being part of a secret cabal of businessmen no one knows about? It's all about bragging, leave it out and you've got nothing.

@Lohoris - I actually think you're mistaken. I am in the process of getting an invite, so while I won't be able to divulge members' identities of course, I believe that I will be able to confirm or deny their general caliber.

@Lohoris: It's more about a mutually beneficial strategic alliance.

@DavidSchwartz ok it's not only about bragging, I agree now. Still, as long as member list isn't public I fear it won't collect the interest of the potential new members, and stay too far on the shady line...

Well, I won't speak about other people, just that I am now a part of BBA myself.

Remember Grouch Marx: "I don't care to belong to any club that will have me as a member."


text:
In order to "pay someone back", must I ask them for a return address?
I want to write code that accepts a transaction, and afterwards "pays back" some amount to the origin of the transaction.
Assume users will be using the standard client. Will transactions have a single input, or must I handle the situation where a transaction have multiple inputs?
Can I just choose one of these inputs and pay back to that input? I want to avoid having to request users from entering a payout Bitcoin address - it's so much neater to just pay back to the same address they used.

Assuming that the user uses the standard client, or in fact any client, is a very strong assumption. If the user is using an eWallet service such as Instawallet, in all likelihood the user will not get the funds back, they will be held by the operator and possibly credited to one of his other clients.
Even if the input addresses are controlled in some way by the user, paying back to one of them can cause confusion regarding the payment's source - it will look as if the payment was for whatever the address was originally associated with. If there is a change address controlled by the user, it is associated uniquely with the payment to you so the information exists to identify it, though the client may not display it properly.

Hmm. So I have to ask the user to provide a return address? This sucks :(

Well, that depends. You could make an optional return address field, and clarify that if the user is not using the default client (or knows exactly what he's doing) he should fill this. It would be a good idea for eWallet providers to associate change addresses with the originating client, and in an ideal future where it is reasonable to expect eWallets to do this, it's safe to send to the change address. Also eWallets could offer the option to send a payment by routing it through an address associated with the client first.

As any user can easily receive Bitcoins with multiple addresses, the transactions they send can have multiple inputs. There are a couple cases you should consider:

Single input, single output - easy case, send coins back to the input (unless some prankster mines coins onto your address, then you might as well keep them instead of sending them to some invalid address)
Any number of inputs, two outputs - the second output is probably where the user has sent its remaining coins, you might as well send them there (although you should explain it to the users first)
Multiple inputs, single output - you probably should provide the users with two functionalities - either sending coins to the first input, or sending the same amount of coins got from each input into each of them
Multiple inputs, multiple outputs - probably should work as the previous case

All in all, you should provide users with different functionalities, probably each using a different address for their transactions and see which are used more often.

Most users won't know anything about the kind of transaction they're generating. I don't want to complicate their lives. Will the outputs always be either 1 or 2? When will I get a tx with more than 2 outputs, from a legitimate user?

@ripper234 You can make the more complicated options less accessible, for example by putting them in "advanced options". From what I understand, the outputs will usually be 1 or 2 for the standard client, but someone might be using a non-standard client that allows one to send coins to multiple addresses at once. For now, I think those only appear in exchanges and mining pools, which probably won't be used to send you coins.

OK, so I'll assume the tx has 1-2 outputs, and pick one of the inputs arbitrarily as my payback address.


text:
What is the highest recorded difficulty in the main net?
What is the highest recorded difficulty in the main net and which blocks was it used for?

It's worth noting that the answer to this will likely change over time. Maybe the question should be rephrased to be as at a particular date? Otherwise, we can just keep editing the answer (but SE's not really set up for that... it's not like we'll get a reminder to do it)

@HighlyIrregular The answer to this question does state a date it was checked. In the future it can be edited accordingly.

As at 9th May 2012, the highest recorded difficult has been:
1,888,786.705353 first reached August 01, 2011.
Blocks 139,104 through 141,119:

http://blockexplorer.com/b/139104
Bitcoin Difficulty History

As the comments mention this value is likely to change over time.
Since Stephen Gornick's answer in May 2012 the highest recorded difficulty is:
3,415,121.18552938
At the time of writing (24th November 2012) this is the current difficulty and the difficulty is expected to increase again in ~257 blocks.
The current difficulty can be checked at this link and the estimate of the next re-target here (this estimate is often wildly incorrect just after a difficulty re-target, i.e. when there are only the first few of the 2016 blocks of the current difficulty period that can be used to calculate the estimate).
Historical hash rates and difficulties can be seen in these graphs


text:
What .dat files are safe to be accessed while the Bitcoin client is running?
Sometimes one wants to backup some .dat files from Bitcoin, but one can't shut down the client to do so (for example, if one is running a pool). Which .dat files are safe to be copied when the client is running, and which are only updated when the client shuts down?

None of them are safe to access while bitcoind is running.  The only one that is critical to backup is wallet.dat, and the backupwallet rpc command will do that safely while bitcoind is running.