Is version 0.5 safe enough to recover a backed up wallet from? 0.4 isn't downloading the block chain when I try to recover.
Yes. But not being able to download the block-chain sounds like a networking issue that 0.5 is unlikely to fix. |
|
|
|
Release Candidate 7 binaries are available at: https://sourceforge.net/projects/bitcoin/upload/Bitcoin/bitcoin-0.5.0/test/Difference between rc6 and rc7 : rc7 does not remove BDB (Berkeley database) log/* files, because that is causing un-readable wallets on some people's machines (all the reports were from people running 64-bit version of Linux, but that might have just been coincidence-- I could never reproduce the problem in any of my test environments). What that means: old private keys can remain in a file on your disk even after wallet encryption, but they will eventually be removed. Details: BDB closes the old logfile and opens a new one when it get close to 10megabytes big. When bitcoin shuts down cleanly, it asks BDB to remove any unused log files, and BDB will remove all but one file from database/log.* So: if you encrypt your wallet, unencrypted private keys will be in the old part of the log file. But after running for a half a day or so, BDB will close that old log file and open a new one. Then, the next time you restart bitcoin, the old log file containing the unencrypted keys is removed. This seems like a reasonable compromise between security and safety for now; a better wallet encryption solution for the next version of bitcoin (for example, one that doesn't require shutting down and restarting after encrypting the wallet) is a good idea, but out of scope for this release. |
|
|
|
|
They're not throwing away 0.01 BTC, they just haven't redeemed them yet-- they're using valid-but-strange transactions.
|
|
|
|
I'll see if the private key is present on the disk image at all after 0.3.24->0.4.1, 0.4->0.4.1, and ->0.5 when converting and encrypting (which requires care to not inadvertently put the key on the disk by searching -> MUI registry entries, save keys in text files, pywallet --web -> browser cache, etc).
Absolutely no guarantee is made that old, pre-rc6 private keys will not end up unencrypted somewhere on the disk. There is no guarantee that newly generated, post-rc6 private keys will not end up on the disk, either, although the code tries to keep that from happening (locking memory so it is not swapped to disk, for example). There should be no files containing unencrypted private keys after rc6 rewrites the wallet, though. Thanks for helping test! |
|
|
|
Does anyone here believe this? Are people who believe this also opposed to subsidies for bitcoin businesses?
Why limit it to bitcoin businesses? Somebody should create a website where you can get a few bitcoins for free, to subsidize adoption.
You mean give a significant amount of bitcoins to the 'important' businesses? Who decides which are 'important' ? How do you make sure somebody isn't creating fake businesses just to get free bitcoins ? If you want to subsidize bitcoin businesses and have answers to those questions, then I heartily encourage you to go for it! |
|
|
|
Just tried testing 0.5.0 on Linux64.. Here's the result:
I don't have a Linux64-with-GUI machine available to try to debug this, and I've failed to reproduce it on an Ubuntu 10.10 'maverick' server. If you can, please test (and, if you can, help debug) on 64-bit Linux. This is the last issue holding up the release. |
|
|
|
I accidentally sent some bitcoins to a testnet address from MtGOX.
First: sounds like a bug in Mt Gox's bitcoin address validation code that they should fix. Second: Do you own the testnet wallet with that address in it? If you do, then it is possible to transfer the public/private keypair from your testnet wallet to your main wallet and recover the coins (but you'll need to use PyWallet or one of sipa's export/import private keys bitcoin branches). Because the coins are recoverable, you shouldn't expect Mt. Gox to refund the transaction... (otherwise everybody could create testnet versions of their main-net bitcoin addresses, withdraw, and then as Mt Gox to "refund" their "mistake") |
|
|
|
|
If I recall correctly, the courts have ruled that "commercial speech" is not as protected-- so laws that restrict (for example) cigarette ads on television are OK.
Bitcoin transactions would, I think, be very likely to be classified by the courts as non-protected speech, if they were classified as 'speech' at all.
|
|
|
|
|
The hosts of Free Talk Live know quite a lot about Bitcoin-- I had lunch with them last year (there's a thread in here somewhere about that....).
RE: "don't emphasize the potential illegal uses" -- mmmm. Last I heard, Ian was enthusiastic about the Silk Road, so I'd expect it to be part of the conversation.
And I think one of the people associated with the show (I'm being vague because I don't want to reveal something they don't want revealed) lost some bitcoins when MyBitcoin went away, so I'd expect security/trust issues to be raised, too.
|
|
|
|
Updated to release candidate 6: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/test/ https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/test/Two changes were made between rc5 and 6: 1) When you encrypt your wallet for the first time, a new keypool is created before Bitcoin-Qt/bitcoind shuts down. This prevents losing bitcoins if you backed up your newly-encrypted wallet, received coins to new addresses, and then later restored from the backup. There is still a potential problem when you upgrade a previously-encrypted wallet: in that case, the wallet file is rewritten on startup and will be left with an empty keypool (new keys cannot be written because in this case the code doesn't have your wallet passphrase). The release notes suggest backing up the re-encrypted wallet after generating a new address. 2) Be less aggressive about deleting the database/log.* file(s) on shutdown -- with rc6, they are only deleted if the wallet is successfully encrypted/re-encrypted (to make sure unencrypted private keys are not left in them). Please report only show-stopper bugs in this thread-- normal bug reports or feature suggestions should go into the github issue tracker: https://github.com/bitcoin/bitcoin/issuesPlease DO add to this thread if you've done some testing, giving what you tested (0.4.1? 0.5.0 ? win32 exe ? zip ? linux ?), what operating system you tested on, and if you were testing a fresh install or upgrading (and if upgrading, was your wallet encrypted before?). |
|
|
|
Damn, I need one of these but was leaning to the EB1020 because of its HDMI out. This only has VGA right?
Yes, VGA out. |
|
|
|
I had grand plans to make this the center of a Linux-powered multimedia center... but after doing nothing with it for a couple of months I think I just won't ever have the time.  This is an Intel Atom D410 -powered little computer, with 1GB of memory and a 250GB hard disk, running a custom version of Linux (easily upgraded to the latest Ubuntu or other Linux distro by booting from a USB stick, though). Like new in the original box with all the original parts (keyboard, mouse, stand, power cable). New at Amazon: $229Selling for 90 BTC, I'll pay shipping to the US or Canada. |
|
|
|
|
D'oh! I was running a -testnet bitcoind....
Never mind.
|
|
|
|
Neither of those addresses are valid according to my bitcoind: $ bitcoind validateaddress 1AYSPTVt8WytG12Kz9guUpXjwAMFZG9CJh
{
"isvalid" : false
}
$ bitcoind validateaddress 1AYSPTVt8WytG12Kz9guUpXjeAMFb7AX2K
{
"isvalid" : false
}
The checksum in addresses is 4 bytes, so there is a one-in-four-billion chance that a random typo would get you a valid address. |
|
|
|
bitcoind follows the JSON-RPC-over-HTTP spec for reporting errors, but it sounds like Sergio's library follows a different spec. You're not the first person to complain that bitcoind returns HTTP error codes; here's a one-line patch to change that behavior with a "-rpcerrorstatus=200" argument/option: diff --git a/src/bitcoinrpc.cpp b/src/bitcoinrpc.cpp
index 31ef725..447b55c 100644
--- a/src/bitcoinrpc.cpp
+++ b/src/bitcoinrpc.cpp
@@ -2088,6 +2088,9 @@ void ErrorReply(std::ostream& stream, const Object& objError, const Value& id)
if (code == -32600) nStatus = 400;
else if (code == -32601) nStatus = 404;
string strReply = JSONRPCReply(Value::null, objError, id);
+
+ // Allow overriding the HTTP status response:
+ nStatus = GetArg("-rpcerrorstatus", nStatus);
stream << HTTPReply(nStatus, strReply) << std::flush;
}
Let me know if that solves the problem and/or if it causes any other issues; if it doesn't, I'll submit it as a PULL request. |
|
|
|
The SHA1SUMS.asc file in the 0.5 folder only has the hashes for the 0.4.1 rc files.
Fixed, thanks for finding it. |
|
|
|
I have upgraded to RC5 0.5 XP SP 3. I have encrypted the wallet. How do I know if it worked for sure?
To be absolutely sure, you need to extract your private keys and then run a tool to look for them in your wallet.dat file (or other files on your disk). If you are able to compile a custom version of bitcoin and run python, here's how: https://gist.github.com/1361001If you can't compile a custom version of bitcoin or run python code, then you'll have to trust other people to thoroughly test. |
|
|
|
|
Show Posts
