You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. Support for full-precision bitcoin amounts. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the -upnp=1 command line switch or using the Options dialog box. If you find bugs, please open an issue at:īinaries for Bitcoin version 0.3.21 are available at:Ĭhanges and new features from the 0.3.20 release include: This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. …and several improvements to –help output.-rescan : scan block chain for missing wallet transactions.Please checkout the git integration branch from: If you have already downloaded version 0.3.20.1, please either add this to your nf file: The Amazon Machine Images I used to do the builds are available:Īmi-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows Administrator password ‘bitcoin development’) Worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday. The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get Never released or release notes were lost. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain. It was never intended as a long term feature. We can say all we want that users can just run with “-disablesafemode”, but it’s better just not to have it for the sake of appearances. “safe mode” alerts was a temporary measure after the 0.3.9 overflow bug. I’m leaving the -limitfreerelay part as a switch for now and it’s there if you need it. This is one improvement, but there are still more ways to attack than I can count. The build for this is version 0.3.19.Īs Gavin and I have said clearly before, the software is not at all resistant to DoS attack. There’s more work to do on DoS, but I’m doing a quick build of what I have so far in case it’s needed, before venturing into more complex ideas. The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin’s been working on (more details at ). * Jgarzik’s optimisation to speed up the initial block download a little * IsStandard() check to only include known transaction types in blocks * Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again We still have some more changes to make first. The accounts-based commands: move, sendfrom and getbalance will be in the next release. The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it. * sendtoaddress returns transaction id instead of “sent” * added transaction fee setting in UI options menu testnet, keypoololdest and paytxfee added to getinfo.make sure generation doesn’t start before block 74000 downloaded.BitcoinMiner processes transactions in priority order based on age of dependencies.sending avoids using coins with less than 6 confirmations if it can.paytxfee switch is now per KB, so it adds the correct fee for large transactions.* Option to use SSL for JSON-RPC connections on unix/osx * Key pool feature for safer wallet backup Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent.
You can still control the SSE2 use manually with -4way and -4way=0. Please try this instead and let me know if it gets it right: The SSE2 auto-detect in the Linux 64-bit version doesn’t work with AMD in 64-bit mode. * Option -rpcallowip= to accept json-rpc connections from another machine.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux. * Fix problem sending the last cent with sub-cent fractional change. * Only accept transactions sent by IP address if -allowreceivebyip is specified. * Internal version number from 312 to 31300. * Don’t count or spend payments until they have 1 confirmation. Note: 0.3.13 prevents problems if you haven’t already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2. You should upgrade to prevent potential problems with 0/unconfirmed transactions. If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form, which is the standard. Other nodes shouldn’t be able to cause an exception, and it hasn’t happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes. * Recovers and continues if an exception is caused by a message you received. * json-rpc command line returns exit codes. * json-rpc errors return a more standard error object.
0 kommentar(er)
