Bitcoin Forum

Win32, Linux and source releases for bitcoin v0.3.23rc1 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/test/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

• P2P connect-to-node logic changed to reduce timeout a bit.  The network saw a huge influx of new users, who do not permit incoming connections.  This change is a short-term hack, to more quickly hunt for useful P2P connections.  Better "leaf node" logic is in the works, but this should let us limp along until then.
• Transaction fee reduced to 0.0005 for new transactions (see note below)
• Client will relay transactions with fees as low as 0.0001 BTC (see note below)

NOTE:  There has been some fee confusion recently.  Free transactions are supported and relayed as they always have been, according to special anti-spam rules.  See https://en.bitcoin.it/wiki/Transaction_fees for details.

Full git changelog:

Dean Lee (1):
      Updated Chinese Simp translation

Doug Huff (3):
      Fix rfc1918 and rfc3927 compliance for ignoring non-internet-routable host
      Add common temp files to .gitignore.
      Demystify a few magic numbers.

Han Lin Yap (2):
      Added Swedish translation
      Remove unused variable

Jeff Garzik (4):
      Bump version to 0.3.23.
      Reduce minimum TX fee for new transactions, to 0.0005.
      Lower minimum relay TX fee to 0.0001 (from 0.0005) BTC.
      Add minimal release process docs.

Matt Corallo (1):
      Fix CPU Usage bug when using -nolisten and have no connections.

Nils Schneider (1):
      create keypool in LoadWallet()

Pieter Wuille (3):
      Update transactions already in the wallet when rescanning.
      Fix for small change outputs
      Faster timeout when connecting

Note to self -- actually compile the newly updated translations.

SHA1 sums for rc1:
5ca82c5b694fc432b4b342dde5cd1b145e265f13  bitcoin-0.3.23rc1-linux.tar.gz
8853206ec4d9e48bb41a0482ac1367f6fb01bcad  bitcoin-0.3.23rc1-src.tar.gz
12952b1c4a15ce55564500dace18ee22eb2feaa8  bitcoin-0.3.23rc1-win32-setup.exe

PGP signature of same: http://paste.pocoo.org/raw/405066/

Does this version allow opting out of the fee, whether recommended or not?

For normal transactions yes.  For spam transactions no.  Quoting,

MacOSX -rc1 binary uploaded.  Updated sums:

5ca82c5b694fc432b4b342dde5cd1b145e265f13  bitcoin-0.3.23rc1-linux.tar.gz
cdf6f76a41c880ebac53455e373fa78602da7be7  bitcoin-0.3.23rc1-macosx.zip
8853206ec4d9e48bb41a0482ac1367f6fb01bcad  bitcoin-0.3.23rc1-src.tar.gz
12952b1c4a15ce55564500dace18ee22eb2feaa8  bitcoin-0.3.23rc1-win32-setup.exe

PGP signed: http://paste.pocoo.org/raw/405159/

Right, I get that. But for example in 3.22 when trying to send a very low priority tx, you were forced to pay a fee. Do you now have the option to not send with a fee even though it will likely take a long time to be confirmed?

No, you have to hack the client in order to send spam.

In the future, people are considering a checkbox to avoid the recommended fee.

Can you display the full 8 decimal places in the Balance field? I don't like having a hidden amount of value left in my wallet.

Thanks for getting the Mac version out quickly!

Or at least 4 decimal places. 2 are not enough these days...

Funny, I just headed over here to ask when is 0.3.23 due ... great timing :)

Why does it still say "Fee 0.01 recommended"? (under settings->options)

What you see is what you have. The full decimals will appear if you receive a transaction that has fractions of a bitcent.

This is not true. I have received several full precision deposits, the full value of which is not reflected in the balance.

I'm using this beta and it shows 8 decimal places on the balance field  ;)

Hum... good question...

Everything looks okay from here. I'm seeing my full 8 digits of precision. As others have noticed, a 0.01 transaction fee is still "recommended", but that's just cosmetic.

Another cosmetic request: given the new fee schedule, could the minimal number of decimal digits displayed be either increased to 4, or decreased to 0?

LightRider: 0.44370502 + 0.07668922 - 2.17039424 = -1.65 exactly.

There will be a lot of fee-related UI changes in the next version.  Matt C already has a 'better fee UI' pull request at github.

This version is just to triage the P2P network, until we get to that awesome, big next version with wallet encryption and other useful things.

The point of v0.3.23 is to release it fast, fast, fast...

So people: test, test, test!  :)

Does switching from a newer version to a previous version mess up the wallet.dat file? Is it possible that the previous version might have not handled full precision transactions properly?

Probably not, we've taken steps to make sure that works.  But if you jump back too far in time, that could create a problem.


Define previous version.  All recent versions handle full precision correctly, though the UI might not display it or other cosmetic details like that.

Mystery solved, I apologize for the confusion. Apparently the transaction took a very small fee that I could not account for until I saw the transaction page on Blockexplorer. Also, I neglected to look for it in the transaction details panel in the client. I feel very silly now. Thanks for your help.

Awesome turnaround guys! I tested the Mac version both with and without port forwarding, it was able to establish a connection to the network within a few seconds in both configurations (tried a few times). This was with UPnP off.

I also tried the UPnP option and it worked fine here.

   Is there something done to prevent sending BTC on unknown address when backuping new wallet (without  100 new address created) - or we will again see something like -  " OMG  - i am followed instructions on backup, and my xxxx BTC  gone in unknown direction - where is nearest window to jump in ?"

   Maybe some steps to send back unclaimed tx`s back to sender in 6 month ? Just to avoid that unnecessary windows jumps.
   
   How about choose clearly one address to send (not all of us  buying drugs , your know, - at least not every time) .
   Easy consolidation of wallet amounts on one address still require some focus-pocus actions with fee free nodes ?
   Clear representation of BTC`s on each address in wallet ?
   Floating point operations ? - that is annoying question, but still important.

Anyway, i am believe you are done great job. Will test it.
 

The keypool is now created immediately in this version. However, it could use some testing.

no zip version?

One thing that might make the display of the wallet less confusing (maybe) would be to show all the properly available decimal places.

1.0000000000
for example.

or 2.500000000
not just 2.5

Why truncate the display at all?

Thanks for your hard work!

ditto. and, why was the 'generate coins' option removed? will you bring it back or is that only for elitists who can understand setting up scripts?

I somewhat agree. Theoretically a 10mhash CPU could generate 0.35 BTC over the next month if the difficulty stayed stagnant. It won't, but still that is a great way to distribute small amounts of currency to new interested users. Sure, flash a warning perhaps that it might deplete their CPUs lifespan and increase their electrical bill... but don't restrict them from the possibility that was once there. A lot of people don't want to have to install more than 1 program in the course of a their days. One is more than enough to frustrate many of my friends.

FFS, just start the client with the -gen option then.

If you really want to mine on a CPU, please use cpuminer or another specialized program that is efficient, optimized and supports pool mining. The miner left in the default client is only intended as a reference and for testing.

Incorrect.  Besides being slower than other CPU miners, the built-in CPU miner has never supported pooled mining.  It only mines full blocks.  Thus, users either get zero BTC (highly likely) or 50 BTC (highly unlikely).

At current difficulty, you get a block once every 8 years, at 10 Mhash/sec.  http://www.alloscomp.com/bitcoin/old_calculator.php

Was the spam-detection algorithm improved since 0.3.21 ?
In 0.3.21, even when i wanted to send some bitcoins having 7 confirmations, i had to pay the fee. Downgrade to 0.3.20 fixed the problem, and i could send the bitcoins (and later i got 2 confirmations after 45 minutes, so the transaction was OK contrary to what client claimed).

So is this finally fixed or not ?

Polite bump.

Let's ask this question differently: Was the algorithm which decides what is spam and what isn't changed at all since 0.3.21 ?

No, but the minimum fee required in case it is considered "spam" was decreased to 0.0005 in 0.3.22 and to 0.0001 in 0.3.23.

Actually, i had the forced feee even when sending 10 BTC having 7 confirmations....
So i guess this wasn't fixed.