getinfo and getbalance (with no arguments)... are a little complicated.

They include all 1 confirmation receive transactions, but (this is the complicated part) they also include 0-confirmation receives if they are self-sends (either the "change" from coins you just sent or all the coins if you sent to one of your own addresses).

In any case, I think they will do exactly what you want-- show you coins that have at least one confirmation or that you are certain you are able to spend (because they are your own 0-confirmation coins).

It will create 100 keypool entries the first time you request a new address or if you turn on coin generation (the mining threads each ask the keypool for an address to create the coinbase transactions).

I don't know what the story is with "wkey".

getbalance '*' 1

... will do what you want in the next version of bitcoin.  I need people to help download and build and test it.

Please checkout the git integration branch from:
  https://github.com/bitcoin/bitcoin

... and help test.  The new features that need testing are:

-nolisten : https://github.com/bitcoin/bitcoin/pull/11
-rescan : scan block chain for missing wallet transactions
-printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

-maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
...and several improvements to --help output.

This needs more testing on Windows!  Please drop me a quick private message, email, or IRC message if you are able to do some testing.  If you find bugs, please open an issue at:
  https://github.com/bitcoin/bitcoin/issues

What version of gcc are you using?  After a little googling I found this thread about the same issue:

Unless somebody volunteers to fix/maintain this, I'm inclined to simply remove all of the "try to make the CPU miner go faster" optimizations from bitcoin.  CPU mining is, for most people, a waste of electricity.

There are:
  1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible bitcoin addresses.

As ribuck says, that is a very big number.  There are approximately:
133,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

.. atoms in the Earth, so even if you used just 100 atoms to store each bitcoin address, you'd run out of atoms before you were done generating addresses.

From the Quora question:


You can't spend 400 BTC 80 times in 1 hour.  If you control a majority of the generation you could spend them twice an an hour (assuming merchants require 6 confirmations).

So you need to divide your expected profit per hour by 40, making your ROI very, very negative.

You are confusing "control 50+% of generating power" with "control connections."

Lets say you control 51% of the generating power.

You can:

Spend bitcoins once.  Then wait for them to be confirmed by the rest of the network as many times as the merchant requires, while secretly working on another version of the block chain where you did NOT spend them.  Your secret block chain should be longer than the network's, since you control 51% of the generating power.

So you announce your secret block chain, and instead of sending those coins to a merchant you include a transaction where you send them to yourself.  YEAH!  you just ripped off the merchant!  Wahoo!

You cannot rip off two merchants with the same bitcoins-- one or the other of the transactions will be seen as valid.

And you cannot "unspend" the transaction to the merchant-- if you don't spend it SOMEWHERE, the merchant's bitcoin node will re-announce it to the network and all the other nodes will consider those bitcoins "spent, just waiting to be included in the next generated block."


If you run the numbers again with the realistic double-spend scenario, you'll see crime doesn't pay.  There is no way you can rent enough hashing power to commit a profitable double-spend attack.

If you can steal the hashing power (maybe you're a bot farmer), then if you run the numbers you'll find it is more profitable to just generate blocks and sell the bitcoins rather than try to somehow get stuff trying to double-spend.

FreeMoney is absolutely right.

The only way to get 80 people to accept the same 400 bitcoins would be to control all of their bitcoin connections and feed them different versions of the block chain.

And THAT will be impossible, because the people you're trying to rip off (merchants selling stuff) are exactly the people with long-running, well-connected bitcoin nodes.

It will have only 8 (outgoing) connections.

With fewer connections, it will notice new blocks a tiny bit more slowly than the other machine, and blocks it finds will propagate to the rest of the network slightly more slowly than the other machine.  So it will spend a teeny-tiny bit more time working on an out-of-date block chain, and will be a teeny-tiny bit more likely to lose "announce a new block" races.  But I bet the effects are so small you'd never notice them.


Yes and yes and no.

The number of confirmations tells you which block a transaction is in:
0 confirmations: not in a block yet.
1 confirmation: in block number "getblockcount" block.
2 : getblockcount-1
 ... etc.

Note that if there is a block chain reorganization which block the transaction is in can change (as can the number of confirmations).

BioMike:  any progress tracking this down?

I just committed a fix to the git integration tree CallCPUID code to declare ebx/edx clobbered...

"Bitcoin, the New Zimbabwe Dollar" would be TERRIBLE marketing.  How about a nice, respectable country that is just tired of using somebody else's currency?  If the value of the dollar keeps falling, there may be a lot of those in the next 20 years.

It is time to build and test a new version of bitcoin.

In the past, Satoshi built the Windows and Linux releases, Laszlo built the Mac releases, and we trusted them not to put malware in them (or we compiled ourself from source).

Satoshi is busy, and even if he wasn't he shouldn't be spending his time doing a job that a lot of the rest of us are capable of doing.  So we need a new process.

Ideally, that process should be open and verifiably trustworthy.  So I'd like to propose that we do the following:

1. For each platform, somebody creates a pristine, reproducible build environment, preferably as a virtual machine image that anybody can download, inspect, clone, run, etc.

Anybody should be able to reproduce the build environment by running or following a script (e.g. "Install Ubuntu X.Y.Z.  apt-get the following versions of the following packages... etc").

2. A copy of that virtual machine is used to build/package the release.

3. Anybody can audit the process by re-creating the build environment and ensuring that they end up with "identical" executables.  (where "identical" means compare the code in the executables, ignoring timestamps or other meta-info linkers put into executables -- are there already tools to do that, or do we need to roll our own?).

Feedback?  Suggestions for improvement, or are there better ways of creating 'trusted builds' ?

Just to be sure:  "removed all bitcoin data" means you removed and reinstalled bitcoin.exe ?

RE: wallet works fine on ubuntu:  did you happen to run the wallet on another machine, then copy it back to your windows machine?

I don't know what to suggest-- I'm not a Windows person...

I wrote a 'vanity bitcoin address' patch a while ago that lets you do exactly that:  https://gist.github.com/614460

I bet finding an address starting  1HAL...  wouldn't take more than a few hours.  If I recall, it took a day or so to find one with the string 'gavin' in it.

Because the first byte in a bitcoin address is a version number, and "version 0" is encoded as a "1" in the bitcoin address "base58 encoding" (because 0 is too easy to confuse with capital-o).

Trivia:  -testnet addresses are version 111 (eleven is my favorite number), and begin with m or n (I haven't actually worked out whether they might begin with another letter, too...).

Publicly announce where?

Publicly announce it here and one of the moderators will delete it faster than you can type 'rm'.
Announce it on your own website and I'd encourage the legal authorities and/or your ISP to shut you down.

Announce it in IRC chat or via a Freenet/TOR/i2p hidden service and I would personally encourage everybody to shun and /ignore you... and very few people will hear your announcement, anyway.

I suppose you could try to get a journalist or government interested in causing trouble for bitcoin to publicly announce it.  If you did, I would ask as loudly as I could why the journalist or government is complaining about innocent bitcoin users instead of trying to track you down and prosecute you.

Yes, after posting I realized that self-mixing creates a mostly-self-connected sub-graph.  You really need to start with multiple transactions in, ideally randomly occuring during the mixing process, and not spend all your bitcoins at once.

Somebody who knows a lot more about graph theory, statistics, and probability than I do should chime in and tell me how I'm wrong or come up with a good metric for the ideal amount of mixing (I bet too much is just as bad as too little).  Analyzing the connectedness of the existing bitcoin transaction graph might be a good place to start.

If the threat model is as zipslack describes, then I think a "send to self" mixnet would work.

Patch bitcoin so it generates, a random transaction every, oh, I dunno, eight hours or so, sending, oh, I dunno, 1/10'th or so of your bitcoins back to yourself via a newly generated address.

And to erase your trail in case your wallet gets seized, remove the source transactions and their (spent) keys from your wallet.

After a week of doing that you'll have put 21 extra transactions on the network and, on average, four extra transactions on the coins in your wallet (four because every send typically generates a change transaction).  Do it constantly and you'll have an ever-churning wallet that aught to foil any attempt to connect incoming <-> outgoing transactions.

That is all assuming that you don't start with zero bitcoins in your wallet, get exactly 111.11 bitcoins from somebody, spend a couple weeks mixing them, and then pay exactly 111.11 bitcoins to somebody else.  That transaction network graph is easy to analyze, and it would be insanely unlikely that you "just happened" to receive exactly those same 111.11-worth of coins that were given out.

Hmm, I wonder if the patch could detect a bad mix and warn you if you tried to do something stupid like that...

Somebody who knows a lot more about mixnets than I do can probably work out the math to know how much, and what type, of randomness to add to the eight hours and 1/10th to make statistical analysis as difficult as possible.