Bitcoin Forum
September 26, 2022, 07:01:22 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 »
21  Bitcoin / Development & Technical Discussion / Version 0.3.9 rc1, please test on: August 13, 2010, 05:40:00 PM
Here's a test build if you'd like to help test before 0.3.9 is released.
(or if you'd rather get upgrading out of the way now instead of waiting)

Downloads:  (binaries only)

SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e
SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz

Linux please test rc2 instead.  This adds a -4way switch for tcatm's 4-way SSE2.  This will only be for Linux:

SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz

Please report back your results
22  Bitcoin / Development & Technical Discussion / Bugfixes in SVN rev 130 on: August 12, 2010, 09:20:31 PM
Misc bugfixes in rev 130:

fix -datadir with relative path
autostart is now off by default except on windows
fix occasional "vector iterator not dereferencable" assertion when compiled with msvc
fix readlink compile warning on linux build
use sys/param.h and BSD define instead of __BSD__
-paytxfee switch, e.g. -paytxfee=0.01
23  Bitcoin / Development & Technical Discussion / Connection limits on: August 09, 2010, 08:58:45 PM
SVN rev 125:
- Always make 8 outbound connections even if have 8 inbound
- Limit outbound connections to one per a.b.?.? range
- Switch -maxconnections=#

I added the (currently undocumented) switch -maxconnections=#.  You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.

I haven't really tested -maxconnections much, could someone test it?
24  Bitcoin / Bitcoin Discussion / Version update for Linux 64-bit on: August 09, 2010, 07:46:58 PM
When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build.  Version is on SourceForge with the 64-bit binary updated.


Future versions after 0.3.8 will probably require SSE2.  Anyone have Pentium 3 or older where this would be a problem?
25  Bitcoin / Development & Technical Discussion / Escrow on: August 07, 2010, 08:13:52 PM
Here's an outline of the kind of escrow transaction that's possible in software.  This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.

While this system does not guarantee the parties against loss, it takes the profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
26  Bitcoin / Bitcoin Discussion / Please upgrade to 0.3.8! on: August 03, 2010, 11:40:18 PM
Version 0.3.8 adds an important security improvement.  Everyone should upgrade to get this change.

The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.

If it sees a longer chain, but it can't process it, then it knows something is wrong.  It displays "WARNING: Displayed transactions may not be correct!  You may need to upgrade." and makes most RPC commands return an error.  It still keeps generating as normal, which is necessary for the stability of the network.

There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!

Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.

27  Bitcoin / Development & Technical Discussion / Webpage idea: Next predicted difficulty change on: July 31, 2010, 01:32:08 AM
It would be neat if someone had a page (like that handy calculator at that projects what the next difficulty adjustment will be.

projected difficulty adjustment multiplier =

 blocks_since_last_adjustment / 2016
 time_since_last_adjustment / 14_days

For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:

 (1008/2016) / (3.5/14) = 0.5/0.25 = 2.0

Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.
28  Bitcoin / Bitcoin Discussion / *** ALERT *** Upgrade to 0.3.6 on: July 29, 2010, 07:13:06 PM
Please upgrade to 0.3.6 ASAP!  We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted.  Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6!

If you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.

Also in 0.3.6, faster hashing:
- midstate cache optimisation thanks to tcatm
- Crypto++ ASM SHA-256 thanks to BlackEye
Total generating speedup 2.4x faster.


Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
29  Bitcoin / Development & Technical Discussion / bitcoind without wxWidgets on: July 26, 2010, 05:23:33 PM
I replaced the last of the few wxBase dependencies in bitcoind.

bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.

main(int argc, char* argv[]) is added to init.cpp.  CMyApp and the Startup folder stuff are moved to ui.cpp.  ui.cpp and uibase.cpp aren't linked by bitcoind.

The makefiles have -DGUI to control whether the GUI is used.

I test compiled MinGW, VC and Ubuntu.  I don't know if I broke the Mac OSX build, someone will need to check that.
30  Bitcoin / Bitcoin Discussion / Bitcoin 0.3.3 released -- PLEASE UPGRADE on: July 25, 2010, 04:55:09 PM
Please upgrade to 0.3.3!  Important security improvements were made in 0.3.2 and 0.3.3.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
31  Bitcoin / Bitcoin Discussion / Version -- please test! on: July 24, 2010, 03:32:52 AM
Please test in preparation for the 0.3.3 release!  This build is looking good and should be the one that goes into 0.3.3.  I encourage you to go ahead and upgrade now if you're on Windows or Linux.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes

Download here:

32  Bitcoin / Development & Technical Discussion / Faster initial block download (5x faster) on: July 23, 2010, 06:24:56 PM
By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster.  It downloads in about 30 minutes.

The database default had it writing each block to disk synchronously, which is not necessary.  I changed the settings to let it cache the changes in memory and write them out in a batch.  Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.

I only enabled this change during the initial block download.  When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.

I built a test build if you'd like to start using it:

These binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.

I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.

There are no changes to the way it handles wallet.dat.  This change is only for blk*.dat and the non-critical addr.dat.  You can always delete blk*.dat if it gets screwed up and let it re-download.
33  Bitcoin / Bitcoin Discussion / Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower) on: July 19, 2010, 04:01:38 PM
Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser.  It opens port 8332 on, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.

We're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.

The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
34  Bitcoin / Development & Technical Discussion / JSON-RPC password on: July 18, 2010, 08:49:22 PM
I uploaded to SVN my changes to add a password to JSON-RPC.  If you're set up to build, please test it.

The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password>    -- runs with JSON-RPC port open
bitcoind -rpcpw=<password>   -- daemon with password

If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too.  I'm not sure but I think they may want to use different passwords for the two.

It gives a warning if you don't set a password.

All commands now require the password as the first parameter.  It'll tell you that if you run "bitcoind help".

The central code:

  // Check password
  if (params.size() < 1 || params[0].type() != str_type)
      throw runtime_error("First parameter must be the password.");
  if (params[0].get_str() != strRPCPassword)
      if (strRPCPassword.size() < 15)
      begin = strRequest.end();
      printf("ThreadRPCServer incorrect password attempt\n");
      throw runtime_error("Incorrect password.");

Any comments on these decisions?

1) if (strRPCPassword.size() < 15) Sleep(50);  -- this means if it's a short password, it'll wait 50ms after each attempt.  This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan.  This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15.  If you want to close the DoS possibility, just use a password 15 characters or longer.

2) begin = strRequest.end();  -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password.  This is so you can't stuff it with millions of password attempts in one packet.  What do you think, is this the right thing to do?  (multiple invocation is probably almost never used anyway)

I also fixed the two duplicated commands listed in the help:

getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>
35  Bitcoin / Development & Technical Discussion / Bitcoin 0.3.2 released on: July 17, 2010, 09:35:51 PM
Download links available now on  Everyone should upgrade to this version.

- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.

The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday.  (if you have this update)

I'll probably put a checkpoint in each version from now on.  Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.
36  Bitcoin / Development & Technical Discussion / Sample account system using JSON-RPC needed on: July 16, 2010, 07:45:10 PM
We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system.  Most sites that sell things will need something like this.  Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.

When a user is logged in to their account, you show the bitcoin address they can send to to add funds.  Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>).  You only need to keep the latest bitcoin address for the account in your database.  (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)

You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account.  You need to keep a "debit" amount in your database.  The current balance of the account is (credit - debit).  When the user spends money, you increase debit.

If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged.  Not all sites need to wait for confirmations, so the dual current & available should be optional.  Most sites selling digital goods are fine to accept 0 confirmations.

A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address.  The sample code should be the simplest possible with the minimum extra stuff to make it a working site. is an example of a site like this.
37  Bitcoin / Development & Technical Discussion / Bitcoin 0.3.1 released on: July 15, 2010, 05:05:54 PM
This is a bugfix maintenance release.  It is now uploaded to SourceForge.  Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.

The download links are on

- Added Portuguese translation by Tiago Faria
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option
38  Bitcoin / Bitcoin Discussion / Bitcoin 0.3 released! on: July 06, 2010, 06:32:35 PM
Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.  Escape the arbitrary inflation risk of centrally managed currencies!  Bitcoin's total circulation is limited to 21 million coins.  The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.

What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero)

Get it at or read the forum to find out more.
39  Bitcoin / Development & Technical Discussion / Beta? on: June 26, 2010, 05:02:43 PM
Is it about time we lose the Beta?  I would make this release version 1.3.
40  Bitcoin / Development & Technical Discussion / 0.3 almost ready -- please test the Mac version! on: June 22, 2010, 04:01:53 AM
I finished everything on my list to do for version 0.3.  The code on SVN is about ready to release.

Testing at this point is much appreciated.
Pages: « 1 [2] 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!