But bitcoind is 0.3.20.0 0 and requires MSVC libraries.  Did I put the wrong bitcoin d.exe in the Windows exe and/or zip? D'oh! Companies I've worked for in the past had a rule-- programmers were not allowed to test their own code. I'm still looking for people to volunteer to be dedicated quality assurance testers (and a quality assurance manager to organize them) to help keep this type of thing from slipping through. |
|
|
|
First: the bitcoin.org homepage links will be updated as soon as sirius has a chance to wake up, read his email, and make the changes. Thank you for new release! I have two little questions:
- Windows build use little different skin than previous version. Is this a mistake or intention? Nothing which I really care about, I just noticed.
- Is there a reason why "bitcoin.exe -datadir=c:\bitcoin2 -nolisten" don't start second client instance?
A different skin for the Windows build is from upgrading the wxWidgets used to build (2.9.1 instead of 2.9.0). Did anybody test the -nolisten with the GUI bitcoin on Windows? I believe there is windows-specific code for checking to see if another bitcoin is running that looks at window titles; file an issue at github if -nolisten isn't doing what you expect. |
|
|
|
Binaries for Bitcoin version 0.3.20.01 are available at: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/There were several changes and additions to the JSON remote-procedure-call interface; there are no significant user interface changes. See: http://bitcointalk.org/index.php?topic=3473.msg48839#msg48839... for details. This version does fix one significant denial-of-service attack (earlier versions of bitcoin could be caused to crash due to running out of memory by a remote attacker). SHA1-checksums for the binary files are: bitcoin-0.3.20-linux.tar.gz 7dfbc05b36112f59886a29f044cfd21c6c253169 bitcoin-0.3.20-win32-setup.exe 2a4affd92dd11e0b759f90a8fa4bead58bdbf7b4 bitcoin-0.3.20-win32.zip 7bf306554092e742d076d4157aaa077d95de6102 bitcoin-0.3.20-macosx.zip 47ca28454e7ea0b576b80905353d1cea024e53fe |
|
|
|
|
Oops, sorry-- I forgot to change the admin password. The correct pw for that instance is:
penguinsrule
I change the password to match the MinGW VM and updated the AMI:
ami-d621d2bf 982440761210/BitcoinVC10
Admin password: bitcoin development
You should change the password as soon as you login or make sure you use a security group that only allows your IP address to access the virtual machine.
|
|
|
|
So can we count on this that current TBTC (test bitcoins) will NOT be reseted?  No. You should expect the testnet to be reset, if for no other reason than to keep people from using it as a "real" currency. |
|
|
|
As I said I think an ideal solution would be having an official miner as a separate application, where you could chose between what miner you want to use (miners would be included in the installation package).
Good idea. Patches welcome, as long as they're nice and stable and have had a fair bit of testing... |
|
|
|
Bounty for the 50 coins. The first person to get a patch merged by Gavin into the core software that allows import/export of wallet files, via the GUI on all 3 supported platforms, defined in the following manner wins the coins. Obviously not very much but I guess it's symbolic  The format should be a CSV file (unix line endings) that looks like this: base58 encoded privkey,block number,block number....
base58 encoded privkey,block number,block number....
base58 encoded privkey,block number,block number....
where the block numbers are the blocks in which there are unspent outputs sending to that key. CSV file with the private key and block numbers is a good idea, although for it to be a valid CSV file then it needs to have a fixed number of columns. I'd modify the design slightly to be just: base58 encoded privkey,block number ... where block number is the block number of the earliest input (that'll save rescanning time-- you probably always want to rescan from the earliest block number, anyway, in case more payments were sent after you exported the key). Also what do you mean by "export" -- write and then remove the keys from the wallet? Write a newly generated key and generate a payment-to-that-key for a given amount of coins? I think any code that removes keys from the wallet (or generates payments to keys that are never added to the wallet) needs to be structured as two distinct steps: 1. Write the keys to <destination> 2. Read <destination> to make sure it is valid, and, if it is, delete the corresponding keys from the wallet (or generate the send-to-self txn). |
|
|
|
|
Here's the public AMI for the dodgy 0.3.20 VC10 build:
ami-d621d2bf 982440761210/BitcoinVC10
Bitcoin source is at c:\bitcoin
(all the other dependencies are in the root c:\, too).
Administrator password is: bitcoin development
|
|
|
|
Gavin, do you have / can you make public the image for the dodgy 0.3.20 VC10 build? I'd like to have a look and compare it to my home build to see if I can reproduce that rendering artifact problem. Thanks.
Yes, I have the VC10 VM. I am hesitant to make it publicly available because it has a copy of Visual C++ 2010 Express installed, and I don't want Microsoft to sue me for redistributing their software without permission. I'll uninstall it from the VM and then make the image public; you'll have to download and install (and agree to the license) Visual Studio Express yourself to get it working. |
|
|
|
|
Can you post examples of requests/responses with the "old" JSON-RPC and your new JSON-RPC?
I'm still firmly against this change-- it seems to me you are "solving" a non-problem.
|
|
|
|
A lot of coulds there...what is stopping this from happening?
There are approximately 2 160 things higher on the development priority list. |
|
|
|
A committed individual or organization could easily aquire network storage in the Petabytes. I think that would be more than enough to get a sizable operation started.
1 petabyte is 10 15 bytes. There are 2 160 possible BTC addresses, each of which is 160 bits == 20 bytes long. So to store all of them you need 2 160x20 bytes, which is 29,230,032,746,618,058,364,073,696,654,325,660 petabytes. |
|
|
|
Gavin, is this windows/mingw build environment publicly available?
Yes, it is public Amazon ami-2edd2e47 named 982440761210/BitcoinMinGW The linux32 and linux64 amis I used to build the linux releases are also public. |
|
|
|
Appears to work well, but i still get the wxWidgets debug alert on Win7x64
Did you get a debug alert with bitcoin 0.3.19 or earlier? And could you post a screen snapshot (or, even better, file an issue at https://github.com/bitcoin/bitcoin/issues )? |
|
|
|
|
Frankly, I'm not sure how I feel about this.
I absolutely positively want more scrutiny of both bitcoin's source code and the underlying cryptographic concepts.
However, I don't think offering a token amount of money (even in the form of bitcoins) is appropriate.
A real, professional security review of bitcoin would take a lot of time and a lot of money. I understand that's not what is being asked, but asking Mr. Schneier to write about bitcoin is really an irrational "Appeal to Authority" -- I think he'd say that any cryptography-related technology is never proven secure, but only gains trust by having multiple people and groups of people look at it, imagine potential attacks, try to attack it, etc.
Or, in other words, if he writes an article about bitcoin now I think the summary would be "interesting new technology, doesn't appear to be a scam, worth keeping an eye on." I think he'll write that article soon without any prompting from "the bitcoin community," just given the level of buzz bitcoin is generating the last month or two. I don't think a few hundred bitcoins will motivate him to write the article any sooner.
|
|
|
|
|
The only thing stopping me from announcing 0.3.20 "Final!" is confirmation from Windows users that switching to the mingw build process fixed the rendering issues.
So: if you're a Windows bitcoin user, please install the latest 0.3.20 from SourceForge and let me know how it works for you.
|
|
|
|
Has anyone successfully generated a block while using this?
I've generated lots of blocks on the new -testnet. |
|
|
|
|
I've made public the windows, linux32 and linux64 Amazon Machine Images used to build bitcoin 0.3.20. If you have an Amazon EC2 account, you can launch them and have your own working build environment for linux or windows bitcoin (paid for by the hour).
They are:
ami-4adf2c23 32-bit Linux (Ubuntu 9.04)
ami-12df2c7b 64-bit Linux (Ubuntu 9.04)
ami-7a21d213 Windows (with MinGW)
All created in the us-east-1b zone (I don't know if Amazon automatically migrates public AMIs across the world).
After launching the Linux VMs, you login as root (using the ssh keypair you specify when you launch).
After launching the Windows VM, you connect via Remote Desktop and then login as Administrator, password "bitcoin development" (you should change that for your instance as soon as you login, of course).
They contain bitcoin, bitcoind, and everything needed to build them, already built. You could launch instances and try to generate coins, but that's not cost-effective.
(Updated 22 Feb with 0.3.20.01 Windows AMI)
|
|
|
|
|
I just committed (to git and svn) an updated build-msw.txt
Thanks to m0mchil for putting together a working windows/mingw build environment.
And I'll be making the 0.3.20 build environment virtual machines (for Windows, Linux32, and Linux64, in the Amazon EC2 cloud) public, hopefully, if all goes well, later today.
|
|
|
|
|
Show Posts
