It looks like the implicit conversion from std::string to wxString isn't working.  That's used everywhere, the conversion needs to work.

wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile.  You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.

It's probably some wxWidgets compile defines or build configuration.  What "configure" options did you use?

I'm not sure __WXMAC__ is the right define.  It may be the Mac Classic support that's complicating wxString, and we only want OSX.  Try __WXOSX__ (or see below)

http://docs.wxwidgets.org/stable/wx_cppconst.html
"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:

    * If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.
    * If you want to test for any GUI Mac port under OS X, use __WXOSX__.
    * If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__"

There would be a command line switch at runtime to tell it to run without UI.  All it needs to do is not create the main window.  A simplistic way would be to disable "pframeMain->Show" and "ptaskbaricon->Show" in ui.cpp.  The network threads don't care that the UI isn't there.  The only other UI is a message box in CheckDiskSpace if it runs out of disk space.

Then a separate command line utility to communicate with it to do things.  Not sure what it should be named.

"natural deflation"... I like that name for it.  Yes, there will be natural deflation due to payment mistakes and lost data.  Coin creation will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation.

Mac support would be nice.  wxWidgets really pays off for cross platform.

Please don't try PPC.  PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there.  PPC is on its way out anyway.

Considered autoconf.  Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it.  I'd rather keep the makefile simple as long as possible.

My head hurts just thinking about that.  Funnelling all the UI backend through a TCP connection would make everything twice as hard.  There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.

I'd rather have command line control, that would get us remote admin and batch automation.

The average total coins generated across the network per day stays the same.  Faster machines just get a larger share than slower machines.  If everyone bought faster machines, they wouldn't get more coins than before.

We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network.  It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility.  It's nice how anyone with just a CPU can compete fairly equally right now.

Right, the SVN has the almost-release-candidate 0.2 source, which can also be built and run on Linux.   It hasn't been tested on FreeBSD.

That would be a big help.  TOR users wouldn't have to worry about how to get seeded, and we wouldn't depend on IRC.

It can be run in a few simple modes without access to the UI if you don't mind a minimized window on the desktop.  (0.1.5 doesn't have -min so it would be an open window)

To only run a seed:
bitcoin -min -gen=0

You could sort of monitor it by looking at debug.log.  To stop it, kill the process, the database won't mind.

To generate:
bitcoin -min -gen

To get the generated bitcoins, you'd have to copy wallet.dat (with version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin and transfer the coins to your main account.  (With version 0.1.5 you'd have to copy the whole "%appdata%/Bitcoin" directory.)  There is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory.

I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels everyone through a few proxy servers.  I just committed a fix to SVN for this.  If it gets "433" name already in use (it was error 433, right?), it'll retry with a non-address random username.  

That's great, any help is really appreciated!

That's true, with the send-to-IP option, you are sending to whoever answers that IP.  Sending to a bitcoin address doesn't have that problem.

The plan is to implement an IP + bitcoin address option that would have the benefits of both.  It would still use a different address for each transaction, but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver.

1-3:
For that level of anonymity you need to connect through TOR, which will be possible with version 0.2, which is only a few weeks away.  I'll post TOR instructions at that time.

4:
Version 0.1.5: backup the whole %appdata%\Bitcoin directory.
Version 0.2: you can backup just wallet.dat.

5:
Nope.  The whole design is all about preventing that from working.

6:
Those coins can never be recovered, and the total circulation is less.  Since the effective circulation is reduced, all the remaining coins are worth slightly more.  It's the opposite of when a government prints money and the value of existing money goes down.

7:
It's currently 29,296 blocks.  The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.  

If you only have 24k blocks, it must not have finished the initial block download.  Exit bitcoin and start it again.  Version 0.2 is better/faster at the initial block download.

8:
Typically a few hundred right now.  It's easy now but it'll get harder as the network grows.

9:
Good question, it's TCP.  The website needs to be updated to say TCP port 8333.

The port forwarding is so other nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes.  You also need it to receive payments by IP address.

10:
No, the other nodes won't accept that.

Being open source means anyone can independently review the code.  If it was closed source, nobody could verify the security.  I think it's essential for a program of this nature to be open source.

11:
Slower machines produce fewer coins.  It's proportional to CPU speed.

12:
There are more coming.

13:
It uses a transactional database called Berkeley DB.  It will not lose data in a system crash.  Transactions are written to the database immediately when they're received.

14:
For now, you can just multiply the total blocks by 50.  The Bitcoin network has been running for almost a year now.  The design and coding started in 2007.

That's a good approach for mobile.  Programmatic API used by PHP (any language) to present a web UI covers remote admin, mobile and any other client that can't be online all the time with a static IP.  It would be like webmail.  It would be easier for new users to get started if they only need to create an account on a website, not install software.

Yeah, we can phase out IRC when there are enough static nodes to preprogram a seed list.  Once you get seeded, you don't need IRC.

There were some issues in 0.1.5 where the initial block download could get bogged down.  0.2 has code to make sure it goes smoothly.  It ought to take less than an hour, I think.  I need to hurry up and get 0.2 out the door.

The blocks increase linearly, it'll be decades before it's millions.  In theory, the block download time should top out 8 months from now when Moore's Law will be growing faster than the block chain.

It's SVN on sourceforge.  PM or e-mail me your sourceforge account and I'll give you access.

That's great because that's where I have less expertise.  For instance, I haven't researched the best way to do the "Start Bitcoin on system startup" feature on Linux.  On Windows, the option adds/removes an icon in the Startup folder.

Helpful suggestions, thanks.

That's a good idea.  The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake.  Any portscan would only get a dead connection that doesn't volunteer to identify itself.

I have thought about eventually SSLing all the connections.  I assume anything short of SSL would be pointless against DPI.  Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2.  

That's one of the main things on the agenda after 0.2.

Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.

I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default?

I'm still thinking about how best to structure the management interface.  Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers.  That would be more automation friendly.  Or what about an http interface on some port other than 80 to manage it with a browser?

We've been working hard on improvements for the next version release.  Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:
 - Minimize to system tray option
 - Autostart on boot option so you can keep it running in the background automatically
 - New options dialog layout
 - Setup EXE for Windows, in addition to the archive download

I've been working on a number of refinements to the networking code and laying the groundwork for future functionality.  Also coming in version 0.2:
 - Multi-processor support for coin generation
 - Proxy support

The Linux version is on its way.  Martti's Linux port was merged into the main code branch and New Liberty Standard has been testing it.  It'll be in the next release, version 0.2.

Command line is on the to-do list after 0.2.

--------------------
scott:
Linux/UNIX compile
Posted:Thu 08 of Oct, 2009 (05:49 UTC)

Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great.

> Can nodes on the network tell from which and or to which bitcoin
> address coins are being sent? Do blocks contain a history of where
> bitcoins have been transfered to and from?

Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.

When you send to an IP address, the transaction is still written to a bitcoin address.  The IP address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.

Blocks contain a history of the bitcoin addresses that a coin has been transferred to.  If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.

The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use.  If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under.  If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.

For greater privacy, it's best to use bitcoin addresses only once.  You can change addresses as often as you want using Options->Change Your Address.  Transfers by IP address automatically use a new bitcoin address each time.

> Can nodes tell which bitcoin addresses belong to which IP addresses?

No.

> Is there a command line option to enable the sock proxy the first
> time that bitcoin starts?

In the next release (version 0.2), the command line to run it through a proxy from the first time is:
bitcoin -proxy=127.0.0.1:9050

The problem for TOR is that the IRC server which Bitcoin uses to initially discover other nodes bans the TOR exit nodes, as all IRC servers do.  If you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such:
bitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress>

If someone running a node with a static IP address that can accept incoming connections could post their IP to use for -addnode, that would be great.

> What happens if you send bitcoins to an IP address that has multiple
> clients connected through network address translation (NAT)?

Whichever one you've set your NAT to forward port 8333 to will receive it.  If your router can change the port number when it forwards, you could allow more than one client to receive.  For instance, if port 8334 forwards to a computer's port 8333, then senders could send to "x.x.x.x:8334"

If your NAT can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but I'll look into it.

--------------------
bitcoinbitcoin:
How anonymous are bitcoins?

Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?

There will be a proxy setting in version 0.2 so you can connect through TOR.  I've done a careful scrub to make sure it doesn't use DNS or do anything that would leak your IP while in proxy mode.

It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.

1) During generation (when the status bar says "Generating" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.

2) When you successfully generate a block, it is immediately broadcast to the network.  Other nodes must receive it and link to it for it to be accepted as the new latest block.

Think of it as a cooperative effort to make a chain.  When you add a link, you must first find the current end of the chain.  If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.

After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent.  Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours.  You don't have to be online during that time.

--------------------
anonguy54:
Request: Make this anonymous?
Posted:Thu 15 of Oct, 2009 (19:58 UTC)

Are there any plans to make this service anonymous?

e.g; Being able to route BitCoin through Tor.

--------------------
bitcoinbitcoin:
Bitcoin Maturation
Posted:Thu 01 of Oct, 2009 (14:12 UTC)

From the user's perspective the bitcoin maturation process can be broken down into 8 stages.

1. The initial network transaction that occurs when you first click Generate Coins.
2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.

Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?

--------------------
sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)

As far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating the next proof-of-work.  The CPU usage is 100% when you're generating coins.

In this example, the network connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.

Welcome to the new Bitcoin forum!

The old forum can still be reached here:
http://bitcoin.sourceforge.net/boards/index.php

I'll repost some selected threads here and add updated answers to questions where I can.

FAQ
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ

Download
http://sourceforge.net/projects/bitcoin/files/