Where is Gavin's announcement? I can not find it. 
Gavin did not make the announce: http://forum.bitcoin.org/index.php?topic=12269.0
Topic: Please test: Bitcoin v0.3.22 release candidate (Read 15852 times)
Gavin did not make the announce: http://forum.bitcoin.org/index.php?topic=12269.0
Where is Gavin's announcement? I can not find it.
I'm not sure which exact release candidate of 0.3.22 I am using, it says it's 0.3.22-beta. It's still using .0005 BTC fees, so it's probably not RC5.
I wanted to send a 1.0 BTC transaction, my balance was 1.0085BTC. Of course, the window came up asking me to add a 0.0005 fee, which I accepted. Suprisingly, I now have only 0.0 BTC left in my account.
The reason is simple, my transaction would have contained an output of 0.0085BTC (the "change"), so the fee was raised. I'd have expected the prompt to ask me if I'm okay with a 0.0085 fee instead of 0.0005.
As soon as my transaction is included in a block, I'll post a blockexplorer link.
Update - Here it is: http://blockexplorer.com/tx/e90356e7b71ba6c440ceeb5e1ea789f4b6dc14c62c0e5f8f00ebd1d5bb7ef8c2
I wanted to send a 1.0 BTC transaction, my balance was 1.0085BTC. Of course, the window came up asking me to add a 0.0005 fee, which I accepted. Suprisingly, I now have only 0.0 BTC left in my account.
The reason is simple, my transaction would have contained an output of 0.0085BTC (the "change"), so the fee was raised. I'd have expected the prompt to ask me if I'm okay with a 0.0085 fee instead of 0.0005.
As soon as my transaction is included in a block, I'll post a blockexplorer link.
Update - Here it is: http://blockexplorer.com/tx/e90356e7b71ba6c440ceeb5e1ea789f4b6dc14c62c0e5f8f00ebd1d5bb7ef8c2
Is anyone else having trouble solo mining with RC6?
I keep getting this:
Once I try to start a miner, the bitcoin.exe (or bitcoind.exe if I run that) process pegs the CPU until I end-task it. (Exiting makes the GUI go away, but the process keeps running with the CPU pegged.)
It used to work, and I have the proper username and password in my bitcoin.conf.
I keep getting this:
Code:
bitcoin-miner 0.10 Copyright (c) 2011 Ufasoft http://ufasoft.com/open/bitcoin
Mining for http://localhost:8332
1 threads Using SSE2
0 MHash/s Error 80072EE2: The operation timed out
Mining for http://localhost:8332
1 threads Using SSE2
0 MHash/s Error 80072EE2: The operation timed out
Once I try to start a miner, the bitcoin.exe (or bitcoind.exe if I run that) process pegs the CPU until I end-task it. (Exiting makes the GUI go away, but the process keeps running with the CPU pegged.)
It used to work, and I have the proper username and password in my bitcoin.conf.
The text in the options still says a fee of .01 is recommended. Is this intentional?
Yes. Scroll up and read the -rc5 release notes, and see this post.
The text in the options still says a fee of .01 is recommended. Is this intentional?
Because they might use the processor somewhat more efficiently I suppose.
No, just...no.Why does the Linux Bitcoin distribution come with 64-bit binaries?
Because there are occasionally some lib errors running the 32-bit ones on a 64-bit machine. 
Why do you want 64 bit binaries?
Because they might use the processor somewhat more efficiently I suppose. Why does the Linux Bitcoin distribution come with 64-bit binaries?
You would have to patch the client to connect= on a different port, and those nodes would have to change their listen ports.
OK, thanks. I did this and it seems to work fine. The only change needed was GetDefaultPort() in net.h. I do believe this is something that should be configurable from the command line. Various entities could start watching/blocking port 8333 in an attempt to shut Bitcoin down.
One other question...how do I generate 64-bit binaries? Compile from a 64-bit machine? I don't see any switches in the makefile.
Why do you want 64 bit binaries?
Thanks for fixing the transaction fee thing. I had something annoying happen to me today.
I tried to send .10 BTC to another computer of mine, and it asked for a .02 transaction fee. I set the fee at .02 and try and send .08 BTC, and it tells me that I need a fee of at least .04 to send it.
Argh! It's moments like that which made Mac OS 9 apologize profusely and disown all responsibility before giving an error report.
--Edit--
Nope. Still happens. I don't want to have to spend half of my transaction on fees!
I tried to send .10 BTC to another computer of mine, and it asked for a .02 transaction fee. I set the fee at .02 and try and send .08 BTC, and it tells me that I need a fee of at least .04 to send it.
Argh! It's moments like that which made Mac OS 9 apologize profusely and disown all responsibility before giving an error report.
--Edit--
Nope. Still happens. I don't want to have to spend half of my transaction on fees!
You would have to patch the client to connect= on a different port, and those nodes would have to change their listen ports.
OK, thanks. I did this and it seems to work fine. The only change needed was GetDefaultPort() in net.h. I do believe this is something that should be configurable from the command line. Various entities could start watching/blocking port 8333 in an attempt to shut Bitcoin down.
One other question...how do I generate 64-bit binaries? Compile from a 64-bit machine? I don't see any switches in the makefile.
Well, maybe I misunderstood the purpose of the -port option. I'd like bitcoind not to use 8333 for anything. I don't want any traffic on the network to/from port 8333. I have my own peers spelled out in the bitcoin.conf file (connect=x.x.x.x), so I don't need to discover nodes. Is there a way to establish an outgoing connection on an alternate port?
If you connect=x.x.x.x it connects to that node on port 8333, which is the default port. You would have to patch the client to connect= on a different port, and those nodes would have to change their listen ports. I've been testing the -port option, and it doesn't seem to work. I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat). I tried setting the port through both the command line option and in the bitcoin.conf file. Has anyone else tested this?
Bitcoin still has to make a ton of outgoing connections to ...:8333 because that is where remote nodes are listening and thus connections must be made to that port, but, as always, it will connect from ...:[random high-number port]. According to my system, it is listening properly on *:[port i set]Well, maybe I misunderstood the purpose of the -port option. I'd like bitcoind not to use 8333 for anything. I don't want any traffic on the network to/from port 8333. I have my own peers spelled out in the bitcoin.conf file (connect=x.x.x.x), so I don't need to discover nodes. Is there a way to establish an outgoing connection on an alternate port?
Matt, can u use Process Explorer to detect specific activity localized to port 8333?
If you double-click on the process, and click the TCP/IP tab, it will show you which connections belong to that process. 
I've been testing the -port option, and it doesn't seem to work. I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat). I tried setting the port through both the command line option and in the bitcoin.conf file. Has anyone else tested this?
Bitcoin still has to make a ton of outgoing connections to ...:8333 because that is where remote nodes are listening and thus connections must be made to that port, but, as always, it will connect from ...:[random high-number port]. According to my system, it is listening properly on *:[port i set]Matt, can u use Process Explorer to detect specific activity localized to port 8333?
I've been testing the -port option, and it doesn't seem to work. I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat). I tried setting the port through both the command line option and in the bitcoin.conf file. Has anyone else tested this?
Bitcoin still has to make a ton of outgoing connections to ...:8333 because that is where remote nodes are listening and thus connections must be made to that port, but, as always, it will connect from ...:[random high-number port]. According to my system, it is listening properly on *:[port i set] 
Downloading RC6 now
I've been testing the -port option, and it doesn't seem to work. I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat). I tried setting the port through both the command line option and in the bitcoin.conf file. Has anyone else tested this?
The network is experiencing growing pains, sure, but cries of "Bitcoin doesn't work for new users" are just hyperbolic, considering this is an issue that has been present for years and bitcoin does seem to work for new users.
Unfortunately I can't go back in time and do careful testing a month ago. What I can tell you is that a month ago I brought up two firewalled nodes and immediately got connections... I was surprised a few weeks later when people started showing up in #bitcoin complaining of being stuck in 0 connections state. And I'm now finding that a configuration which clearly worked before (firewalled hosts) no longer starts up reliably.
While the software hasn't changed in this regard, the composition of the network has. It's not hard to see how the old situation worked fine when most hosts were accepting connections, but with a super-majority not accepting connections it appears to be failing pretty much completely for a popular configuration.
I don't think thats particularly hyperbolic…
There isn't any particularly compelling reason for most users to upgrade right now, nor do these fixes have big network effects (e.g. a connect() timeout fixed node is still fixed regardless of what the rest of the network runs). So this not making it into .22 may not matter much ultimately, so long as a version with the fixes is quickly forthcoming.
The network is experiencing growing pains, sure, but cries of "Bitcoin doesn't work for new users" are just hyperbolic, considering this is an issue that has been present for years and bitcoin does seem to work for new users.
There are always calls for One More Issue to be stuffed into a release, and this is no different. Adding anything to 0.3.22 means another round of testing, probably delaying the release at least another 7-10 days.
If you have an important issue, it is easy enough to release a 0.3.23, but further 0.3.22 delays seem unwise.
Jump to: