No.
See: https://en.bitcoin.it/wiki/Script
Opcodes 1-75 push data onto the stack.

It is high on my list because I think most miners (and pools) would be happy to include many more free transactions than the current rules allow, and if there is another price spike or somebody rich decides it would be fun to make the block chain a couple of gigabytes bigger it is much easier to react if the fees are not hard-coded.

The rough plan is:

 + Give miners more "knobs" to set fee policy-- let them specify (via command-line switch and maybe bitcoind RPC command) how much (if any) space to set aside in blocks for free transactions, how much to charge per-kilobyte and/or per-ECDSA-signature-validation, and what the priority/size/number-of-signatures thresholds are for considering a transaction for inclusion in the free space.

 + As Meni says, teach clients to look at the recent blockchain history and, for a given transaction, estimate how much of a fee will be required to get it into a block reasonably quickly. Maybe a "createtransaction" RPC call that locks coins for a certain amount of time and returns the how-long-to-confirm estimate along with "commit/aborttransaction" calls....

 + Figure out a reasonable UI for fees. Maybe:  calculate the probability sending the transaction with 0 fee will get into the next, oh, 3 blocks, and if it is greater than, oh, 90% then just send it without a fee.  Otherwise, let the user decide between paying a fee that will get it included (with 90% probability) in the next 3 blocks or letting them know how long it might take if they pay no fee.

Lots of details to be worked out...

The setup.exe is a "NSIS installer" -- I think this will work (but I haven't tried it):

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.