Show Posts
|
Pages: « 1 [2] 3 »
|
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
|
|
|
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?
|
|
|
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.
|
|
|
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. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/
|
|
|
It would be neat if someone had a page (like that handy calculator at http://www.alloscomp.com/bitcoin/calculator.php) 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.
|
|
|
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. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
|
|
|
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.
|
|
|
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
|
|
|
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: http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gzThese 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.
|
|
|
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 127.0.0.1, 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.
Update: The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
|
|
|
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) Sleep(50); 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>
|
|
|
Download links available now on bitcoin.org. 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.
|
|
|
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.
vekja.net is an example of a site like this.
|
|
|
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 bitcoin.org
Changes: - Added Portuguese translation by Tiago Faria Windows - Fix for 22DbRunRecoveryException if your username has non-ascii characters in it Linux - 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
|
|
|
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 http://www.bitcoin.org or read the forum to find out more.
|
|
|
Is it about time we lose the Beta? I would make this release version 1.3.
|
|
|
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.
|
|
|
|