 Show Posts
|
|
Pages: [1] 2 3 »
|
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 build for this is version 0.3.19. - Added some DoS controls As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count. I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it. - Removed "safe mode" alerts "safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. 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. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain. Builds: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/ |
|
|
|
|
Some sample pseudocode using the new Accounts based commands in 0.3.18.
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)
// if you make a sale, move the money from their account to your "" account
if (move(username, "", amount, 6, "purchased item"))
SendTheGoods()
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")
You can use listtransactions(username) to show them a list of their recent transactions.
|
|
|
|
Version 0.3.17 is now available. Changes: - new getwork, thanks m0mchil - added transaction fee setting in UI options menu - free transaction limits - sendtoaddress returns transaction id instead of "sent" - getaccountaddress <account> 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. The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first. Downloads: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/ |
|
|
|
|
I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601)
m0mchil's external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.
The interface has a few changes:
getwork [data]
If [data] is not specified, returns formatted hash data to work on:
"midstate" : precomputed hash state after hashing the first half of the data
"data" : block data
"hash1" : formatted hash buffer for second hash
"target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed.
Notes:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of "ThreadRPCServer method=getwork" is disabled, it would be too much junk in the log.
|
|
|
|
|
Version 0.3.15 is now available.
Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo
|
|
|
|
|
SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.
For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don't go crazy with it. Disk space is about 1K per key.
I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.
I've only tested this moderately. You might not want to use this for a website server until it's had some more testing.
|
|
|
|
Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. 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. Changes: - Don't count or spend payments until they have 1 confirmation. - Internal version number from 312 to 31300. - Only accept transactions sent by IP address if -allowreceivebyip is specified. - Dropped DB_PRIVATE Berkeley DB flag. - Fix problem sending the last cent with sub-cent fractional change. - Auto-detect whether to use 128-bit 4-way SSE2 on Linux. Gavin Andresen: - Option -rpcallowip= to accept json-rpc connections from another machine. - Clean shutdown on SIGTERM on Linux. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/(Thanks Laszlo for the Mac OSX build!) Note: The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right: http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gzYou can still control the SSE2 use manually with -4way and -4way=0. 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. Here's a Windows build of it: http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe |
|
|
|
0.3.13 release candidate, to be released soon so please test: http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe- don't count or spend payments until they have 1 confirmation http://bitcointalk.org/index.php?topic=1306.0- internal version number from 312 to 31300 - only accept transactions sent by IP address if -allowreceivebyip is specified - dropped DB_PRIVATE Berkeley DB flag - fix problem sending the last cent with sub-cent fractional change - auto-detect whether to use 128-bit 4-way SSE2 on Linux Gavin Andresen: - option -rpcallowip= to accept json-rpc connections from another machine - clean shutdown on SIGTERM on Linux |
|
|
|
|
In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.
|
|
|
|
SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2. It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw. Here's what I ended up with: // We need Intel Nehalem or AMD K10 or better for 128bit SSE2
// Nehalem = i3/i5/i7 and some Xeon
// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
// Intel Core i5 family 6, model 26 or 30
// Intel Core i7 family 6, model 26 or 30
// Intel Core i3 family 6, model 37
// AMD Phenom family 16, model 10
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs. If it's wrong, you can still override it with -4way or -4way=0. It prints what it finds in debug.log. Search on CPUID. This is only enabled if built with GCC. |
|
|
|
Version 0.3.12 is now available. Features: - json-rpc errors return a more standard error object. (thanks to Gavin Andresen) - json-rpc command line returns exit codes. - json-rpc "backupwallet" command. - Recovers and continues if an exception is caused by a message you received. 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. 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 {"code":<number>,"message":<string>}, which is the standard. See this thread: http://bitcointalk.org/index.php?topic=969.0Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/ |
|
|
|
Version 0.3.11 is now available. Changes: - Some blk*.dat checking on load - Built the -4way code with -march=amdfam10, which makes it a little faster - Warning if your clock is too far off - Warnings/errors/alerts can also be seen in the getinfo command - Alert system The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update. In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade: sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them. This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information. Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/ |
|
|
|
|
I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have.
Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.
In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade. Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.
The json-rpc methods that return errors during an alert are:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
|
|
|
|
|
I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list:
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up proper.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
|
|
|
|
|
SVN rev 139 does a basic check of the block chain after loading.
With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time.
It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number.
|
|
|
|
I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1: "0 connections 0 blocks 0 transactions" It's always been "nBestHeight + 1" because it's counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't not have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded. The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11. It would reduce the confusion we had here: ... It already is on block 74638. I assume that means that block is now a good one?
I had some confusion on this myself and got clarification in #bitcoin-dev: The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one. |
|
|
|
Version 0.3.10 patches the block 74638 overflow bug. http://bitcointalk.org/index.php?topic=823The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the "-4way" switch to enable it and check if it's faster for you. Download from sourceforge: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain. |
|
|
|
0.3.10 has tcatm's 4-way SSE2 as an option switch. Use the switch "-4way" to turn it on. Without the switch you get Crypto++ ASM SHA-256. I could only get this working with Linux. Download: Get 0.3.10 from http://bitcointalk.org/index.php?topic=827.0Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs. |
|
|
|
|
