analyze this text- 
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:
It would have been nice to get this attention in any other context.  WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.
That means a lot coming from you, Hal.  Thanks.
If you ever find anyone who turned it on.  It's disabled by default.
It's all STL.  There are almost no buffers.
@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS.  And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.
Avoiding CPU power fragmentation is no longer a reason.  Independent networks/chains can share CPU power without sharing much else.  See:
I agree.  All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.
You might consider a certain amount of work to generate a domain, instead of a fixed total circulation.  The work per domain could be on a schedule that grows with Moore's Law.  That way the number of domains would grow with demand and the number of people using it.
Right, the exchange rate between domains and bitcoins would float.
A longer interval than 10 minutes would be appropriate for BitDNS.
So far in this discussion there's already a lot of housekeeping data required.  It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain.  Some transactions:
Changing the IP record.
Name change.  A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken.  This would encourage users to free up names they don't want anymore.  Generated domains start out blank and the miner sells it to someone who changes it to what they want.
Renewal.  Could be free, or maybe require consuming another domain object to renew.  In that case, domain objects (domaincoins?) could represent the right to own a domain for a year.  The spent fee goes to the miners in the next block fee.
Some sample pseudocode using the new Accounts based commands in 0.3.18.
// if you make a sale, move the money from their account to your "" account
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")
You can use listtransactions(username) to show them a list of their recent transactions.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.
If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.
Not locktime.
There's a possible design for far in the future:
You intentionally write a double-spend.  You write it with the same inputs and outputs, but this time with a fee.  When your double-spend gets into a block, the first spend becomes invalid.  The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
It's easier said than implemented.  There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases.  Every assumption in the existing code is that you're not trying to write double-spends.
There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher.  Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
The incentive is to get the rewards from the extra side chains also for the same work.
While you are generating bitcoins, why not also get free domain names for the
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
You have one piece of work.  If you solve it, it will solve a block from both Bitcoin and BitDNS.  In concept, they're tied together by a Merkle Tree.  To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal.  You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility.  We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.
Note that the chains are below this new Merkle Tree.  That is, each of Bitcoin and BitDNS have their own chain links inside their blocks.  This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain.  This is two timestamp servers not sharing a chain.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other's total CPU power.  This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one.  Instead, all networks in the world would share combined CPU power, increasing the total strength.  It would make it easier for small networks to get started by tapping into a ready base of miners.
Thanks for setting this up Cdecker.
Is there any chance of getting it to build the GUI version also?  If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly.  Is this an environment where you can build wxWidgets once and leave it there and just keep using it?
As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.
Gavin, could listtransactions have an option to list transactions for all accounts?
I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]
It would be hard to do that from the command line though.
I can't think of a good solution for the interface, that's the problem.  Maybe "*" special case like "" is.  Everyone would have to make sure no user can create account name "*".
I don't get how that's "easy" to track with transactions.
I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.
That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.
New transaction templates can be added as needed.  Within a few days, there will be plenty of GPU power that accepts and works on it.  Network support will be thorough
there'll be enough clients who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible:
If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.
I like Hal Finney's idea for user-friendly timestamping.  Convert the hash of a file to a bitcoin address and send 0.01 to it:
I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case.  It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
Suppose both spends are to the same address.  getreceivedbyaddress would always count only one or the other spend at any given time, never both.
Using listtransactions, it would be very easy to count both.  You see the first spend, you count it.  You see the second spend, you count it.  Total is double counted.
The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at
Then how do you cope with the issues I listed in the message you quoted?
It's not safe to use listtransactions this way.
I know I've been criticized for being reluctant about listtransactions.  Let me explain my reluctance.
Transactions are dynamic.  Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.  Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them.  This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.
The model where you assume you only need to see new transactions because you've already seen previous transactions is not true.  Old transactions can change at any time.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.
No, don't "bring it on".
The project needs to grow gradually so the software can be strengthened along the way.
I make this appeal to WikiLeaks not to try to use Bitcoin.  Bitcoin is a small beta community in its infancy.  You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.
That's a good optimisation.  I'll add that next time I update SVN.
More generally, we could also consider this:
We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.
What was this wallet used with?  An early accounts patch or git build?
It's while loading the wallet.  I assume it must be in this:
You could check that with this:
Was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key?
If you have gdb, you could run it in gdb and do a backtrace.
It seems like you're inclined to assume everything is wrong more than is actually so.
Writing the block index is light work.  Building the tx index is much more random access per block.  I suspect reading all the prev txins is what's slow.  Read caching would help that.  It's best if the DB does that.  Maybe it has a setting for how much cache memory to use.
Already does that.  See CDB.  The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.
If it was doing that it would be much slower.  It's supposed to be only once a minute or 500 blocks:
Probably should add this:
Does transaction commit imply flush?  That seems surprising to me.  I assume a database op wrapped in a transaction would be logged like any other database op.  Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b)  I can't imagine they're required to batch all their stuff up themselves.
In the following cases, would case 1 flush once and case 2 flush twice?
Contorting our database usage will not be the right approach.  It's going to be BDB settings and caching.
Very much not.  Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that.  Both copies will get screwed up.
If you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems.  jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).
New demonstration CPU miner available:
Despite everything else said, the current next step is:
In particular, I suspect that more read caching might help a lot.
Then something more specific was wrong.  That's not due to normal initial download time.  Without more details, it can't be diagnosed.  If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source?  debug.log might have clues.  How fast is their Internet connection?  Was it steadily slow, or just slow down at one point?
The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000.  -checkblocks does more, but is still easily defeated.  You still must trust the supplier of the zipfile.
If there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.
80 bytes per header and no indexing work.  Might take 1 minute.
The data is mostly hashes and keys and signatures that are uncompressible.
The speed of initial download is not a reflection of the bulk data transfer rate of the protocol.  The gating factor is the indexing while it downloads.
ribuck's description is spot on.
Pool operators can modify their getwork to take one additional parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone
That would be easier and safer to start up.  It also has the advantage that multiple hits from the same user can be combined into one transaction.  A lot of your hits will usually be from the same people.
The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.
Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.
New users wouldn't really even need the Bitcoin software.  They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server.  When the miner says it found something, a while later a few coins show up in their account.
Miner writers better make sure they never false-positive near-hits.  Users will depend on that to check if the pool operator is cheating them.  If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.
You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp.  It compiles fine as a C file, just rename sha256.cpp to sha256.c.  I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin.  It may have a better chance of working as part of a C program instead of C++.
Currently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users.  It's about 100% speedup on AMD CPUs.
That's what it does, it returns true/false.
Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major.  I'll ask him to do this version.
I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck.  Initial download took 1 hour 20 minutes.
If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong.  It would be nice to know what appears to be the bottleneck when that happens.
Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node.  When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest.  At least, that's how it should work.
It may only need more read caching.  It has to read randomly all over blk0001.dat and blkindex.dat to index.  It can't assume the file is smaller than memory, although it currently still is.  Caching would be effective, since most dependencies are recent.
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster.  If something substantial is discovered, then we can work out the particulars.
We checkpoint every 500 blocks.
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:
It's not the downloading that takes the time, it's verifying and indexing it.
Bandwidthwise, it's more efficient than if you downloaded an archive.  Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB.  Building blkindex.dat is what causes all the disk activity.
During the block download, it only flushes the database to disk every 500 blocks.  You may see the block count pause at ??499 and ??999.  That's when it's flushing.
Doing your own verifying and indexing is the only way to be sure your index data is secure.  If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.
getwork does the byte-reversing.  midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing.  They're the same data that is passed to the ScanHash_ functions.  You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone).  If a nonce is found, patch it into data and call getwork.
I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.
target is little endian, it's supposed to be the same as how m0mchil's did it.  (if it's not, then it should be fixed)  That's the only case where you would use byte reverse.  I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].
This is the new spec.  It shouldn't be hard to update your miner to use it.
The changes are:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.
It's not an exact drop-in replacement.  I wanted to clean up the interface a little.  It only requires a few changes.
ScanHash_ functions aren't going away.  BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).
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.
Thanks m0mchil for keeping up on the updates!
GPU miners, please upgrade as soon as possible to shut down the free transaction abuse!  This version has the new priority-based limit on free transaction spam.
Before SVN 184, compiling transactions into a block used an n^2 algorithm.  The new efficient single-pass algorithm is orders of magnitude quicker.  (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)
I'm doing something like that.  Priority is a more formalised version of the concept you're describing.
Yes, like this.  And the no-priority-requirement area is 3K, about a dozen transactions per block.
I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions.  Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly.  0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.
Version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.
I think this is a good compromise short of making the default fee 0.01.  It's not so much to ask that free transactions can only be used to turn coins over so often.  If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.
We've always said free transactions may be processed more slowly.  You can help ensure your transactions go through quickly by adding -paytxfee=0.01.
We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block.  The OP_BLOCKNUMBER transaction and all its dependants would become invalid.  This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.
nTimeLock does the reverse.  It's an open transaction that can be replaced with new versions until the deadline.  It can't be recorded until it locks.  The highest version when the deadline hits gets recorded.  It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline.  The feature isn't enabled or used yet, but the support is there so it could be implemented later.
You should use at least some priority in case a flood comes along before the next block.
As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.
Or managing how much priority you spend on a transaction.  The software would have to know your future plans to know whether to spend your priority now or save it for later.  I don't think we'll need to get into that much detail though.  There's a wide enough difference between normal users and flooders.
Priority doesn't have to do everything.  Once you know there's a flood, you can add -paytxfee=0.01.  Hopefully with priority, your transactions before that should be at worst slow, not stuck.
Version 0.3.15 is now available.
Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack.  The key was Gavin's idea for prioritising transactions based on the age of their dependencies.  Every coin is entitled to turn over so often.  The longer waited, the more priority accumulates.  Priority is sum(valuein * age) / txsize.  Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left.  This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
I'm happy if someone with artistic skill wants to contribute alternatives.  The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes.  I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.
It'll be a lot simpler if authors could make their graphics public domain.
The only thing I can think of is to see if there are other versions of mingwm10.dll you can get.  mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread.  I don't know exactly what it does, but it probably just says something like "yes Windows, see I'm in a DLL like you insisted."
The end of your debug.log file might show the last thing it was doing before it crashed.
Here's some pseudocode of how you would use the account based commands.  It sure makes website integration a lot easier.
sendfrom(username, bitcoinaddress, amount, 6)
I have the beginning of something like this.  It's mostly like what Gavin described.
Some more rpc interface:
move <fromaccount> <toaccount> <amount>
Move from one internal account to another.  I think blank account name ("") will be your default account.  If you sell something to a user, you could do move "theiraccount" "" 123.45.
Is "move" the best name for this?  I shied away from "transfer" because that sounds too close to sending a transaction.
I'm thinking a new function getaccountaddress instead of overloading getnewaddress:
getaccountaddress <account>
Gives you an address allocated from getnewaddress <account>.  It'll keep giving the same address until something is received on the address, then it allocates a new address.  (It automatically does what the sample code I posted some time ago did)
Would these commands make it possible in simple cases to implement your website without needing a database of your own?
ECDSA can't encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages for everyone to see.  It would be an accident waiting to happen.
If there's going to be a message system, it should be a separate system parallel to the bitcoin network.  Messages should not be recorded in the block chain.  The messages could be signed with the bitcoin address keypairs to prove who they're from.
This is the important clue.  I believe it's saying it crashed in that.  Maybe there are other versions of it to try.  mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.
Is anyone else running OK on Windows 64-bit?
OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.
Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.
It would be instructive to get knightmb's blk*.dat and see if that gets him past that point.
He was generating invalid blocks at difficulty 1.0.  He must have a corrupted entry in his blk0001.dat or blkindex.dat file.  He just needs to delete blk*.dat and let it redownload.
The safety lockdown detected the problem and was displaying "WARNING: Displayed transactions may not be correct!" because it saw a longer chain existed that it was unable to accept.  The safety lockdown cannot stop generation or it would create an attack possibility.
Good idea, I made a change to make sure it won't generate before checkpoint block 74000.
The order matters not to the program, but it matters to me maintaining it.  If it jumbles the order of the .po file then I can't diff for changes.  I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.
I can still put it back into normal order by making poedit rescan it.
It is normal that untranslated strings are shown on top.
I know, but not easily without complicating the sourcecode.
Version 0.3.14 is now available
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.
Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism.  One good one I found was Mihalism Multi Host.  It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.
Maybe you were just unlucky to have an exit node without reverse lookup.
The IRC server's response doesn't look like it was disconnecting you for that.  It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.
I see the problem.  The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase.  I'll fix it.
I don't know if it's really required to wait for the server to finish looking up hostname before sending nick.
How long did it take to get connected with TOR the first time, having to use the seed nodes?
That's going to be more of a SelectCoins thing.
SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent.  This is needed because you should be able to spend your own change right away.
The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.
Here's a Windows build:
This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it.  If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.
poedit reorganised the file for some reason.  I re-ran update from sources and it put it back in the original order so it's fine now.  Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?
Strings aren't added or changed very often.  It's months before enough changes build up.
I uploaded the changes.
This Windows build has the Russian translation in it:
It can be phased in, like:
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
poedit does it.  Either get the src directory from a release, or download it with SVN.  Place your .po file 3 directories deep under the src directory.  Open it with poedit and do Catalog->Update from sources.
So for example, you have:
Thanks eurekafag, Russian translation added to SVN rev 160.
Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0.  It haven't seen it rebroadcast since 29/09/2010 16:41.
You're connecting to yourself.  All 21 connection attempts were to a node with version 31300 (0.3.13).  Not everyone has 0.3.13 yet.
IRC seems to be working.  It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting.  I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside.  Maybe there's something wrong in it.
Are you using -addnode?
ShadowOfHarbringer, is yours faster with -4way?
If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.
The specialbuild version I posted here looks for model 4 or higher.  If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.
This is the point of confusion.  extraNonce is not part of the block header, it is part of the first transaction.  It does not slow down your hashing.  It does not change the size of the header.
We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed.  It doesn't.
extraNonce never needs to be very big.  We could reset it every second whenever the time changes if we wanted.  Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.
Separate machines are automatically collision proof because they have different generated public keys in the first transaction.  That also goes for each thread too.
+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.
We can phase in a change later if we get closer to needing it.
Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.
Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain.  If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong.  It's a part of code that doesn't get much use.  They should be recorded in the wallets of everyone who has a transaction depending on them.
Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case?  You should never delete a wallet.
It may take a while to collect re-broadcast transactions.  It'll help if you can accept inbound connections so you'll be listening to more nodes.  Even if you find a block in 3 hours, keep it running continuously for a few days at least.
Seriously?  What hardware is that?
Could a few people please run this special build?  It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now.  We really just need one block letting them through to clear up the previous transactions.  Post if you generate a block with this.
These are binaries only.  The linux version is 64-bit only.
The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better.
Forgot to say, I suspected the detect might not work on 64-bit AMD.  I found it hard to believe but AMD reports a different model number in 64-bit mode.
Could you grep CPUID your debug.log and tell me what it says?  (and anyone else with 64-bit AMD)  And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware also?
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.
Download:
(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:
You 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:
Too late for 0.3.13, but I'll try to find time to add it to the next version.
It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.
0.3.13 RC1 is available for Windows:
True, the switch should be something more dynamic that pays per KB.  It's harder to think of how to explain it.
It ramps up the fee requirement as the block fills up:
It's a typical pricing mechanism.  After the first 50KB sells out, the price is raised to 0.01.  After 250KB is sold, it goes up to 0.02.  At some price, you can pretty much always get in if you're willing to outbid the other customers.
Just including the minimum 0.01 goes a long way.
If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.
I wish rather than deleting the article, they put a length restriction.  If something is not famous enough, there could at least be a stub article identifying what it is.  I often come across annoying red links of things that Wiki ought to at least have heard of.
The article could be as simple as something like:
"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."
The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash.  We can probably establish a paragraph there.  Again, keep it short.  Just identifying what it is.
Open bitcoin.po with poedit, do Catalog->Update from sources.  It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.
This updates your existing .po file you already worked on and adds any news strings.  It may try to match close strings, so check things over and make sure it didn't make any bad guesses.
Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things.  I'm attaching your Russian one to this message.
0.3.13 release candidate, to be released soon so please test:
- 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
0.3.13 release candidate, please test:
As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation.  0/unconfirmed transactions are very much second class citizens.  At most, they are advice that something has been received, but counting them as balance or spending them is premature.
I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending.  This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.
I didn't make it (+1.23) because parenthesis in accounting means negative.  I hope square brackets is different enough to be clear what is meant.
The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.
I uploaded the changes to SVN rev 158.  I will post a 0.3.13 RC shortly.
If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.
If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.
It's not implemented yet, but the network can support a transaction that requires two signatures.  It's described here:
It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater can't win, but it's still possible for you to lose.  It at least takes away the profit motive for cheating you.  The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
I don't think it should cause any problems for version comparisons.  31300 > 312.
I would not encourage using the extra decimal places.  They're only intended for future use.
You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it.  The UI will show it rounded down.
Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to "porn guys", or afraid of recurring billing.
I don't understand, are you under the impression that the program sets the system clock?  It doesn't.
We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour.  If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.
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.
I implemented this change in SVN rev 157.
The reason I previously made it so high was to allow very large transactions without hitting the transaction fee.  The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins.  Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level.  The new threshold puts it at around 11,000 BTC for sending generated coins.  It would mostly only be reached with generated bitcoins.  If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions.  Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.
Theymos already said this...  ECDSA does not support encrypting messages.  Only digital signatures.
Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.
In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.
In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.
I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".
Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".
I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.
I don't know anything about any of the bug trackers.  If we were to have one, we would have to make a thoroughly researched choice.
We're managing pretty well just using the forum.  I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker.  A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.
I keep a list of all unresolved bugs I've seen on the forum.  In some cases, I'm still thinking about the best design for the fix.  This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.
The lines it's tripping on:
So it's acting like nothing is defined, not even map and vector.
Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.
Is VC trying to use precompiled headers and screwing it up?  Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?
There's an installer package now that makes it really easy to install MinGW.  Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0.  A setup program completely installs everything, it's not hard like it used to be.  I think the only thing I had to do was rename make*.exe something to make.exe.
Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows.  There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault.  With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.
Bouncing between 0 and 2 connections could be if it's connecting to itself.  Are you using the "-connect" switch?
Did you compile it or is this a release build, and what version?
I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts.  How fast is it flickering between 0 and 2 connections?  Faster than twice a second?
The wait function on linux is:
If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
If the only library is closed source, then there's a project to make an open source one.
If the only library is GPL, then there's a project to make a non-GPL one.
If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.
I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS.  For smaller projects, I think the fear of a closed-source takeover is overdone.
Trying it without the DB_PRIVATE flag in rev 153.  We need to keep an eye on what's different.
On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB.  It doesn't delete them on exit, it just leaves them behind.
The docs say it uses memory mapped files.  I assume they have the same file permissions as the database files, so the same user access restrictions apply.
Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE     20 minutes 51 seconds
without DB_PRIVATE   20 minutes 51 seconds
I wasn't expecting them to come out exactly the same.
Is there a way to open BerkeleyDB exclusive?
DB_PRIVATE is the worst of both worlds.  DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.
I've dropped the DB_PRIVATE flag in rev 153.
Added in SVN rev 152
The fix is in SVN rev 151.
You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.
I think I know what happened.  Doubleclick on the generated transaction.  It probably has a sub-0.01 transaction fee in it.
Someone has been paying a 0.00000010 transaction fee.  I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it.  Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.
It would normally be harmless except in this corner case.  I should add a special case to CreateTransaction to handle this.
What version is the one where this happened?  Release build, or built it yourself?  Which operating system?
Were you sending by IP or by Bitcoin Address?
When you sent 49.99, did it prompt you to pay a 0.01 fee?
There was a change in GetMinFee, but I can't see how it would cause this.  It only starts to apply when a block gets huge.
The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.
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:
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.
Did you try -4way?
AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup.  24 cores should get 66,000khps.  AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)
There's been so much else to do that I haven't had time to make -4way automatic.  For now you still have to do it manually.
Bitcoin clients currently only create and recognize transactions that match two possible templates.
Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit.  Nodes will only work on adding those transactions to their block.
In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
Currently, paying a fee is controlled manually with the -paytxfee switch.  It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee.  We're so far from reaching the threshold, we don't need that yet.  It's a good idea to see how things go with controlling it manually first anyway.
It's not a big deal if we reach the threshold.  Free transactions would just take longer to get into a block.
I did a rough tally of 4000 blocks from around 74000-78000.  This is excluding the block reward transactions:
There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.
Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.
The current threshold is 200KB per block, or about 1000 transactions per block.  I think it should be lowered to 50KB per block.  That would still be more than 100 times the average transactions per block.
The threshold can easily be changed in the future.  We can decide to increase it when the time comes.  It's a good idea to keep it lower as a circuit breaker and increase it as needed.  If we hit the threshold now, it would almost certainly be some kind of flood and not actual use.  Keeping the threshold lower would help limit the amount of wasted disk space in that event.
Version 0.3.12 is now available.
Features:
- json-rpc errors return a more standard error object. (thanks to <PRESIDIO_ANONYMIZED_PERSON>)
- 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:
Download:
Another option is to reduce the number of free transactions allowed per block before transaction fees are required.  Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.
The threshold should probably be lower than it currently is.
I don't think the threshold should ever be 0.  We should always allow at least some free transactions.
Can you build?
Try changing line 78 of init.cpp from:
If that works, I'll change the source.  It should work.
rpc backupwallet <destination> is in SVN rev 147.
Thanks.
This is in SVN rev 147.
This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be
not strings or other values, so we needed to change this to be correct.  The code/message members have become standard in later json-rpc specs.
If you have code that checks the error and expects a string, you'll need to change it.  When there is an error, the error member is now an object not a string.
Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code.  Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread.  It locks the wallet and copies it, so you can be sure you get a correct copy.
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
It's trying to tell them their clock is wrong and they need to correct it.
It's relying on 3 time sources:
1) the system clock
2) the other nodes, if within an hour of the system clock
if those disagree, then
3) the user (asking the user to fix the system clock)
I've thought about NTP, but this is more secure.
You can probably just comment out the line
Let me know if it works, and watch if it memory leaks.
It looks like a template class to make sure the derived class defines its own version of allocate and deallocate.  It would be weird if that was the actual problem and it made it all the way to release.  Probably a false alarm.
The code assumes little-endian throughout and was written with the intention of never being ported to big-endian.  Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code.  It would not be worth the extra sourcecode bloat.
Big-endian is on its way out anyway.
What OS?  I ran the Windows and 64-bit Linux version and checked the about dialog.
The Mac version is still 0.3.10.1.
I updated the first post to be more specific.  Only the -4way code is compiled this way.
The simplification is intentional.  There will only be more than one thash[7]=0 in one out of 134,217,728 cases.  It only makes it 0.0000007% slower.
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:
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:
As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose
and one special, magical property:
- can be transported over a communications channel
If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.
Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange.  (I would definitely want some)  Maybe collectors, any random reason could spark it.
I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value.  But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.
(I'm using the word scarce here to only mean limited potential supply)
Bitcoins have no dividend or potential future dividend, therefore not like a stock.
More like a collectible or commodity.
That's kind of interesting as an upside-down bar chart of how many blocks were produced each day.  The target is 144 blocks per day.
Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.
We want to avoid Windows API calls whenever possible.  They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.
I usually shy away from iostreams.  Seems like I too often hit limitations.  They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right.  Using it in rpc.cpp may still turn out to be a mistake.
Bottom line is I'd rather call an existing file copy function than make and test my own.
I doubt there's an mmap(2) on Windows.  I'd rather call an existing file copy function than make and test my own.
Thanks.  I thought it would be in there somewhere.
We already use boost::filesystem in a dozen places.  It's not a new added dependency.  It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere.
If you read it into memory and write it out, it could fail in tight memory situations.
I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it.  If you find it for me, it's more likely I'll get to implementing it.
We require Boost for JSON and a dozen things replacing dependencies on wxWidgets.  Boost is good, portable stuff, we should not shy away from it.
Try -datadir=
Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it.  There wasn't time to investigate at the time.
One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there.  -lwx_gtk2ud-2.9 only matches the right configuration.  It fails if wxWidgets was built with the wrong configuration.
Did they say why they were baffled?
Why is it there?  Was it included by the OS, or did you have to build it?  If you built it, I wonder why it would put itself in a different place.
Has wxWidgets 2.9 finally started to become available as a debian package?
Maybe we should do this:
Again, those paths help make sure it's only 2.9 and will fail with 2.8.
wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us.  It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.
I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.
The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history.  Then a backup will last forward for a long time.
I was starting to post the same idea you said nelisky.
How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it?  That would be a smaller project than the pooled keys, so maybe it could be done first.
What's the simplest portable way to copy a file?  Is there something in Boost?
What should it be named?  maybe:
Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software.  We can try to use words to help the situation until code gets there.
The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history.  Then a backup will last forward for a long time.
Can you provide more details about what removing DB_PRIVATE does?
I can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code.  Does removing DB_PRIVATE make it safe for other processes to open the database simultaneously?  That may be an improvement, depending what the side effects are.  Does it substantially reduce performance by making it have to write out every change immediately or do other coordination?  Are there additional locking or coordination files then?  What else changes?  You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor.
Apparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database.  It still lets them, it just screws up if they do.  Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes.
My apologies, your post was indeed a question not a statement.
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.
The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.
I added the switch "-testsafemode" for you.  SVN rev 145.
This stuff is very new and may still be subject to change.
Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.
-4way should eventually be replaced by an auto-detect.
WRT the alert system, who cares?  The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade.  All nodes keep running and generating, the network stays up.  If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system.  It would be a temporary inconvenience only.
This is what makes me think the people objecting don't know what they're talking about.  It can't "shut down the complete network".
I changed the switch name to -disablesafemode.
It can't do arbitrary actions remotely.  Maybe some of you are responding to other posters who suggested the alert system should do more?
If there is an alert, the following json-rpc methods return an error:
The remaining 14 methods function as normal.
I believe the safer option should be enabled by default.  If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.
Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.
Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.
Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back.  I'm not arguing that this is the permanent way of things forever.  It's still beta software.
This is in SVN rev 142 as version 0.3.11.
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do.  If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.
This probably explains why hyperthreading increases performance with -4way.  If three SSE2 units is excessive, then hyperthreading would help keep them all busy.
Hey Zooko!
I wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the Cryptography mailing list.
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:
Thanks for clearing that up.  I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel.
There's no hope for Core/Core2 then.  They only have half the SSE2 hardware.
Strange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one.
Search debug.log for "proof-of-work found".  If you find any, then check for any errors right after that.
The margin is 2 hours.
This should be solved in SVN rev 141 and the next release (0.3.11+).  It'll pop up a message box alerting you if your clock is off by more than an hour.
The clock part will be covered in the next release (0.3.11 or higher).  SVN rev 141 pops up a message box if your clock is too far off.
That's right.  You don't need to be re-broadcasting your transactions for it to work.
When any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain.  The entire network is making sure to re-integrate your transactions again.  All you should see is that your number of confirmations starts over from 0.
In some types of forks, your transaction would have gotten into both forks already, so you're already good either way.
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.
Make sure your computer's date and time are correct.
That's the first I've heard anyone say i5 was slower.  Everyone else has said 4way was faster on i5.  Moreso with hyperthreading enabled.
Good, so I take it that's a confirmation that it's working on Mac as well?
Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac.  I don't think makefile.osx on SVN has it yet, just the built version.
That's a really well written walkthough.  Someone should confirm if they followed it and didn't run into any snags.
wxWidgets 2.9 is their first UTF-8 version.  We are UTF-8 on all platforms including Windows.
The distro packages of 2.8 are UTF-16, so they just trip people up.  People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9.  Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.
This is a problem that will solve itself.  With time, 2.9 will become a more mainline release.
In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000.  If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem.  Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.
Still, the system won't be entirely secure against your blk*.dat files.  You are trusting someone if you use a copy of their blk files.
The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical.  Only in the 1500 khash/s range.  If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast.  It still has to do all the steps.  It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel.  That's not necessarily easy or a given.
Definitely.  The old screenshots of 0.1 are very outdated.
Windows Aero is a good choice.  Windows is still the largest user group.  Mind what's behind it for the transparent parts.
What to have displayed in the transaction list?  Not completely filled up with stuff, just a few things.
Total proof-of-work.
Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks.  If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again.  0.3.9 and lower nodes still must upgrade.
The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually.  I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option.
There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work.  In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.
The only exception to that is the manual checkpoints I've added.  If it weren't for those, it would be able to reorg all the way back to the first block.
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.
This is what I ended up doing in SVN rev 139.
Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.
Done in SVN rev 137
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
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:
That's a difficult approach.
We need to cause a reorg, which will disconnect the invalid chain.
This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.
Here's what I was thinking of.  (I haven't tested this yet)  It checks all the blocks in the main chain.  If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg.  (It can't change pindexBest without actually doing a reorg)
This isn't perfect yet.  It still needs to receive one valid block to trigger the reorg.
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention.  I probably should break out part of AddToBlockIndex that sets the new best block.  I'll probably end up doing that instead of the code below.
I wrapped sha256.cpp in
try it now.
It looks like we overtook the bad chain somewhere around 74689.  0.3.9 and lower nodes have been responding with the current block number for some hours now.
That means it's no longer necessary to delete blk*.dat before upgrading.  You can just upgrade and it'll reorg away the bad block chain.
Thanks to everyone for the quick response!
cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.
That works.
That's strange...  are we sure that's the same thing?  tcatm, try amdfam10 and make sure you get the same speed measurement.
GCC 4.3.3 doesn't support -march=amdfamk10.  I get:
Hey, you may be onto something!
hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.
tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.
How much of an improvement do you get with hyperthreading?
Some numbers?  What CPU is that?
On Windows, findstr /c:"version message" debug.log
It looks like the bad chain was on block 74678 recently.  Can't wait to overtake it.
On the stats at there's been 5 blocks per hour in the last 3 hours.  We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour.
The bad chain is also slowed down as more nodes upgrade.
We've already generated 14 blocks since 74638.  The builds of 0.3.10 were uploaded about 2 and 3 hours ago.  Of the nodes I'm connected to, more than half are already 0.3.10.  I would say we probably already have more power than the bad chain.
1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.
If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.
For today, try adding these parameters:
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14
Right, it will get reincorporated into the fixed chain.  The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.
It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear.  Any blocks in the bad chain wouldn't have matured yet.
For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP?  Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.
I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower.  We need enough of us so that at least one node you connect to will be 0.3.10.  The problem will start to go away when we make up more than 1/8th of the network.
It'll help if you port forward so you can get lots of connections.
Version 0.3.10 patches the block 74638 overflow bug.
The 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:
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.
Agree, wanted to do that for a long time, haven't had time to do it.
For now, you could also subscribe to the bitcoin-list mailing list.  It rarely gets used except for announcements like this and major new versions.
Starting at 67000 is
Yeah, at the moment you'll stop at 74638.  It should start slowly creeping up as more nodes upgrade and generate.
Linux build links below.
The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5 and AMD CPU's.  Use the "-4way" switch to enable it and check if it's faster for you.
Download links:
Just leave the old one alone!  Older is better.  What block number is it?  Anywhere from 60000-74000 is good.  The one that you've had available for a while has been vetted and is the best choice.
Don't update the block chain download.  When you take someone's block chain download, you don't want it right up to the end.  A somewhat old one is better so it can download and verify the most recent blocks.
tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.
I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux.  If you build rev 134 on Linux now you'll get the -4way switch.
If you have problems building because of it, then edit makefile.unix and:
- remove -DFOURWAYSSE2
- remove obj/sha256.o from the end of these lines:
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o
The 0.3.10 linux build
have the -4way option when I build it.
Here are the patch downloads for Windows:
Steps:
1) Shut down.
2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.
3) Upgrade to 0.3.10.
4) It should start out with less than 74000 blocks and redownload the rest.
Or if you don't want to mess with downloading blk files, you can just do this:
1) Shut down.
2) Delete (or move) blk*.dat
3) Upgrade to 0.3.10.
4) It redownloads all blocks, probably take about an hour.
Patch is uploaded to SVN rev 132!
For now, recommended steps:
1) Shut down.
2) Download knightmb's blk files.  (replace your blk0001.dat and blkindex.dat files)
3) Upgrade.
4) It should start out with less than 74000 blocks. Let it redownload the rest.
If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
I'll build releases shortly.
Once you have an update, you could download knightmb's block chain.  You'll want one that's old enough that it ends
block 74000 so the most recent security lockin will check it.  Can someone find the link for that?
It would help if people stop generating.  We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.
A first patch will be in SVN rev 132.  It's not uploaded yet.  I'm pushing some other misc changes out of the way first, then I'll upload the patch for this.
Here's the preliminary change.  Look right?  I have more changes to make, this isn't all of it.  Will SVN shortly.
Don't sticky the topic, nobody looks up there.  There'll be enough posts to bump.
I just uploaded a quick build so testers can check if I built it right.  (I don't have an i5 or AMD)  If it checks out, I'll put together the full package and do all the release stuff.
I hope someone can test an i5 or AMD to check that I built it right.  I don't have either to test with.
I'm also curious if it performs much worse on 32-bit linux vs 64-bit.
The idea was the main part.  When you posted your patch, I realized it should have been done that way instead of "-?".  I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.
Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them
There are legitimate places where it's free.  Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating.  Many small flats have electric heat out of convenience.
How expensive is heating oil?  With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.
There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.
Case 3 comes into play for small amounts.  The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments.  I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
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.
Please 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.
On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner.  So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.
I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.
I found the problem with Crypto++ on MinGW 4.5.0.  Here's the patch for that:
MinGW GCC 4.5.0:
Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns
I only got 4-way working with test.cpp but not when called by BitcoinMiner
MinGW GCC 4.4.1:
Crypto++ works
4-way SIGSEGV
GCC is definitely not aligning __m128i.
Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.
By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only:
But that's with -O0.
Got the test working on 32-bit with MinGW GCC 4.5.  Exactly 50% slower than stock with Core 2.
If you haven't already, try aligning thash.  It might matter.  Couldn't hurt.
No help from -O0, same error.
MinGW is GCC 3.4.5.  Probably the problem.
I'll see if I can get a newer version of MinGW.
MinGW on Windows has trouble compiling it:
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make: *** [obj/sha256.o] Error 1
It's too soon to start junking up the API for backward compatibility at all costs.
Just return "<txid>".
I'm not grasping your idea yet.  Does it hide any information from the public network?  What is the advantage?
If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it.
Can public nodes see the values of transactions?  Can they see which previous transaction the value came from?  If they can, then they know everything.  If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.
Does it hide the bitcoin addresses?  Is that it?  OK, maybe now I see, if that's it.
Crypto may offer a way to do "key blinding".  I did some research and it was obscure, but there may be something there.  "group signatures" may be related.
There's something here in the general area:
What we need is a way to generate additional blinded variations of a public key.  The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them.  Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key.  These are the properties of blinding.  Blinding, in a nutshell, is x = (x * large_random_int) mod m.
When paying to a bitcoin address, you would generate a new blinded key for each use.
Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key.  I'm not sure if always signing a different blinded public key would already give you this property.  If not, I think that's where group signatures comes in.  With group signatures, it is possible for something to be signed but not know who signed it.
As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it.  If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.
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)
Linux please test rc2 instead.  This adds a -4way switch for tcatm's 4-way SSE2.  This will only be for Linux:
Please report back your results
Which doesn't matter because you can't access sourceforge to download the software either.
If you've ever been connected before, you don't need IRC to bootstrap anymore.  Even if you haven't, you can bootstrap from seed nodes.  IRC is completely redundant since 0.3.0.
No, that's not what it is.
-paytxfee allows you to include a transaction fee with your transactions.  If transaction confirmations become slow, you can get priority by using "-paytxfee=0.01".  Any transactions you send would cost an extra 0.01.  There's no reason to use more than 0.01.
It's just there in case we need it.  It probably won't be needed, and it can be explained more if we do.
That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with.  Unless it's a touted feature of the i5 that they made SSE2 six times faster.
A quick summary:
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.
on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)
My Core2Quad (Q6600) slowed down 50%,
my i5 improved ~200%,
on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)
Fixed in SVN rev 130.
True, there would probably be someone with a dial-up modem or satellite dish internet.  Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.
ISP network cuts are just your local area.  If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less.  Block generation in the segment would take several hours per block.
I favour the plan to monitor if the frequency of blocks received drops too slow.  That covers a large range of possibilities.
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
This is in SVN rev 130.  Check that it compiles right.
Are you back to talking about the existing Bitcoin system here?
I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.
If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.
But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think.
That code was a bad idea anyway, I'm deleting it.  Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__.
Will that definitely cause BSD to be defined on Mac?
It would be nice to keep the blk*.dat files small as long as we can.
The eventual solution will be to not care how big it gets.
But for now, while it's still small, it's nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won't matter much anymore.
There's more work to do on transaction fees.  In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.  However, I haven't had time yet to add that option to the UI.
Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
It doesn't have to be such a breaking change.  New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW.  Or, they could always accept old transactions, but only a limited number per time period.
I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better.  0.01 is basically a proof of work, but not wasted.  But if the problem is validating loads of transactions, then PoW could be checked faster.
A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected.  Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.
+1
Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.
You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup.  (like 5 seconds)
No, it doesn't usually empty your wallet with each transaction.  It uses the smallest set of coins it can find to add up to near the amount.  In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.
Still thinking this idea through...
The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.
If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:
- the value
- the association of inpoints and outpoints in one transaction
The network would track a bunch of independent outpoints.  It doesn't know what transactions or amounts they belong to.  A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent.  The network keeps the outpoint and the first valid inpoint that proves it spent.  The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.
I believe the clients would have to keep the entire history back to the original generated coins.  Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend.  Maybe the data transfer could be done as an e-mail attachment.
The fact that clients have to keep the entire history reduces the privacy benefit.  Someone handling a lot of money still gets to see a lot of transaction history.  The way it retrospectively fans out, they might end up seeing a majority of the history.  Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
Updated SVN.  Thanks.
There's little hope of not repeatedly stumbling over that in the future.  It doesn't break the compile for me.
That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.
When you pay for something up front, you can't get it back either.  Consumers seem comfortable with that.  It's no worse than that.
Either party always has the option to release it to the other.
Then you must also be against the common system of payment up front, where the customer loses.
Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn't get the money either.
Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?
Imagine someone stole something from you.  You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it?  Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too?  If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen.  If the thief gives it back, it turns to gold again.
It still seems to me the problem may be one of presenting it the right way.  For one thing, not being so blunt about "money burning" for the purposes of game theory discussion.  The money is never truly burned.  You have the option to release it at any time forever.
This is a very interesting topic.  If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.
Originally, a coin can be just a chain of signatures.  With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations.  It's the need to check for the absence of double-spends that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist?  It seems a node must know about all transactions to be able to verify that.  If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before.  Do you have any ideas on this?
It's hard to think of how to apply zero-knowledge-proofs in this case.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
SVN rev 128: disable SSE2 on 32-bit.  This may only disable it for MSVC and GCC.  Other compilers might have different 64-bit defines.
The heat from your computer is not wasted if you need to heat your home.  If you're using electric heat where you live, then your computer's heat isn't a waste.  It's equal cost if you generate the heat with your computer.
If you have other cheaper heating than electric, then the waste is only the difference in cost.
If it's summer and you're using A/C, then it's twice.
Bitcoin generation should end up where it's cheapest.  Maybe that will be in cold climates where there's electric heat, where it would be essentially free.
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?
That's a good point, I believe you could run with generation off if you don't have SSE2.
How about add to the top of cryptopp/config.h:
that would disable SSE2 for 32-bit builds.  (at least with GCC or MSVC)
I uploaded 0.3.8.1 for Linux with re-built 64-bit.  I ran a difficulty 1 test with it and it has generated blocks.
int is good until 2106.  Surely the network will have to be totally revamped at least once by then.
There should not be any signed int.  If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.
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 0.3.8.1 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?
I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility.  I was trying to take the safer option.
It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime.  Maybe I'm not looking in the right place.
Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
Sorry about that.  CRITICAL_BLOCK isn't perfect.  You have to be careful not to break or continue out of it.  There's an assert that catches and warns about break.  I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.
Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around?  For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow?  I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level.  I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope.  But it would be really nice if this was working on most CPUs.
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.
Really?  Do you think people won't be able to understand the benefit?  (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)
It's the same situation as gold and gold mining.  The marginal cost of gold mining tends to stay near the price of gold.  Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.
I think the case will be the same for Bitcoin.  The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used.  Therefore, having Bitcoin would be the net waste.
Each node's influence on the network is proportional to its CPU power.  The only way to show the network how much CPU power you have is to actually use it.
If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it.  IP addresses... much easier to get lots of them than CPUs.
I suppose it might be possible to measure CPU power
For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes.  You could still prove your total power at given times without running it all the time.  I'm not sure how that could be implemented though.  There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.
Proof-of-work has the nice property that it can be relayed through untrusted middlemen.  We don't have to worry about a chain of custody of communication.  It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?
A transaction can be written that requires two signatures to spend it next.  You write a payment that requires the signature of both the recipient and the sender to spend it.  To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half.  There's no mediator in this simple case.  The recourse is to refuse to ever release it, essentially burning the money.
If you're only going to have one person work on building the block, that could take days.  Oh, do you mean send a different variation to each node with the tx fee written to them?
The way it is now, it's whoever builds this gets it.
If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast.  Relay paying transactions to me, or I won't relay them to you.  It probably won't be an actual problem though.  It only takes one node relaying like it should to cancel out 7 others greedily not relaying.
I can't think of a way to implement that.  All the transaction fees would be additional transactions.  What about the transaction fees for the transaction fee's transaction?
It's not implemented.
It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
Silently failing would look bad.
Definitely needed.  What rate are you thinking of?  Ultimately, it's better to rate limit it than to let it all drain out.
That might work surprisingly well.  If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.
Definitely time to lower it.
I don't know a way to implement that.  The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size.  If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
One alternative is to use a round-up system.  You pay for, say, 1000 pages or images or downloads or searches or whatever at a time.  When you've used up your 1000 pages, you pay for another 1000 pages.  If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.
Or you could pay per day.  The first time you access the site on a given day, you pay for 24 hours of access.
Per 1000 or per day may be easier for consumers to get their heads around too.  They worry about per item because it's harder to figure if it might add up too fast.  Unlimited for 24 hours they know what the cost will be.  Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
Forgot to add the good part about micropayments.  While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.  If Bitcoin catches on on a big scale, it may already be the case by that time.  Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.  Whatever size micropayments you need will eventually be practical.  I think in 5 or 10 years, the bandwidth and storage will seem trivial.
I am not claiming that the network is impervious to DoS attack.  I think most P2P networks can be DoS attacked in numerous ways.  (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)
If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.  0.1.5 actually had an option to set that, but I took it out to reduce confusion.  Free transactions are nice and we can keep it that way if people don't abuse them.
That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01?  It would be awfully annoying to ask each time.  If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left.  I think it should just add it automatically.  It's trivial compared to the fees many other types of services add automatically.
No, not at all.
Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.
The software is designed to support things like this.  I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.
I guess SourceForge hasn't updated its mirrors yet.  The files are there on the admin side, but not on the user side.  I have no idea how long that will take.  It's always been immediate in the past.
Edit: SourceForge is updated now.
I'd rather you didn't make a build of the 1000 node connecting version available.  It won't take very many people running that before we have to make another release just to limit the incoming connections.
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.:
creighto: I agree with that idea.  After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance.  It could tell if it's not hearing the hum of the world anymore.
In practice, splits are likely to be very asymmetrical.  It would be hard to split the world down the middle.  More likely it would be a single country vs the rest of the world, lets say a 1:10 split.  In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days.  Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.
There's no time limit.  Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.
I guess we should try to support the case where there's no Content-Length parameter.  I don't want to rip and replace streams though, even if it has to read one character at a time.
Edit: That is, assuming there actually are any libraries that don't support Content-Length.
I urge you not to use BDB 4.8.  The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.
Yes, 0.3.7 has it.  It was in rev 112.
The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure.  Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.
I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly.  The serialization format we have is as dead simple and flat as possible.  There is no extra freedom in the way the input stream is formed.  At each point, the next field in the data structure is expected.  The only choices given are those that the receiver is expecting.  There is versioning so upgrades are possible.
CAddress is about the only object with significant reserved space in it.  (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)
The larger things we have like blocks and transactions can't be optimized much more for size.  The bulk of their data is hashes and keys and signatures, which are uncompressible.  The serialization overhead is very small, usually 1 byte for size fields.
On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists.  There are few P2P systems that only need broadcast.  There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want.  Those libraries are also much harder to install than ourselves.
Is it 2x fast on AMD and 1/2 fast on Intel?
Tried that, but it doesn't work for things on the stack.  I ran some tests.
It doesn't even cause an error, it just doesn't align it.
"Minimize to the tray instead of the taskbar" & "Minimize to the tray on close" must not be implemented yet on the Mac.  We should grey them out in the next version.
Did it print anything to the console?  Are you sure you didn't run "bitcoind"?
Try version 0.3.7.
It can be built with Boost 1.37 or later.
It would be neat if someone had a page (like that handy calculator at
) that projects what the next difficulty adjustment will be.
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:
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.
That's amazing...
So are you saying you use 128-bit registers to SIMD four 32-bit data at once?  I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.
Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.
Seems they changed everything around in Boost recently, "-mt" and all that, makes it hard.
BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.
Mac OSX version is available now.  See bitcoin.org or the SourceForge link.
I can't understand why you're having so much pain.  I just followed the instructions in build-unix.txt.  I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:
What are you needing to use listtransactions for?
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it.  It would be very easy to latch onto that for watching for received payments.  There is no reliable way to do it that way and make sure nothing can slip through the cracks.  Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
When we do implement listtransactions, maybe one way to fight that is to make it all text.  It should not break down the fields into e.g. comment, confirmations, credit, debit.  It could be one pretty formatted string like "0/unconfirmed   0:0:0 date   comment      debit 4  credit 0" or something so it's hard for programmers to do the wrong thing and process it.  It's only for viewing the status of your server.  I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
I don't get how it let you send if it was not matured.  Your balance would have been lower than the amount.  It would have said balance 0.01, right?  If I try that it says "you don't have enough money" or "Insufficient funds" from the command line.
How many blocks did it say it had left to mature when you sent?
There's a chance it might still go through.
Have you copied or moved your wallet.dat in any way?
We don't really need pre-compiled header.  It only makes it compile slightly faster.  I think I'll just get rid of it.  Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11.  I thought I'd been careful not to accept any of the updates.
Yeah, acutely aware that I should have stayed on 9.04 or 9.10.  It's a lot more work to downgrade than upgrade and I've been squeezed for time.  Ubuntu is the most popular distro, so I'm staying with that.
If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it.  Long term, it does keep relentlessly sending it.
I'll shorten that length of time in a future version.
You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms.  Same with the recipient.
Actually, it works well to just PM me.  I'm the one who's going to be fixing it.  If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.
"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it?  This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0.  I will not upgrade anymore.  I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
0.3.6 Linux build is back to the old makefile.unix.  It static links libjpeg so that shouldn't be a problem.
Is that working better?
If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*
Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
SVN is updated with version 0.3.6.
Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.
Haven't had time to update the SVN yet.  Wait for 0.3.6, I'm building it now.  You can shut down your node in the meantime.
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.
WTF?  How did we get on that?  AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration.  I'd consider turning off the forum notification e-mails, I don't know why we have that.
The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions and don't generate.
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less.  If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
You were looking at the wrong code.  Here's the code that applies:
The timestamp is limited to up to 2 hours in the future.  It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks.  The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.
Was that the only thing I broke in the OSX build?!  Does it actually work after just that one change?
I had to do that for makefile.vc also.  It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.
We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then.  It's still 1.7x faster from the midstate optimisation.
The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).
I uploaded this makefile.osx change to SVN.  (let me know if that compiles now)
It was able to reproduce this.  The database doesn't like the relative path.
"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
OK, thanks.  I'd also like to know if it runs fine as long as you don't turn on Generate.  You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load.  At least Pentium 3's could run it without generating.
I added a subset of the Crypto++ 5.6.0 library to the SVN.  I stripped it down to just SHA and 11 general dependency files.  There shouldn't be any other crypto in there other than SHA.
I aligned the data fields and it worked.  The ASM SHA-256 is about 48% faster.  The combined speedup is about 2.5x faster than version 0.3.3.
I guess it's using SSE2.  It automatically sets its build configuration at compile time based on the compiler environment.
It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available.  I want the release builds to have SSE2.  SSE2 has been around since the first Pentium 4.  A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.
I added the cached SHA256 state idea to the SVN, rev 113.  The speedup is about 70%.  I credited it to tcatm based on your post in the x64 thread.
I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes.  It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++.  Does it only work with the MSVC and Intel compilers?
Is that still starting from Crypto++?  Lets get this into the main sourcecode.
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.
Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA.  I shouldn't have said "prime numbers".  ECDSA doesn't take much time to generate a keypair.
For future reference, here's my public key.  It's the same one that's been there since the bitcoin.org site first went up in 2008.  Grab it now in case you need it later.
SVN rev 111
That's strange, didn't someone just say that was supposed to work?  (what library was he using?)  Post if you figure out what wrong.
I hope it's not going to put up this much of a fight for all PHP users.
Looks like we've got the Fortran scenario already.
+1 to you for having such a long password that you found this bug.
Uploaded to SVN as rev 110.
2^80 is if you can use a birthday attack.  You can't use a birthday attack for this, so the difficulty is the full 2^160 bits.  Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.
Bitcoin Addresses are the only place where 160-bit hash is used.  Everything else is SHA-256.  They're calculated as:
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case.  An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision.  Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256.  If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it?  You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.
For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone.  But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256.  If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.
You would still have to sign it with public key 654321.  You need to find a collision using a public key for which you know the private key.
When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.
Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.
He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone.  Someone trying to brute force would have to take time generating a key for each attempt.
Red, thanks for telling me privately first!  Please go ahead and post it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as secure as the hash function.  To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself.  An attacker would only have to break the hash function, not ECDSA.
It's best if you tell it to me privately so it can be fixed first.
I just e-mailed you my e-mail address.  (or you could PM me here)
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
Please do these tests on the test network.  That's what it's for.  Thanks.
Was that on the test network?
FLATDATA was a workaround to serialize a fixed field length array.  There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time.  We don't support MSVC6 anymore because we use something in Boost that doesn't.  We lost support for it after 0.2.0.  Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
Please test 0.3.2.5 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
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply?  I can't remember where I picked that up, maybe it's wrong.  It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself.  (and maybe that's what it said and I forgot and spread 500 to all error responses)
Obviously it's a bug that it repeats the header.