next-test is a branch of the mainline bitcoind & Bitcoin-Qt with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): |
|
|
|
Bitcoin version 0.4.4 is now available for download at: http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/This is a bugfix-only release based on 0.4.0. Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. Please report bugs for the daemon only 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.4.4#.tar.gzBUG FIXES- Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
- Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
- Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
- Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
- Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
- Various memory leaks and potential null pointer deferences have been
fixed. - Several shutdown issues have been fixed.
- Check that keys stored in the wallet are valid at startup, and if not,
report corruption. - Various build fixes.
- If no password is specified to bitcoind, recommend a secure password.
- Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
- Add checkpoint at block 168,000.
Thanks to everybody who contributed code or helped test this release: Pieter Wuille Luke Dashjr Gavin Andresen Gregory Maxwell Matt Corallo Lars Rasmusson Daniel Folkinshteyn |
|
|
|
hmmm, I hope this wont happen to soon since right now I have over 200 BTC still unpaid and without a decent chance of recouping atleast some of it would simply suck. Unless you figure out a way to start rewarding only those who still mine at the pool from new blocks generated since it seems a huge volume of users simply stopped and is now piggybacking on remaining miners who still clear blocks for the pool, these loyal miners would be affected the most since they constantly will have unpaid balances. I suspect you mean extra credit. That was never promised to become Bitcoins or retain any value. |
|
|
|
FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.
Why's that? The v0.6.0rc4 tag includes the -lmingwthrd fix. When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source. The v0.6.0rc4 tag includes the fix, but it removes -lmingw only in the gitian build of Qt. Since it doesn't also change the filename, there is a probability anyone using gitian will not rebuild Qt; they, and non-gitian builders, will therefore not get the change. I submitted a pull request to move the change to bitcoin-qt.pro where it belongs, and incorporated this into the v0.5.3.1 tag. While it would be possible (and in the case of the binaries, was done) to build v0.6.0rc4 with the adjusted Qt, doing so required inside knowledge of the fix, and could not be explained without disclosing the nature of the security issue; therefore, I stuck with a blanket "will not" to be on the safe side. |
|
|
|
So, [sarcasm]*theoretical question*[/sarcasm], when some retard mines for over 24 hours with the username set as <bitcoinaddress>.x instead of the username being properly set as <bitcoinaddress> with a password of x, is there any chance said retard can get the rewards he should have earned added returned to his queue?  Not practical, sorry. The shares are processed in realtime, and there's no way for me to change the history without significantly rewriting code and taking the pool down for probably an extended duration to try to adapt the historical block record. |
|
|
|
The key is having a compiler toolchain written in the language itself. After some iterations the original C-code used to bootstrap (if it was C) can be replaced totally. Only if the language can be compiled to native code at all. In which case it's just as "at risk" of buffer overflows etc as C++ is. For Python, Java (for practical purposes; GCJ seems to have trouble with most real Java software), etc, they cannot be compiled to native code, and thus always require a C/equivalent interpretor. |
|
|
|
I'm trying to register for the namecoins and my bitcoin qt doesnt have the message option. How can I correct this. Upgrade to 0.6.0rc4. |
|
|
|
|
FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.
|
|
|
|
At least python and ruby are both implemented in a wide variety of other languages, not just C. My point is that every language eventually reduces to C somewhere, even C++. |
|
|
|
Bitcoins are not recognized by the US as a currency or commodity, so there are no governmental laws regulating trade. This is complete nonsense. The US recognizes Bitcoins as "stored value", and even if it hadn't yet, you could be sure it's something, and everything is regulated/taxable. |
|
|
|
|
Finally got around to removing the old debug info ("fee"), so now Eligius is completely fee-free (as of midnight UTC tonight).
|
|
|
|
You have to be god-like to not create security vulnerabilities in significantly C/C++ software. 'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere). But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.
Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw). Guess what language Java/Python/etc are implemented it. |
|
|
|
If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier  I'm using the anonymity patched bitcoin client ( https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too. I don't have any info on the vuln or code for the patch. So I'd advise you not to use my patched binaries until the vuln and fix have been disclosed and I can compile new ones. Dev team is doing builds of 0.5.3+coderrr with the fix applied; should be available later today. |
|
|
|
It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity. It actually isn't impossible, just complex enough it hasn't been accomplished yet. It's quite possible to write a specialized emulator that follows every possible code-path with "quantum" memory states... |
|
|
|
so all the 0.4.* versions are still safe, right?
For this specific bug, yes. But wxBitcoin (the GUI in 0.4.x) is not maintained or supported at all, so it likely has other unfixed vulnerabilities. |
|
|
|
are the backups in 0.6.0 for windows encrypted?
No why wouldn't it be? if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think. Encrypted wallets aren't really encrypted entirely. Only your private keys are. There's still a lot of sensitive data in there you probably don't want public. |
|
|
|
|
Show Posts
