It will rescan for transactions.... but if the chain download lies to you and gives you an alternate chain you won't know.
It will become apparent though as soon as you get no new blocks.

If you aren't verifying anything or looking for transactions that are relevant to you then you might as well just download the block chain all at once:
http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/

That's a bit misleading.
Part of the 80 bytes is the merkle root of the transactions which is essentially the contents of the block.

Unless you are doing simple payment verification you can't verify a block until you have all previous blocks.

You can't know if anything in the block you are examining is a double spend unless you possess the data where those double spends would exist.
If you are downloading the headers with the intention of downloading all the full blocks then you might as well just download the full blocks since you are going to do the same work twice.

I specified in the the first sentence that you can't do it without involving another currency.
The government is the insurer of last resort when it comes to banks... for example the FDIC in the US.
I would never deposit money in a bank that guaranteed my funds on the condition I didn't mind being paid back in Rubles.
Since its impossible to have an insurer of last resort for bitcoin the bank would have to work in reverse.

I've only been able to come up with one way to earn "interest" (technically dividends) on bitcoins that do not involve another currency. It comes in the form of an insurance agency combined with a bank.

Essentially, a bitcoin bank makes the following guarantee:
We will store your bitcoins securely and we will only release them given condition x and will charge a small fee.
The condition could be a pgp signed directive to release a certain amount of funds to a given address.
The bank will then become liable for any funds lost for which it cannot produce the signed directive.

Unfortunately bitcoins are essentially uninsurable. To solve this the bank is also its own insurance agency.
The bank locks away very high security keys under physical... as well as legal... safeguards.
It can then execute contracts with large (or many small) bitcoin holders who approve of the banks security and methods.
By signing the contract you agree to insure in proportion any losses incurred by the bank. A loss in this example is not when the user loses control of their pgp key. That would be on the user. Only when the bank is compromised would this go into effect.

Assuming no breach occurs the insurance depositors earn "interest" from the fees in proportion to their deposits.
If a breach occurs the bank then needs to go through the legal hoops to access the escrowed money.

How big is the database + indexes at the moment?

Restricted to a local market I would think a system like ripple or Chaum's digicash would be preferable.

Some that stick out that should be relatively strong:
j3n0VA$@
Nephi7187$$$
K7mmI8lAsn1o0q
c0urche$ne
7XiBKeJe5ochSqVW
n0k!@N900
yT#g1Srm123

I'm also curious how these were broken assuming these are salted.

Agreed.

Judging by this post [ http://forum.bitcoin.org/index.php?topic=23340.0 ] it looks like blockexplorer won't be open source any time soon.
I'm starting to trust it less and less especially once it ends up on other servers where it can easily be modified but you have no option of just running your own.

ABE is starting to look very attractive.

Check out the rpcconnect option in the configuration file:
https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File

I would still strongly recommend not working directly against a live bitcoin instance unless you absolutely have no choice.

The biggest problem is figuring out what a valid trade is. Using pure block chain activity to determine what is going on will be extremely unreliable.
There is nothing stopping people from trading with themselves to make it appear like any price and volume they want.
If you could make intrade bets at any price and volume without risk by trading with yourself then it would not be a very reliable indicator.
It would be akin to placing a bet that there would be at least x transactions on the bitcoin network on a given day. Anyone can push that number as high as they want.
Also, since the binary event will be decided without real world measurements the person with the most money can force the outcome to whatever they want it to be.

Prediction markets work because at the end of the day an arbiter will make a final call on whether the event did or did not occur.
If there is no arbiter of the event then you are just in a competition to see who can most effectively game the system.

You are right. I meant more in the practical sense that he could collude once but then it would essentially kill his business since the falsely reported outcome would be openly visible in the block chain.

As far as locking the money up so it can't be spent I'm assuming the technique from the contracts wiki would work:

I'm not sure why it was allowed to happen but the Bitcoin forum has become a liability to the entire project.

As I type this the majority of posts in the the main forum... the only one that most people see... are mt gox rants.
How is someone discovering Bitcoin today supposed to wade through this mess to find information?

The threads are filled with gigantic signature pictures and ridiculous trolling. Several of the top level threads are just joke pictures.

Why is this being allowed to happen?
All serious discussion of bitcoin gets moved to subforums while the main is left to wallow in garbage.

Moderators, you know that this site is linked from the the main bitcoin page and this is the first place people turn to ask questions.
The state of the forum today makes the whole project look like a joke.
If this had been the state of the forums when I first got interested I would have dismissed the entire thing.

Re-reading some of this thread I realize my grammar goes way down hill when I type from my iphone.


There isn't a central authority just an entity that you and your counter party agree to trust for a single transaction.

Competing "authorities" is way better than trying to use a block chain for external data. Lets use the intrade example.
(I'm not an internet gambler so I may not describe how intrade works correctly)

Intrade has a prediction market with enough saturation in the market that it reaches a critical mass become a reliable indicator.
Alice wants to place a wager with Bob on an intrade event. Alice does not trust Bob and vice versa.
They want the bet to be settled in bitcoin and both will cheat the other player if given a chance since that's the way it seems to go on the internet.
Ben starts an anonymous intrade settlement service on TOR. There are many, this is Ben's.
Ben publishes a public key and claims to honestly sign and report the outcome of every intrade event. (This could be done by intrade directly but lets assume they aren't interested.)

To decide whether to trust Ben Bob and Alice each examine the Bitcoin block chain proper looking for all script contents containing Ben's public key. They each independently verify the results against their known list of intrade outcomes. Each is satisfied that Ben reports results honestly. They also decide on a time oracle using the same process.

Using a combination of the techniques on the contract wiki entry Bob and Alice exchange a transaction with the following properties:
If the event happens Alice wins, if not Bob wins. If the agreed upon time has passed each gets their money back. (This handles event cancellation but it could be done directly by Ben without the time oracle.)

Benefits of this scenario:
Neither Alice nor Bob can cheat each other.
Ben cannot collude with either because he doesn't know about the bet.
Bitcoin becomes the escrow agent.
Charlie and Dan don't trust Ben's intrade service. They are not forced to use it.

Variations of this scenario:
All miners are owned by governments that do not allow gambling. Because of this Ben charges a fee for each event pairing. The fee covers the generation of a unique public key for each matched bet. Ben does not publicly publish paring results until a few days after the event has occurred. In the interim he only provides event results to Alice or Bob. The bitcoin network still validates all betting transactions because they appear no different than regular transactions. By the time event results are published the transaction is too far down the chain to reverse.

This would be cool. I'm assuming given two known public keys for an individual the relationship cannot be reverse engineered?
If so that would not be a good thing.

I don't understand the argument that people don't want to pay 0.00035 for something.

Retailers go out of their way to make prices appear as low as they can by appealing to psychological tricks.
http://dealnews.com/features/Psychology-of-Shopping-Why-29.99-Looks-Better-Than-30/429590.html

Given the choice between paying $1 and 0.058 BTC the price with leading 0 is more attractive to a consumer,

Leaving things the way they are will help bitcoin spread not hinder it.

Here's on of the discussion on the subject:
http://forum.bitcoin.org/?topic=6900.0;all

With the oracle approach you don't really need to go through all the trouble. Start an oracle service that signs arbitrary with data with the current chain height.
If you and another party think its safe then just use that. That allows you to base transactions on chain height without risking everyone else.
The same can be done for a time based transaction. Using the oracle approach is much safer. If the oracle signs arbitrary data with the time then it doesn't matter whether the chain gets reorged or not. Your transaction will still be valid even if you don't/can't broadcast until after the time has passed.

In the block number example lets say you could push block number onto the stack and you had a transaction script that relied on it being before a certain block.
The transaction is floated and accepted in to a block as valid.
Then a chain reorg occurs. All the transactions that aren't double spends or coinbase transactions will be mined in to the new chain. However, it is possible the completely valid transaction relying on block number now becomes invalid because when the script is evaluated the new block number is too high.
Compound this by having transactions in the chain that have built upon the old and completely valid transaction but are now invalid.
You get the same problem with pushing on timestamps, etc.


Your oracle can be as complex as you want and there is nothing stopping them from charging for their services. The existing bitcoin miners are verifying the results as long as the parties involved accept the oracle's reality.
You could write a single oracle service that creates a contract based on a hundred different factors and the bitcoin miners could verify the result. All you would need is the oracle to rollup both sides of the action into a single derivative identifier. You get the transaction based on OracleSig(derivative, true) and I get the transaction OracleSig(derivative, false). The bitcoin script doesn't care whats behind the derivative id, just that its signed by the given private key. The blockchain doesn't even know there was an oracle involved, it just sees a script that evaluates to true.

Do you need to send and receive? If you don't need to send you don't need a bitcoin connection at all. Pre generate the keys and lock all but the public portion in a safe. Use blockexplorer to check balances.

If you need to send and receive use the same method as above for receiving. Accept/generate sends in your app server database.
Have your bitcoin installation somewhere else that periodically query your app server for withdrawal requests but have them unconnected at all other times.
Download the send list your bitcoin installation and have a script that translates the request to the local rpc server. Using this method bitcoin rpc never has to be opened up beyond the loopback address.

If you suspect something nefarious has happened on your site just don't run the send script until you investigate.
The bulk of your btc can be left offline and loaded on to your send machine as needed.