0.3.15 is pretty old, and the way you're spending from a copy of the wallet is, I suspect, confusing it.  Pieter updated the wallet code to handle transactions with partially spent outputs a while back.

Try upgrading to version 0.4.1 or 0.5 and running -rescan and see if your missing bitcoins reappear.

Ummm, yes.

It seems to me miners will have an incentive to lie about the transaction ledger, and put fake ledger hashes in their blocks. Either so their transactions might be considered 'unspent' by unsuspecting nodes that trust them, or so that other miners that don't have the full block chain create invalid blocks (eliminate the competition!)

And I don't see a proposal that everybody check the ledger and reject blocks that contain invalid ledger hashes.

I also don't see what the ledger hash accomplishes.  If you're going to trust some other node's version of unspent-transaction-reality, then you could just ask "send me the ledger state before (or after) the block with THIS block hash".

But if you're going to trust one or more nodes anyway... then it seems to me sending an ever-increasing-in-size ledger is a bad way to get scalable. If size-of-full-blockchain becomes a problem before the mining pools and big exchanges/merchants/transactions processors all have transaction processing clusters with a terabyte of ram and petabyte hard drive array then I think extending the protocol to make it easy to request all transactions involved in a given Merkle branch will probably be the way to go.

But before then I expect the bitcoin network will look very different from the way it looks today, and I expect there will be several different solutions for how to scale up. If (when!) Bitcoin gets that successful, there will be serious money hiring the same smart people who figured out how to scale up PayPal and Visa.

How did you build Berkeley DB?  Something like this in the MSYS shell:
  sh ./dist/configure -enable-cxx -enable-mingw

... should do the trick (see this thread, for example).

I'm no longer develop on Windows, but I had to be very careful to make sure bdb/boost/miniupnpc/openssl/Qt were all compiled with the same compiler and compatible options (e.g. -arch i386 versus -arch x86_64) to successfully compile bitcoind and Bitcoin-Qt on my Mac.

I give you a transaction that sends you 11 bitcoins... but I tell you "you better put that in the blockchain in the next 120 blocks, or I'll broadcast another transaction that sends the inputs somewhere else so the transaction to you will be seen as a double-spend."

I'd need a bitcoin client that let me do that, and you'd need one that could take a transaction in some format and then let you decide whether or not to broadcast it for inclusion in the block chain, or told you "sorry, too late, inputs already spent", but that all should work today.

As Mike said, help on "initial headers-only download" would be much appreciated.

Work-in-progress is here:  https://github.com/bitcoin/bitcoin/tree/blockheaders

... and my notes on issues that have to be worked out are here:  https://gist.github.com/1059233

As for scalability in general:  it looks to me like CPU time to validate transactions will be the bottleneck before bandwidth or disk space, so I don't see a strong reason to switching to a 'ledger' or 'balance sheet' method. Effective optimization/scalability is all about identifying and eliminating bottlenecks.

I can't see how OP_CODESEPARATOR can be used, either. I'm tempted to suggest that any transactions using it be 'discouraged' (have miners refuse to build on blocks that contain transactions using it).

Transaction hashes might be another, separate discussion topic-- I've been thinking that the way transaction hashes are calculated/used could be improved, although I don't think it is a critical design flaw but in the category of "stuff we can live with but that maybe could have been done better".

Try running with the -nolisten -noirc flags, see if that works around the problem (and please let me know if it does/doesn't).

I'm not sure any of the current core developers regularly use TOR; getting somebody who does to contribute patches and review code for regressions is a good idea.

Yes, who cares if you get extra testnet coins?

But... if somebody wanted to be annoying, they'd pre-generate as long a min-difficulty coinbase-only-transaction chain as the block timestamp rules allowed, and constantly broadcast those blocks.  Just to prevent transactions from getting confirmed.

To prevent that...

Testnet could prefer to build on blocks with more transactions from the memory pool over blocks with fewer transactions from the memory pool (that's not a bad rule for main net, either; might be worth considering if it works well for testnet). The rule now is "build on first valid block seen".

And "discourage" (refuse to directly build on or relay) blocks with timestamps in the future.

Good, accurate article.

I'm still not Satoshi, though.

Yes.

Any opinions on whether to do a hard reset (new genesis block with the new rules) or a split ("new rules apply to blocks with timestamps after XYZ") ?


RE: scaling down difficulty:  good idea if we were thinking of implementing something like this for the main network.  But I'd want to give everybody lots of time to think long and hard about potential hacks/exploits/unintended consequences if this was being considered for the main network-- sudden drops in hashing power is NOT a problem for the main network, so I don't think it is worth considering now.

Why?  What problem would that solve?

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).

I updated the .zip and .tar.gz and SHASUMS.asc a few hours ago, because the .zip and the .tar.gz were expanding to a "bitcoin-rc7" directory.


Be sure you run bitcoin-qt.exe, not the old bitcoin.exe.

Yes.

I'm testing patches against the last two versions of Bitcoin (0.3.23 and 0.4.1) for BIPs 11 and 12 right now to make it as easy as possible for miners to support them.  Review or help testing is very welcome:

  https://github.com/gavinandresen/bitcoin-git/tree/v0.3.23_op_eval
  https://github.com/gavinandresen/bitcoin-git/tree/v0.4.1_op_eval

Yes, I forgot to rename the folder.

Uploading a fixed 0.5.0 linux.tar.gz and win32.zip now (and SHASUMS.asc), will do the same for 0.4.1.

Mmm... perfect software...

You notice how we aren't at Bitcoin version 1.0 yet?  That the version is "0.5 BETA" ?

If you NEED it to be perfect then you're going to be waiting forever, because no software is ever perfect.

The criteria for a new 0.something release is "Is there general agreement that it is better than the last release."

There is general agreement that the new GUI is better; the huge problem with the old GUI is we have no wxWidgets GUI programmers willing to support the old GUI. There are several people contributing patches to the new Qt GUI.

I've said it before but I'll say it again:  Bitcoin is still a high-risk, high-potential-reward experiment, and you shouldn't invest time or money that you can't afford to lose. We're working hard to make it better, but we're not perfect.

The download directory contains them in a file called SHASUMS.asc:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/SHASUMS.asc/download

... which I'll reproduce here just because it is easy:

Yes, it aught to work (for bitcoind, at least-- I haven't tested with bitcoin-qt).  getinfo will tell you if it is working (look at "hashespersec").

You might want to run a testnet-in-a-box, it is 60 time easier to generate blocks on it:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

http://testnet.freebitcoins.appspot.com/  has 11,000 testnet coins available.

Bitcoin version 0.5.0 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release include German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
  https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date.  Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX  (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
 Bitcoin-Qt: Address Book, then New Address...
 bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet,  then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send  all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
 IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show block-chain download progress.

Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

---

Thanks to everybody who contributed code or helped test this release:

Alan Reiner
Alex B
Alex Waters
Ang Iong Chun
Celil
Chris Howie
Chris Moore
David Joel Schwartz
David Perry
Forrest Voight
Gavin Andresen
Janne Pulkkinen
Jeff Garzik
JoelKatz
Khalahan
Luke Dashjr
Matt Corallo
Misbakh-Soloviev Vadim A
Nils Schneider
Pieter Wuille
Victor Leschuk
Wladimir J. van der Laan
celil-kj
cjdelisle
flower
globalcitizen
gmaxwell
kwaaak
mark
p2k