sendfrom needs the minconf to know if it should fail because of too few confirmed coins in the account.

move used to need minconf for essentially the same reason, but as of (some release in the past) it always succeeds.
E.g. if account A has 5 0-confirmation bitcoins and 5 1-confirmation bitcoins then:
  move "A" "B" 10
... used to fail, because A's 1-confirmation balance was only 5.

Now it will succeed, giving it a -5 one-confirmation balance.  move "A" "B" 100 will also now always succeed, making A's balance go negative.

0.4.0 : Out real soon (0.4.0 release candidate 2 binaries are available on sourceforge now)

0.4.1 : I'd give about a 80% chance of happening (major bug or security problem found in 0.4.0)
0.4.2 : I'd give about a 20% chance of happening (major bug or security problem found in 0.4.1)

0.5.0 : Will be the Qt release.

Beyond that...  who knows?

RE: cannot act as a RPC client:

I believe it will still be able to act as a RPC server.

So you can run the GUI with the -server switch, but you'll have to talk to it using (for example)
  bitcoind getinfo

... as opposed to today, where you can run "bitcoin -server" to get the GUI and then run "bitcoin getinfo" to talk to the running GUI process.

RE: why switch:  because no wxwidgets programmers stepped up and made it better.  And from what I can see, QT is more popular and supported (so there are more programmers able and willing to help improve).

RE: screen shots:  See the bitcoin-qt thread in the Alternative Clients sub-forum here.

So the plan is for the next release of bitcoin to switch from the wxWidgets GUI we have now to the vastly nicer QT GUI that John Smith created.

I spent some time yesterday compiling Qt and bitcoin-qt, and some time this morning doing a very quick code review (executive summary: looks great!).

I'm mostly posting this as a brain dump of "stuff not to forget" when it is time to pull QT and remove WX.

Major behavioral differences I noticed during code review:

• Does not generate new receiving addresses automatically (good idea, I think, but may be controversial).
• Cannot act as a rpc client (ok with me, we'll still compile/ship a headless bitcoind)

Will-need-to-be-done stuff:

• Find and replace or remove references to wxwidgets in documentation, makefiles, etc.
• Change makefiles to track rpc.cpp --> bitcoinrpc.cpp name changes
• The QT library is LGPGL licensed; do we need to change READMEs or other files?

... and probably a bunch of other little things I didn't notice or I forgot to write down.

When did it happen:  I made time to fix it a few days ago.

Please don't spread misinformation.

I agreed to join TruCoin a couple of months ago, because I knew Eric (chaord) and Chris (cbrunner) through these forums and I think their vision and experience give TruCoin a really good chance of being an important company in the bitcoin economy.

And they hired me because TruCoin won't go anywhere if core bitcoin falls apart. I will (and have) mostly be working on core bitcoin issues, jumping in and writing code that I think is critically needed that nobody else is stepping up to write and working to make bitcoin as stable and secure as possible.

If Eric and Chris tell me to do something that is bad for bitcoin, I'll let them know what I think. If they suddenly lose their minds and stop listening, then I'll quit.

If I lose my mind and start doing things that are bad for bitcoin as a whole (or if I start trying to do things to bitcoin-core that benefit TruCoin over everybody else), then you-all should fire me.

Relevant discussion on the bitcoin-dev mailing list is here:
  http://sourceforge.net/mailarchive/message.php?msg_id=28082081

A Radeon 6990 has 4 gigabytes of ram.

If the task is "find a number that bcrypts/scrypts to less than a given hash target," I don't see anything that would stop a GPU programmer from implementing bcrypt/scrypt on the CPU and parallelizing at the try-different-nonces level.

Maybe I'm missing something; I'm probably biased because I worked at SGI from 1988 to 1996 and saw first-hand the evolution of GPUs from very-special-purpose chips with very limited memory to very-general-purpose vector-processing pipelines with very fast access to lots of memory.

I think it would be wise for any alternative block-chain to discourage creation of exchanges for at least a month or three to get the bugs out.

That should also help build trust that the alternative chain developers/promoters aren't just trying to make some quick BTC.

Non-standard transactions are allowed-by-default on the test network. So people can test things out.

They are "discouraged-by-default" on the main network (discouraged means not relayed to peers, and not included in blocks by the default mining code).

I think etotheipi is right: last I heard, Eligius was the only mining pool with different rules for non-standard transactions.

RE: where in the code:  script.cpp

... and all of the arithmetic binary ops do a CastToBigNum()

nMaxNumSize = 4 means numbers added must be 32-bits or less.

RE: simpler version being redeemed by anybody by rewriting:  D'oh!  Right, definitely need a signature so the transaction can't be modified between being broadcast and being included in a block.  I'll remove it from the wiki page.

RE: hidden recipient address:

I dug deeper into the Script OPs when working on the multisig proposal, and OP_ADD can't add bignums, so the 'hidden recipient' script won't work.

A simpler version would, though; I'll update the wiki.

The testnet has suffered rewrite-the-block-chain-with-more-hashing-power attacks.

It does bad things to your wallet, if your wallet contains transactions that depend on previously mined but now-no-longer-valid blocks. I suspect it will cause lots of heartburn for exchanges; this patch from sipa (which hasn't been extensively tested because long block-chain re-orgs on the main chain are not an issue) might help:
  https://github.com/bitcoin/bitcoin/pull/195

Alternatively, removing all the wtx wallet transactions stored in the wallet and then running with -rescan should get back to a sane state.  Although an exchange may very well find customers end up with negative balances after doing that, and customers will likely be upset that their balances are likely to change from what they think they have if they've deposited invalid-under-the-new-chain transactions.

Successfully bootstrapping an alternative chain starting from a low difficulty, given that there are people with lots of potential hashing power and the willingness to mess around with the chain "just because they can," seems like a hard problem to me, although if people were willing to accept some centralization until hashing power got to a "safe" level it could be solved by a central authority publishing block-chain checkpoints every X blocks.

Hi Jeremy!

The yoursway create-dmg script had the same problem.

I changed the approach to using a "template" .dmg file, as described here:
  http://digital-sushi.org/entry/how-to-create-a-disk-image-installer-for-apple-mac-os-x/

The .dmg includes Bitcoin.app, a compiled bitcoind daemon, and the source code .zipped up.

As an experiment, I've uploaded a Mac .dmg disk image with 0.4rc2 binaries to:
  https://github.com/downloads/bitcoin/bitcoin/

I'd like to switch from sourceforge to github for binary release downloads, because sourceforge doesn't support https for downloads.

Help improving the script I used to create the .dmg file would be most appreciated; see this branch for what I done did:
  https://github.com/gavinandresen/bitcoin-git/commits/osx_dmg
For some reason setting the "Drag and drop to install" background image isn't working...

shasum checksum is:
 6621bdb82fd4520f6efcb87f489e47a587d8915f  Bitcoin.dmg


Fixed.  New shasum checksum is:
 c86229b4c973da2207f516962804958424e94e08  Bitcoin.dmg

They won't lose any money to fees, because they won't broadcast their transactions-to-self, they'll just include them in blocks that they create.


So, evil miner does:

Gets some myselfcoins.
Creates transactions that pays themselves the myselfcoins, and pays BIG fees.
Does NOT broadcast those transactions.
... eventually mines a block that contains those transactions (they're a miner, they can put whatever transactions they like in their blocks).

Then does that again and again, re-using the same coins, getting richer and richer from the FEES+10%

I haven't seen anybody post about what would be my biggest worry if I were trying out alternative block chains. I realize this may be perceived as "Gavin is FUD'ding anything that isn't bitcoin!"  (FUD == Fear, Uncertainty and Doubt)  But I think some of you might be forgetting some basic computer security fundamentals in the excitement to be early adopters.

When I first heard about bitcoin, my questions were:

1) Can it possibly work (do the ideas for how it works make sense)?
2) Is it a scam?
3) If it is not a scam, could it open my computer up to viruses/trojans if I run it?

I answered those questions by:

1) Reading and understanding Satoshi's whitepaper.  Then thinking about it for a day or two and reading it again.
2) Finding out everything I could about the project.  I read every forum thread here (there were probably under a hundred threads back then) and read Satoshi's initial postings on the crypto mailing list.
3) Downloaded and skimmed the source code to see if it looked vulnerable to buffer overflow or other remotely exploitable attacks.

If I were going to experiment with an alternative block-chain, I'd go through the same process again. But I'm an old conservative fuddy-duddy.

If you want to take a risk on a brand-new alternative block-chain, I'd strongly suggest that you:

1) Run the software in a virtual machine or on a machine that doesn't contain anything valuable.
2) Don't invest more money or time than you can afford to lose.
3) Use a different passphrase at every exchange site.

0.3.24 Linux/Windows releases weren't built on EC2, but was built on 'gitian' virtual machines (lookup trusted build process here for more info, or get in touch with devrandom).

Very nice bitrick!

By the way, this patch speeds up initial download quite a lot:
  https://github.com/gavinandresen/bitcoin-git/commit/042a619709fab1329e8286c6aedbb2cdc8eb3497

...as do these, which have already been pulled into git head:
  https://github.com/bitcoin/bitcoin/commit/fb45259967032d409bca4d542b55414a7c522fba
  https://github.com/bitcoin/bitcoin/commit/ec74e8a44338202bfb82faa2cef4611cc37e7fa5