I did some benchmarking of client startup. About 75% of it is validating the block chain (CTxDB::LoadBlockIndex). About 15% of it is loading addresses (CAddrDB::LoadAddresses).

Looking at the block chain load/verify process, about 40% of the time is CBlock::BuildMerkleTree. About 10% is SHA256. The rest is ReadFromDisk, GetBlockHash, InsertBlockIndex, and so on.

Looking at the loading of addresses, it's distributed over many functions. The only standouts are CDB::ReadAtCursor and std::_Rb_tree::_M_insert_unique.

Just not checking that the transaction's hashes are correct and match the block header would halve the startup time.

It permits providers to change their green addresses should they need to. It provide a uniform way to know who offers green addresses and which addresses they are using.

Right now, if you started accepting Bitcoin transactions and wanted to accept green addresses, there is no good way for you to know everyone who claims to have a green address, what that address is, and whether it has a history of reliability.

As for why it's important to allow sites to rotate green addresses, the issue is this: Right now, if you supported green addresses, and you had a slight fear that there had been some compromise to that account, what would you do? Say you had just fired someone who had access to the key. You trust them, but would prefer not to have to.

There are many other scenarios.

Actually, that's vastly inferior, because nobody would know when to contact Mt. Gox. You wouldn't want to separately contact every green address provider on every transaction.

However, it does suggest a superior scheme. If sites could somehow broadcast their green addresses and a range of valid dates for each one in a signed form, that could fairly easily be polled. The rule could be you must announce a new green address at least a week before you use it. So people would only need to pull that list every three days or so.

This would allow green addresses to be rotated easily and wouldn't require a poll on every transaction.

You'd be using the key for the same amount of time to sign the same number of things. Whether or not you hold Bitcoins in that account has no effect on either of these two factors.

When you setup a green address, you are asking people to trust the security of that address. The fact that you have clearly stated that *you* do not trust its security makes the green address useless. If you don't trust it, why should anyone else? If you don't trust the key to secure your own funds, why should I trust the ownership of that very same key to protect against double-spending attacks?

I'm 99.9% sure you're protecting against an attack that does not, and cannot, exist. But if it does, your solution doesn't at all solve the problem. If it does exist, until you solve it, you cannot have a persistent green address.

Yep. It's a reported bug in the Bitcoin client. The workaround is to use a subdirectory.

Essentially, the client tries to create its data directory to make sure it exists. If it fails with any error other than "directory already exists", it barfs. Trying to create 'n:\' will fail, obviously, and not because the directory already exists, because there is no parent directory in which to create it. So the client sees the unusual error and assumes something is wrong with its data directory.

The correct approach is to attempt to create the directory, ignoring any errors generated. Then it should attempt to access the directory, and fail if it cannot.

It's sub-optimal because it at least doubles the number of transactions required. In many cases, it more than doubles them. (Because it removes the ability to consolidate multiple withdrawals into a single transaction.)

The problem it solves does not actually exist. It's entirely imagined.

It would if it had a large enough time horizon, but the Bitcoin market has a very short time horizon. People don't know if Bitcoins will be worth $1,000 each in three years or be worthless due to non-adoption and obsolescence. So while the next year or so of new coins is priced in, the time horizon keeps including more and more of the future mining. The fact that there will ultimately be 21 million Bitcoins has almost no effect on the market today because the probability that Bitcoin will remain relevant until they're all mined is unknown.

I agree. But you could if you wanted to. If you were helping the community, it's entirely possible the community would be willing to help you in return. But you can't make your customers cover your losses -- I hope you agree with that.

Except their circumstances don't require them to withdraw, *yours* do. My argument is since it's your circumstances that are compelling them to withdraw, you should cover the fee.

Right, but you are forcing them to terminate early. Otherwise, for example, they may have changed the Bitcoins to Ixcoins and avoided the withdrawal fee. It is your action that is making them incur the fee.

I agree. I'm not sure what I said that implied that you were charging a fee to recoup losses. (I think it may have been places where I was refuting arguments that you did not make, and likely would not agree with, for example when someone suggested that you opened the exchange to help the community and therefore it's okay to compel individuals to help you in return.)

Let me try another analogy. Say you and I had made a deal to exchange a $100 cashier's check for a bicycle. I get the cashier's check, costing myself $5. When I go to buy the bicycle, you say you changed your mind and are no longer willing to sell it. Should you reimburse me the $5?

I grant that the $5 is not a fee you are charging, it's a fee my bank charged for the cashier's check. But your promise induced me to incur that fee, and it is you who are defaulting on that promise.

Now, to be clear, I am not saying this is a big deal and you are a cheater or scammer if you don't make withdrawals free. It's a very small deal, and I realize that reasonable people can differ. But my opinion is that those fees are part of your losses, and you should not pass them on to your customers. You forced the customers to incur those charges by compelling them to withdraw when otherwise they may not have done so. It is equivalent to a fee for terminating an agreement early where you are compelling them to terminate early.

That's my opinion, you are free to disagree.

I'm perfectly willing to give him a break. The issue is him compelling other people who might not feel so generous to also give him a break. It's perfectly fine to open a business to help the community, but you can't then turn around and insist that individual members of that community turn around and help you out. He can certainly *ask* the community to help him cover his losses. However, it is wrong for him to compel them to or to impose his losses on others.

It does make sense to turn it off, since you are compelling people to withdraw. It's not really fair to tell people "you must withdraw all your coins" and at the same time charge them a fee for doing so. Consider a person who just deposited some funds, who now must withdraw them an incur a fee and who gets nothing for his funds.

This is the risk you assumed, and which you were paid for assuming, when you opened an exchange.

I guess a good analogy might be a whole life insurance policy. Such a policy might have a fee associated with cashing in the policy before a particular date. But if the company is going out of business and requires everyone to cash in their policy or lose it, they should clearly waive the fee.

This is the biggest problem. ECDSA is for signing and verifying, not encrypting and decrypting. Something like ECIES would have to be added or we'd have to use RSA instead.

Well then could you answer the implied question -- how?!

Even if that debt is in the form of inflation-protected securities like TIPS?
http://www.treasurydirect.gov/indiv/products/prod_tips_glance.htm

It doesn't matter whether anyone can prove anything or not. If I tend to lose a lot at a casino, I won't go back to that casino. I don't need to prove that the odds are worse there, I just need to feel that I'm not doing as well as I think I should and I'll try someplace else. If I do better elsewhere, I'll stay there.

Technically true. I agree that those things are literally incorrect, and when you're trying to make an argument on a contentious issue, it's good to be precisely correct. Merged mining does add some bytes to the bitcoin block chain. However, lots of other things add many more bytes to the bitcoin block chain and are of much less value.

In fact, if I were designing a Bitcoin replacement/update, one of my solutions to the reducing mining payout over time would be transaction fees for securing things in the block chain -- with an efficient "secure these hashes" transaction and a per-hash transaction fee. (This transaction would have no outputs and clients would know that they have no need to store it as a transaction. Block chain pruning could discard it entirely.)

In any event, if the transaction fees don't accurately reflect the costs associated with committing bitcoin transactions to the block chain, they should be raised. Unfortunately, there's a somewhat fundamental tragedy of the commons here. One person gets the transaction fee just for including the transaction in a block, but then everyone must store that transaction forever. This is a design flaw in the Bitcoin protocol that will likely get resolved in the future.

We add things like interrupt management and memory protection to CPUs because of the way people typically use CPUs. What's fundamental to a CPU is the ability to accelerate random accesses to memory, to make program flow decisions, and so on.

Typically the hash verification takes place on a CPU anyway. In any event, you could make hash verification take several hundred times more computing power and memory than it requires currently and it would, for practical purposes, make no difference. The only thing you'd need to change is, perhaps, DoS protection against nodes that stream blocks with invalid hashes at you.

An FPGA couldn't run a memory-hard algorithm at those kinds of speeds. If this is done right, you carefully design the algorithm so that a CPU is the ideal platform to implement it on. That is, you specifically design it around the things that CPUs do best. (If there was nothing CPUs do best, why would be using them?)

Your client only sent the transaction to one other client, to better hide the origin point of the transaction. That client refused to relay the transaction because you didn't include a fee. So that transaction never got anywhere. Had you left the client running, it would likely have eventually sent the transaction to a node willing to relay it.

Once a transaction gets out broadly, the network will not accept a conflicting transaction. You'd need a conspiring miner to get the conflicting transaction into a block.

There's a good chance you're right. While it's trivial in theory, it's quite difficult in practice. It's in many ways analogous to coming up with a secure encryption algorithm, but more difficult.