Please report to the GitHub issue tracker now. |
|
|
|
Great job! Well done! Is this the same as the rc1 that you posted earlier (Except for the version number change of course) or has something been changed between this release and rc1? Thanks  No changes, but the Windows Bitcoin-Qt was rebuilt by multiple people (devrandom and sipa) to ensure integrity since it isn't 100% deterministic yet. |
|
|
|
|
We're under a tight DoS attack. Been analyzing it, but not sure what the cause is yet.
|
|
|
|
Bitcoin version 0.5.2 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/This is a bugfix-only release based on 0.5.1. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesStable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gzBUG FIXES- Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
- Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability). - Fixed some address-handling deadlocks (client freezes).
- No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
- Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
- Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
- Don't show "IP" for transactions which are not necessarily IP transactions.
- Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Matt Corallo Wladimir J. van der Laan Gavin Andresen Pieter Wuille Dylan Noblesmith |
|
|
|
I'm more concerned about the current state of "buffer empty". You mentioned that it is acting as if "proportional" now and the per-share price varies. How is this affected by pool-hopping? Since the share price is varying would this make the pool a target now?
The share price isn't itself varying; the currency is. Since there aren't enough Bitcoins to go around, the pool issues its own fiat "currency" called "extra credit"; this has no value itself, but the pool tries to convert it to Bitcoins every block until it's gone. Specific to pool hopping, the whole premise of hopping is being able to get more than the fair PPS price for shares. This is never possible with SMPPS. Also, I'd like to note that we're gaining and will probably have a buffer again pretty soon. However, the law of large numbers means that in the long run, the buffer should get closer and closer to zero. |
|
|
|
oh i see.... any estimated date for 6.0?
0.6, not 6.0. Big difference. I wouldn't bet on it being until March. |
|
|
|
just wondering why arn't some of the new RPC functions that are in the source built into this build? like getblockbyhash?
As stated in the initial post, this is a bugfix-only release. New features will be in 0.6. |
|
|
|
While I can clean out old shares from the core database, the webserver still requires a full history of shares for active servers. That sounds like a pretty bad design flaw. So I have to assume it's more a case of using a product to perform a task it was never designed to do or even using it in a manner never envisioned by the developer. No, we just never envisioned a pool server running on for months at the time. There were (multiple) plans to rewrite it by the original author and others, but nothing has come to fruit from them so far... |
|
|
|
Are there digital signatures or hashes or such for the files? It looks like they're not even hosted on sourceforge over SSL (I don't know how hard it would be for them to set that up), and it'd be useful if the downloads were signed by the developers (preferably several), who could attest to the fact that the binaries are correctly compiled and won't (intentionally at least) take all our money.
I think I'm the only one who signed rc1. BlueMatt built it. The same binaries (except Bitcoin-Qt for Windows, since it isn't 100% deterministic yet) are being renamed to final now, built and signed by devrandom and sipa, and signed again by me. I expect Gavin might sign the hashes when he uploads them too. |
|
|
|
Why did you need to switch over? While I can clean out old shares from the core database, the webserver still requires a full history of shares for active servers. This copy of the shares had grown to be 400 GB, and disk space doesn't grow forever. I figured it prudent to start over while we had the opportunity. What is the buffer? The SMPPS buffer? Yes, that buffer. Now that we've switched to Ra, did that happen because people moved to 'generous' and was the buffer donated? The buffer was exhausted. Due to timing, I ended up with 0.20 BTC leftover. I don't consider this amount worth the time trying to figure out how to split it up. |
|
|
|
|
This should be possible with bitcoind 0.5 and Bitcoin-Qt 0.6.
|
|
|
|
I know I am always behind adding new versions to the charts! You guys keep adding them too often and I have not worked out a nice easy way to add the to rrd. Anyway I have now added a table so you can at least see the current number of all versions: Unfortunately, since this number is becoming the protocol version and neither of the more common clients (bitcoind and Bitcoin-Qt) comply with BIP 0014, such nice statistics will probably become history anyway.  |
|
|
|
But it makes me wonder whether I should keep upgrading to the latest versions as soon as they come out, or whether the tried-and-true older versions are more or less likely to be "correct"… That's why I'm maintaining the 0.4.x series. |
|
|
|
Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download). That sounds scary. Could you clarify what risks somebody has in using 0.5.0 and 0.5.1 right now? Is there link to a forum thread or the like about this? Or is this not as scary as it sounds? It's not that scary if you follow best practices of waiting 6 confirmations for transactions. Even if there's a malicious miner out there, other miners would have rejected his blocks. |
|
|
|
So why is the reward per share bouncing all over the place now? Am I mistaken in thinking it's supposed to be a fixed rate per share?
http://eligius.st/wiki/index.php/Shared_Maximum_PPSLong story short, if the pool doesn't have enough money for PPS, it's basically proportional, but will try to make up the difference in the future short blocks. Long-run, it will average out to normal PPS prices. |
|
|
|
What's the ETA on the official release? It's looking good so far! Technically, it's already tagged. We just wanted to make sure more people tested it before putting it on the front page.  |
|
|
|
|
FWIW, if you mine in a KVM and your GPU crashes, this will recover without a (real) reboot (obviously you will need to adapt it for your setup a bit):
killall -9 qemu-system-x86_64
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.0/remove # this is the Radeon's HDMI audio on my system
echo 1 > /sys/bus/pci/drivers/pci-stub/0000:01:00.1/remove # the GPU
echo mem > /sys/power/state # this will put your computer to sleep! don't do remotely
# YOU NEED TO ACTUALLY WAIT 10 SECONDS HERE, to power the card down COMPLETELY
# AFTER PRESSING YOUR POWER BUTTON TO GET THE SYSTEM RUNNING AGAIN
echo 1 > /sys/bus/pci/rescan
# now just start KVM like you usually do
|
|
|
|
|
FWIW, the BIP16-as-preprocessor argument seems fundamentally flawed to me... The C preprocessor acts on explicit statements at compile-time. Scripts are already compiled, and BIP16 is affecting behaviour without any statements or equivalent.
|
|
|
|
|
Show Posts
