Bitcoin version 0.3.21

[ploum]

is there an Ubuntu PPA for 11.04? (Natty)

[1714098146]

1714098146

[1714098146]

1714098146

[Matt Corallo]

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:

libminiupnpc version 1.5 ie not libminiupnpc4.

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. 

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.

[pc]

* 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).

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

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?

[Matt Corallo]

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

[Gavin Andresen]

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.

[cypherdoc]

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

[Matt Corallo]

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

Yep, thats the idea.

[cypherdoc]

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

[deadlizard]

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

Especially after the CIA news. Suspicious release is Suspicious 

[Matt Corallo]

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

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

[cypherdoc]

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

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

thats comforting.

[eMansipater]

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

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.

[xf2_org]

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

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

thats comforting.

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.

[Matt Corallo]

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

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.

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

[Vort]

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

[Gavin Andresen]

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.

[SmokeTooMuch]

One thing I like to mention:
(...)

Am I getting ignored ??

[LightRider]

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.

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.

[Matt Corallo]

Am I getting ignored ??

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.

[Matt Corallo]

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