Bitcoin Forum

-----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-----

Are you going to put the source on SourceForge SVN?

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

EDIT: Done, svn revision 251.

Many thanks to all the developers who make this happen!

Cool!

I tried sending .01001 and i still got prompted for a fee, same with .10001. Is this quote misleading or is this a bug?

Thanks.

I thought the idea of using SVN for "release candidate" code was good. Stability and security are very important for Bitcoin, so there needs to be a long testing period before stable releases are made.

May be we must want before 1/2 of all bitcoind been updated to this version?

I really want to try out sendmany, but I'm a little nervous about being the unlucky person to find the corner-case bug that sends all your bitcoins to satan. Maybe I'll try it on another PC first.

I noticed that bitcoind has to be explicitly started with -daemon in order for it to fork. Was that change intentional?

Also, how do i use the new -dnsseed parameter? -dnsseed=domain.here ? Regardless of what server I specify, the client doesn't seem to connect to it, although it does find other peers somehow, even with domains that are definitely not running a bitcoin client.


Feel free to use my receiving address for testing :3

Sendmany works. One of the pool operators (slush I think) uses it for pool payments. And there is always testnet if you feel uneasy.

One thing I like to mention:

There is a display issue with the German version (only German ?) when setting the font-size to 125% in Win7.
http://img148.imageshack.us/img148/8084/125percent.png

Bitcoin then looks like that:
http://img534.imageshack.us/img534/5135/125bit.png
Note the Number in the lower right corner. Afaik it is the Number of total transactions but the label isn't fully shown.

Also, when you click on ->sending (->Überweisen) you get this error message:
http://img199.imageshack.us/img199/8287/125bitalert.png

And when you finally get to the transfer dialog, it looks like that:
http://img12.imageshack.us/img12/5850/125bittransfer.png
Pretty messed up. You have to resize the window to get to the "transfer" and "cancel" button.

And since the "settings window" can not be resized like all the other ones, I cannot change the transaction fee:
http://img576.imageshack.us/img576/6407/fees.png
This sucks.

I know this only affects like <1% of the bitcoin userbase but anyways,
can this be fixed somehow ?

ummm ... Mac binary?     /Apple-flavored tears      :'(

Hang on.  Am I the only one who thinks this is big news?

Can you describe exactly what behavior you are seeing?  Include OS/platform details.

"bitcoind" should default to being a daemon server; "bitcoin" does not do this.


The DNS seeds are pre-compiled into the binary, just like the static IP address 'seed' node list that has existed for many versions.

gavin, any idea when the bitcoin client will have a wallet.dat encryption feature?

It happens for me both on Debian Squeeze and Ubuntu 10.10. After starting bitcoind from a terminal it doesn't fork and I can cancel out of it with ^C (or by closing the terminal). Starting bitcoind with the -daemon switch results in the old behaviour and the process forks/detaches from the terminal and runs in the background after printing "bitcoin server starting".

Which version of libminiupnpc4 is required?  I have libminiupnpc4 1.4, and get the following errors when compiling bitcoind (even with USE_PNP=0) on Linux:


Cheers,

Could it be that -DUSE_UPNP=0 triggers ‘#ifdef USE_UPNP’ (it is def'ed, although set to zero)?  If tried replacing ‘-DUSE_UPNP=0’ with ‘-UUSE_UPNP’, and everything compiled smoothly.  :)

Cheers,

Will there be an x86-64 client?

is there an Ubuntu PPA for 11.04? (Natty)

libminiupnpc version 1.5 ie not libminiupnpc4.
This is how it is supposed to work make with USE_UPNP=1/0 means UPnP on/off by default (but compiled in).  USE_UPNP= (ie not defined) means not compiled in.

I certainly think that this is big news.

With the prior version of the client, I would sometimes lose some sub-bitcent change to a transaction fee if I sent .01 to somebody and I had a transaction input with something like .0122222 or something. It would pick that as the only input, and leave the .0022222 as a fee without asking. I thought that it could have combined my .0122222 with some other transaction input of at least .01, and then my change output could have the whole change because then the change would be over .01 as well. I thought this was looked at at some point, so is this "fixed" and included as part of the full-precision support?

Oh, and I'm also eagerly awaiting the Mac build. Is there some reason that it's always delayed that the Mac community could help with somehow?

The Mac builds are built by Laszlo instead of Gavin so it can often take a while longer (depending on how long it takes him to get around to building).  You can try following the instructions in build-osx.txt to build your own but for now, you just have to wait.
That said, in 0.4.0 (the next major version) the build process will most likely be replaced with a distributed one where everyone builds bitcoin deterministically and signs the output with their gpg key allowing people to trust the community rather than any central builder.  However, no solution has been found to building Bitcoin deterministically on Mac.  If you think you can help, please contact devrandom and take a look at https://github.com/devrandom/gitian-builder (https://github.com/devrandom/gitian-builder)

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.

wait a minute.  is this a new client release for us lay folks?

Yep, thats the idea.

do i really want to trust a beta version with all my coins?

Especially after the CIA news. Suspicious release is Suspicious  :D

So far, every version is beta.  There is no "stable" version yet.

thats comforting. :-\

This is an excellent idea.  Helping non-techies be at least as secure as internet banking is the biggest limit for adoption in my social network.

Please take the following advice:  if you cannot afford to lose the money invested in bitcoin, do not invest in bitcoin.

From the standard investor's perspective, bitcoin is very high risk, with any number of possibilities for complete collapse.  An undiscovered software bug could eat your money -- this is beta software after all.  A virus could steal your funds.  A large money player could spike the market down, if they so chose.  A government could intervene.  A million-CPU botnet could take it down.  Exchanges could get hit with massive fraud, or even the equivalent of a bank heist -- after all, most of these are one-person operations, due to bitcoin's small size.

Or, worst of all, a simple massive loss of confidence could cause a value collapse.

You have plenty of skilled developers working hard to make it succeed, and plenty of smart cryptographers reviewing and commenting on the open source code.

So I think it will succeed.

But believe the "beta" label on the software.  Bitcoin is very young.

This is planned for version 0.4, however the only current implementation is very incomplete and AFAIK no one is working on it.

hmm, with new version i can't send 0.01 BTC without fee
0.3.20.2 works fine

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.

Am I getting ignored ??

So implementing 64-bit hashing wouldn't improve hash rate? This is my major concern. I should probably be asking this to the major mining software makers instead of the stock client maker though.

No, thank you for reporting the bug.  The problem is, I dont think anyone knows how to fix it very easily.  Currently almost all of the Bitcoin developers/contributors work on the backend and add new features.  Reworking the GUI is not anyone's specialty.  If you know anything about wxWidgets and C++, please take a look.

No, you are right.  64-bit on the client has no bearing on its mining performance.  You should be using either a gpu miner or a rpc cpu miner, as those tend to be faster anyway. 

So what's the deal with the automatic rescanning? Sipa mentioned it in IRC.

I use a program that allows me to switch between wallets easily. They are stored encrypted, and when one is opened, it extracts to the data directory. I have been forcing a rescan every time I open Bitcoin because if blocks are downloaded with one wallet, the other wallets won't recognize their transactions in those blocks otherwise.

Do I no longer need to -rescan every time I open Bitcoin, saving me a few minutes each time?

That is correct, the client keeps track of how up-to-date the wallet is and should automatically scan the necessary portions of the blockchain for transactions that belong to you when started.

Looks like the window sizes are fixed in src/uiproject.fbp. I can't easily rebuild Bitcoin right now, but this is where I'd start looking.

Oh alright, I was just confused because nobody reacted to my post.
And actually no, I don't know anything about C++ or wxWidgets, I'm more of a Java fan ;)

?

AFAIK, the current wallet encryption implementation only lacks IV storage, and someone is indeed working on it :)

just upgraded through windows installer and I got a new receiving address(I think) is that normal?

Was not aware anyone was working on it, I thought the IVs were just going to be the public key hashes.  I just assumed no one was really putting any time into it as it hadn't been updated in quite a while (and doesn't even compile for me).
/Thread Hijack

Current branch (#crypter) compiles just fine.

Hm, I guess my repo was unclean. 

Excellent work guys...

Can I make a few requests?
1) The ability to order the Address Book listings by a column.  For instance, the ability to order the list by "label" automatically, or maybe from newest to oldest.
2) The ability to hide addresses in the Address Book.

Don't know if those have been brought up before (they must have been) but those are things that I would like to see implemented.

:)

Hi,

I noticed a relatively high upload rate while Bitcoin (version 0.3.21-beta) is on.
http://www.secure-sip-server.net/SSS_101/public/pics/btc.png
Even after downloading all blocks the upload rate is mostly higher then the download. Why this? When I quit Bitcoin the up- and download goes to nearly 0 again, so it't not an other program doing this.

Its a P2P network, others will download the blockchain from you, so it is uploaded using your bandwidth.

Thanks for the explanation!!!