"you didn't offer a fee" is misleading; the bitcoin software 99+% of people are using today doesn't let "you" very much flexibility in how you offer fees.  So basically, 99+% of people using bitcoin are charged fees based on a set of built-in rules.

If you want to send a fee with every transaction, you can run bitcoin with the -paytxfee= option; there isn't much reason to do that now, unless you're generating lots of very small (few-bitpenny) transactions.  The Bitcoin Faucet is running with -paytxfee=0.01 because it DOES generate lots of very small transactions.

From the wiki:

tail -f ~/.bitcoin/debug.log
... will show you what bitcoind is doing.

Nothing against jav, but I think instawallet needs a month or three of 'soak time' to give the scammers and script kiddies time to try to break it (and to see how jav reacts to the scammers and script kiddies trying to break it...).

The built-in coin selection algorithm already prefers using older coins rather than newer ones.

Uhhh...  maybe a specific example will help.  Lets say you start with accounts/balances of:

A: 5
B: 5
"": 1
Total wallet balance: 11

Now you send 5 BTC from A, and pay a 0.01BTC fee.  Account balances will be:

A: -0.01 BTC
B: 5
"": 1
Total wallet balance: 5.99

The fee isn't 'taken' from either B or "".  You'll have to decide how to handle fees; for ClearCoin, I keep a positive balance in the "" account and automatically move coins from there if a transaction results in a fee (so for the above case, 0.01 bitcoins would be moved from the "" account to A, so A ended up with a zero balance and the fee is paid from "").

It is definitely an issue-- the account code doesn't keep track of where the coins it is sending out came from, so if you accept 0-confirmation coins you're vulnerable to double-spending attacks (see, for example, the discussion of the "Finney attack" in these forums).

Seeing coins show up right away is a fantastic feature, though, so I'd suggest getting the 0-confirmation balance and a 3+-confirmation balance, allowing only 3+ confirmed coins to be withdrawn, and displaying the difference as 'waiting confirmation'.

But they won't have the experience jumping through all the banking system regulatory hoops, or experience dealing with currencies other than bitcoin.

I expect lots of successful bitcoin vault services, and I expect one or more of them to be purchased by one or more banks and made a part of the banks' money services business.  If they see bitcoin vault services making big profits, they'll want to own one.

My predictions are frequently wrong, though.  Maybe US banks will fight bitcoin tooth-and-nail, or maybe the legal issues will be too unclear for any bank to risk getting involved.

Fantastic idea!

My only suggestion would be a "copy to clipboard" icon/link next to the funding address (I need to do that for ClearCoin, too-- haven't looked into how to do it yet, but github does it so I know it can be done...)

You're running into the "very low priority transactions require a fee" rule.  Priority depends on the value of the transaction (fewer bitcoins == lower priority) and how long ago you received the bitcoin(s) (older == higher priority).

That rule was in place for 0.3.20.2, but only for most miners.  Most would not include very-low-priority transaction in blocks until they were old enough to have a high priority.  The result was a big backlog of very-small transactions starting to build up.

With 0.3.21, the rules are the same for miners, for relaying transactions across the network, and for the user interface-- if your transaction is very-low-priority, it won't get relayed and the user interface will insist that you pay a fee if you really want it transmitted RIGHT NOW.

If you really really really need to send 0.01 bitcoins right now, then you'll have to pay the fee.  If you're willing to wait a while, you'll find you can send it without a fee after it is old enough and has enough priority.

All of this is to discourage people from "penny flooding" -- constantly sending pennies back and forth to themselves without a fee just because they can.

Footnote:  if you don't upgrade, you can send that 0.01 bitcoins without a fee.  But as everybody else upgrades, you'll find that it will take a long time for that transaction to get confirmed.

0.001 BTC at today's exchange rate is uncomfortably close to the estimated network-wide cost of processing a bitcoin transaction (which is about 0.001 US dollars).

The danger is a flood of micro-transactions that keep everybody's CPUs busy, driving up that hidden cost and, eventually driving people to stop running bitcoin because the costs aren't worth the benefits.


Also: lets not confuse the "how many free transactions" with "what is the smallest transaction amount you can send."

I think there's a good chance (mmm... 65.3%) that within 4 years one or more of the largest 1,000 US banks will support currency exchange to/from bitcoin for their customers.

Why would bitcoin be a threat to banks?  They're really good at securely handling currency; that's a valuable service, whether the currency is dollars or euros or bitcoins.

We got a request a couple days ago for somebody to do an interview with a Brazilian radio station about bitcoin.

Any volunteers?

Yep, I live in Amherst, Massachusetts; my family moved to the US when I was 5 years old.

I will be visiting Australia (Sydney for a couple of days then Tasmania for a couple weeks then Cairns for a week or two) in July.

Me and my good friend Charlie will spend it on hookers and blow, of course.

RE: Mac builds:  what BlueMatt said.  Despite using a Mac as my development machine, I am not a Mac developer-- I'm an old Unix developer at heart. I learned enough Windows "Win32-api" programming to create a couple of products, and I know a lot about web development, but I'm a newbie when it comes to making applications for the Mac.

RE: wallet encryption:  I want encryption of wallet private keys (requiring you to enter your password to send coins) to be part of the next release, and I think that is a big enough feature to bump the next release version to "0.4".

RE: x86-64 client:  for the Windows?  or for Linux?  32-bit should work find on 64-bit Windows, there's no real reason to do a 64-bit version.  For Linux, there should be a bitcoin in bin/64/

RE: bitcoind not forking by default any more:  yes, that is intentional, and I forgot to mention it in the release notes.  When the mac binary is done I'll update the README.  Run bitcoind -daemon (or put daemon=1 in the bitcoin.conf file) and you'll get the old behavior.

Wow, I new this would generate discussion... but wow!

A couple of quick notes:

noagenda nailed it-- I was contacted specifically by In-Q-Tel, the CIA's "look for interesting/promising new private technologies and then invest in them" spin-off.  I get the impression they organize the conference.  This year the conference is about money.

They are serious about security; there will be no recording, and I will not be allowed to bring any electronic devices with me.  I am planning on posting my talk, and if I get my act together in time I'll try to post it before I give it so y'all can give me feedback.

I'll be signing an agreement that I, or my company, will not use my appearance for publicity purposes.  So please, no unofficial "from the bitcoin community" press releases about this.

If talking to them makes y'all trust me less... then good!  I'd like to see more careful code review, and, as others have pointed out, if bitcoin can be destroyed by one person, or requires the leadership of one person, then it has failed to be the strong, decentralized system that I think it is.

RE: me == satoshi:  here's some C++ code I wrote 15 years ago:
  http://oss.sgi.com/cgi-bin/cvsweb.cgi/inventor/apps/demos/revo/RevClass.c%2B%2B?rev=1.1.1.1
I have a very different coding style from Mr. Nakamoto.  And I don't know nearly enough crypto to build something like bitcoin by myself.

And one final note:  the US government is a really, really, really big organization.  Like any big organization, different parts have different motives and goals.  I hope I'll get a little tiny glimpse into what one part of that big organization thinks about bitcoin.

Yup.  I think this might be the last release I do that, though...

EDIT: Done, svn revision 251.

I want to get this out in the open because it is the kind of thing that will generate conspiracy theories:  I'm going to give a presentation about Bitcoin at CIA headquarters in June at an emerging technologies conference for the US intelligence community.

I accepted the invitation to speak because the fact that I was invited means Bitcoin is already on their radar, and I think it might be a good chance to talk about why I think Bitcoin will make the world a better place.  I think the goals of this project are to create a better currency, create a more competitive and efficient international payment system, and give people more direct control over their finances.  And I don't think any of those goals are incompatible with the goals of government.

I'm only very slightly worried that talking about bitcoin at the CIA will increase the chances they'll try to do something we don't want them to do.  I think accepting their invitation and being open about exactly what bitcoin is will make it less likely they'll see it as a threat.

PS: Full disclosure: I'll be paid a one-time fee of $3,000 to cover expenses and pay me for my time.  I don't want any "Gavin is on the CIA's payroll" rumors to get started, either...

As always, comments and questions and discussion welcome.  I'd really rather not hear any conspiracy theories about how they'll secretly implant a mind-control chip in my head while I'm there, though....

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Binaries for Bitcoin version 0.3.21 are available at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support.  Enable automatic opening of a port
for incoming connections by running bitcoin or bitcoind with the
- -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts.  You can now send, and
bitcoin will display, bitcoin amounts smaller than 0.01.  However,
sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so
you can send 1.0001 bitcoins without a fee, but you will be asked to
pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A
records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address
in a single transaction.

* Several bug fixes, including a serious intermittent bug that would
sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now
shown in listtransactions.


SHA1-checksums for the binary files are:

54254cba039b02a2f49fdc98b8fe820d0fd4e410  bitcoin-0.3.21-linux.tar.gz
3f94d6a8b08c455a7886561089270247eaada7b4  bitcoin-0.3.21-win32-setup.exe
f9a39404433b01b5a22225855f42275c1c902c26  bitcoin-0.3.21-win32.zip
(mac version should be ready soon)

Thanks to all those who contributed to this release:

Dan Helfman
Dan Loewenherz
devrandom
Eric Swanson
gjs278
Jeff Garzik
Luke Dashjr
Matt Corallo
Matt Giuca
Nils Schneider
ojab
Pieter Wuille
sandos
Santiago M. Mola
Sven Slootweg

Gavin Andresen   gavinandresen@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAk24UbsACgkQdYgkL74406jQlwCeOPf1avdfugmzfiVtuT0hUacm
4DEAoJcAR0ha8VKQ8Mu6QoG9ywDLvwjI
=DRxu
-----END PGP SIGNATURE-----

What operating system?  This sounds like a wxWidgets or bitcoin client bug that needs fixing.