BitcoinTalk

A few suggestions

8
Satoshi-only
BitcoinTalk
#1
From:
madhatter
Subject:
A few suggestions
Date:
Hey,

First off I must say that this is an amazing concept. I have been dreaming of a P2P money system for a LONG time.

You have my complete kudos and respect.

I have a few suggestions:

- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.

- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.

- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.

- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).

- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.

- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).

Smiley
BitcoinTalk
#2
From:
satoshi
Subject:
Re: A few suggestions
Date:
Helpful suggestions, thanks.

Quote from: madhatter on December 09, 2009, 05:34:46 AM
- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
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.

Quote
- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.
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.  

Quote
- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.
That's one of the main things on the agenda after 0.2.

Quote
- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).
Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.

Quote
- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.
I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default?

Quote
- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).
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?

BitcoinTalk
#3
From:
nanaimogold
Subject:
Re: A few suggestions
Date:
Thank you for this effort. A P2P payment system has been needed for a long time.

Shane
BitcoinTalk
#4
From:
The Madhatter
Subject:
Re: A few suggestions
Date:

Most modern P2P software tries UPnP by default. You can (of course) disable it (usually) in the options.

Hmm. I had thought about that as well. Your first idea is probably best. That way you can run the server daemon "headless" and have your choice of a front end. (One of the front ends could be a PHP [or C++ CGI] program that runs on your favorite webserver).

This would also enable you to run the front end and back end on different machines. (Ex. headless on a linux server that has a static IP to make receiving payments easier [pay by ip mode] and a front end client for management that can be ran on windows/mac/or something else). Front ends can also be ran on clients with very low cpu power such as mobile phones. *nudge nudge* Wink

One other thing I have thought of is the seeding. The app could be pre-seeded before downloading. You could prepare a new archive daily that is pre-seeded. That would do away with the IRC connection. (Or it could be used as a fallback, I suppose. I still haven't audited the IRC connection code. I am thinking of a few exploits but I don't want to mention them until I am sure they exist.) Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR. Tongue

Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).

Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out. I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.

Cheers! Smiley

Quote from: satoshi on December 09, 2009, 06:45:10 PM

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?


BitcoinTalk
#5
From:
satoshi
Subject:
Re: A few suggestions
Date:
Quote from: madhatter2 on December 10, 2009, 02:00:17 PM
Front ends can also be ran on clients with very low cpu power such as mobile phones.
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.

Quote
The app could be pre-seeded before downloading. Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.
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.

Quote
Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).
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.

Quote
Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.
It's SVN on sourceforge.  PM or e-mail me your sourceforge account and I'll give you access.

Quote
I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.
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.
BitcoinTalk
#6
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Okay, let me get registered on SF and get you my username. I haven't used SF in years so I'll have to familiarize myself. Will this give me access to the current branch you fellows are currently working on? (0.2)

I have been trying to think of the options that will be needed for the backend process. I wonder which would be better: a long set of command line switches or a configuration file. Hmm...

I have a lot of servers spread across the globe. If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.

I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).

I think that a simple network monitor plugin for Nagios would be helpful as well. Something that can emulate a connecting client, and retrieve a valid status code from the backend process. I have a lot of ideas. Smiley

In any event, I would like to help. I have a lot of time and a project like this one is very exciting.

Thanks for letting me be a part of it. Smiley
BitcoinTalk
#7
From:
satoshi
Subject:
Re: A few suggestions
Date:
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.

Quote from: madhatter2 on December 11, 2009, 04:59:19 AM
If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.
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.

Quote
I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).
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.  

Quote
In any event, I would like to help. I have a lot of time and a project like this one is very exciting.
That's great, any help is really appreciated!
BitcoinTalk
#8
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! Wink I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.

I already run a great deal of TOR and I2P nodes so for me to add this app to those same servers is a snap. Smiley

I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.

I'll keep toying around with the source code and see what I can come up with.

Smiley
BitcoinTalk
#9
From:
SmokeTooMuch
Subject:
Re: A few suggestions
Date:
Suggestion :

Since the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.

So, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA.
BitcoinTalk
#10
From:
satoshi
Subject:
Re: A few suggestions
Date:
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.
BitcoinTalk
#11
From:
satoshi
Subject:
Re: A few suggestions
Date:
Quote from: madhatter2 on December 12, 2009, 06:34:21 AM
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! Wink I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
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.

Quote
I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.
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.
BitcoinTalk
#12
From:
sirius
Subject:
Re: A few suggestions
Date:
Quote from: madhatter2 on December 12, 2009, 06:34:21 AM
given any thought to using autoconf?

I'd choose cmake instead of autoconf if we want build automation at some point.
BitcoinTalk
#13
From:
SmokeTooMuch
Subject:
Re: A few suggestions
Date:
Suggestion:

Add IPv6-Support for payments.
BitcoinTalk
#14
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Okay, Mac PPC is EOL now anyway. Console mode would be awesome.
BitcoinTalk
#15
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Um, so command line only mode could be selected at compile-time? Perhaps with a define? And that would shut off the graphical UI stuff?

Just want to be on the same page here. Smiley
BitcoinTalk
#16
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
One quick question about "natural deflation" (as I call it). I have noticed that it is possible to spend to old addresses that no longer work. In essence the coins can not be claimed. Wouldn't there be a natural deflation effect because of this? I mean if the coins max out at 21,000,000 wouldn't the number of coins slowly work backwards due to payment errors?
BitcoinTalk
#17
From:
satoshi
Subject:
Re: A few suggestions
Date:
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.
BitcoinTalk
#18
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Okay, thanks for the tips. I am going to try running bitcoin 0.2/svn on FreeBSD tonight in console-only mode. I'll create some notes / patches / etc.
BitcoinTalk
#19
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Got it working on FreeBSD! I'll submit my work here soon.

$gmake -f makefile.fbsd     
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o headers.h.gch headers.h
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/util.o util.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/script.o script.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/db.o db.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/net.o net.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/main.o main.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/market.o market.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/ui.o ui.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/uibase.o uibase.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -O3 -o obj/sha.o sha.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o obj/irc.o irc.cpp
g++ -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I"/usr/include" -I"/usr/local/include" -I"/usr/local/include/db47" -I"/usr/local/include/wx-2.8" -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8" -o bitcoin -L"/usr/lib" -L"/usr/local/lib" -L"/usr/local/lib/db47" obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o obj/ui.o obj/uibase.o obj/sha.o obj/irc.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l wx_base-2.8 -l wx_gtk2_core-2.8 -l wx_gtk2_html-2.8 -l wx_gtk2_richtext-2.8 -l crypto -l gtk-x11-2.0 -l gthread-2.0 -l SM
$ file ./bitcoin
./bitcoin: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, not stripped
BitcoinTalk
#20
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Can anyone shed some light here?

g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:421: error: no matching function for call to 'CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*&, <anonymous enum>, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
uibase.h:673: note: candidates are: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int)
uibase.h:651: note:                 CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(const CGetTextFromUserDialogBase&)
ui.h:423: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)
ui.h:424: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
ui.h:428: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
make: *** [headers.h.gch] Error 1
BitcoinTalk
#21
From:
satoshi
Subject:
Re: A few suggestions
Date:
Quote from: madhatter2 on December 14, 2009, 03:01:39 PM
Can anyone shed some light here?

g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
...
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)

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__"
BitcoinTalk
#22
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Okay, I will look into the std::string issue. It is also throwing the same std::string issue on the latest version of Ubuntu Linux. So this isn't just OSX related. I have to say that my main background is C, not C++ so I am still learning some of the C++ data types/headers/and other specifics "as I go". Smiley

There are only defines for __WXCOCOA__ and __WXMAC__ in wx/defs.h (I must be missing something here..maybe my wxwidgets needs to be rebuilt -- I'll try that). I have tried combinations of those existing defines without success. The other option is to use gtk on OSX but the windowing will be slower and (my opinion) "ugly". Carbon would be the best selection for OSX.  I'll keep hacking at it until I get it working. Smiley

I also now have a working startup script for FreeBSD that will launch xorg's virtual framebuffer onto the localhost, fire up bitcoin and have the X11 screen output get stuffed into memory (instead of the monitor). This is a real big hack, but it does enable someone to run bitcoin as a pseudo unix daemon. I have had the code running for over 12h now and I don't detect any memory leaks or other weirdness.

Also I have a simple network monitor that will detect if bitcoin has crashed/stopped responding on port 8333, send me a page, and start the daemon back up again. This setup is ideal. I have started deploying seeds on servers I control that are all over the world. Smiley

One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?

I will include these tools once I get SF setup.

Cheers!
BitcoinTalk
#23
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
Okay, I am on SF now. Username "madhatter2".

Smiley
BitcoinTalk
#24
From:
satoshi
Subject:
Re: A few suggestions
Date:
Quote from: madhatter2 on December 15, 2009, 05:21:09 AM
It is also throwing the same std::string issue on the latest version of Ubuntu Linux.
Then it must be something you're doing differently with building or configuring wxWidgets.

What options did you use on the wxWidgets "configure" script?  The options I used are in build-unix.txt.

Quote
One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?
Never heard of that happening.  Is there anything in debug.log?  If you touched the file, that sounds like something is there.  Does the program have write access to the file?
BitcoinTalk
#25
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
I used the default build options. I will try the options from your txt file. On FreeBSD it just worked right from the normal ports system. Which is excellent. It means that installing bitcoin via the same ports system (my goal) will be a snap.

Yes, the debug.log has the proper permissions. I'll re-read the source. There must be something I am missing.
BitcoinTalk
#26
From:
sirius
Subject:
Re: A few suggestions
Date:
I worked around the string problem by using wxWidgets 2.9. It worked with the default configuration.
BitcoinTalk
#27
From:
The Madhatter
Subject:
FreeBSD build patch
Date:
[madhatter@10 /home/madhatter/src/bitcoin]# diff -u headers.h.orig headers.h     
--- headers.h.orig      2009-12-14 12:29:39.000000000 +0000
+++ headers.h   2009-12-14 12:41:08.000000000 +0000
@@ -35,7 +35,12 @@
 #include <limits.h>
 #include <float.h>
 #include <assert.h>
+#ifndef BUILD_FREEBSD //malloc.h is part of stdlib.h on FreeBSD
 #include <malloc.h>
+#endif
+#ifdef BUILD_FREEBSD
+#include <netinet/in.h>
+#endif
 #include <memory>
 #define BOUNDSCHECK 1
 #include <sstream>

[madhatter@10 /home/madhatter/src/bitcoin]# cat makefile.fbsd
# Copyright (c) 2009 Satoshi Nakamoto
# Distributed under the MIT/X11 software license, see the accompanying
# file license.txt or http://www.opensource.org/licenses/mit-license.php.


ifneq "$(BUILD)" "debug"
ifneq "$(BUILD)" "release"
BUILD=debug
endif
endif
ifeq "$(BUILD)" "debug"
D=d
DEBUGFLAGS=-g
endif



INCLUDEPATHS= \
 -I"/usr/include" \
 -I"/usr/local/include" \
 -I"/usr/local/include/db47" \
 -I"/usr/local/include/wx-2.8" \
 -I"/usr/local/lib/wx/include/gtk2-ansi-release-2.8"

LIBPATHS= \
 -L"/usr/lib" \
 -L"/usr/local/lib" \
 -L"/usr/local/lib/db47"

LIBS= \
 -Wl,-Bstatic \
   -l boost_system -l boost_filesystem \
   -l db_cxx \
 -Wl,-Bdynamic \
   -l wx_base-2.8 \
   -l wx_gtk2_core-2.8 \
   -l wx_gtk2_html-2.8 \
   -l wx_gtk2_richtext-2.8 \
   -l crypto \
   -l gtk-x11-2.0 -l gthread-2.0 -l SM

WXDEFS=-D__WXGTK__ -DNOPCH -DBUILD_FREEBSD
CFLAGS=-O0 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(WXDEFS) $(INCLUDEPATHS)
HEADERS=headers.h util.h main.h serialize.h uint256.h key.h bignum.h script.h db.h base58.h



all: bitcoin


headers.h.gch: headers.h $(HEADERS) net.h irc.h market.h uibase.h ui.h
        g++ -c $(CFLAGS) -o $@ $<

obj/util.o: util.cpp                $(HEADERS)
        g++ -c $(CFLAGS) -o $@ $<

obj/script.o: script.cpp            $(HEADERS)
        g++ -c $(CFLAGS) -o $@ $<

obj/db.o: db.cpp                    $(HEADERS) market.h
        g++ -c $(CFLAGS) -o $@ $<

obj/net.o: net.cpp                  $(HEADERS) net.h
        g++ -c $(CFLAGS) -o $@ $<

obj/main.o: main.cpp                $(HEADERS) net.h market.h sha.h
        g++ -c $(CFLAGS) -o $@ $<

obj/market.o: market.cpp            $(HEADERS) market.h
        g++ -c $(CFLAGS) -o $@ $<

obj/ui.o: ui.cpp                    $(HEADERS) net.h uibase.h ui.h market.h
        g++ -c $(CFLAGS) -o $@ $<

obj/uibase.o: uibase.cpp            uibase.h
        g++ -c $(CFLAGS) -o $@ $<

obj/sha.o: sha.cpp                  sha.h
        g++ -c $(CFLAGS) -O3 -o $@ $<

obj/irc.o: irc.cpp                  $(HEADERS)
        g++ -c $(CFLAGS) -o $@ $<




OBJS=obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o \
        obj/ui.o obj/uibase.o obj/sha.o obj/irc.o

bitcoin: headers.h.gch $(OBJS)
        g++ $(CFLAGS) -o $@ $(LIBPATHS) $(OBJS) $(LIBS)

clean:
        -rm obj/*
        -rm headers.h.gch
BitcoinTalk
#28
From:
The Madhatter
Subject:
Re: A few suggestions
Date:
To build on FreeBSD:

Install all of the required software from /usr/ports and then compile using the makefile.fbsd

"It just works". Smiley
BitcoinTalk
#29
From:
satoshi
Subject:
Re: A few suggestions
Date:
That's good, is it running fine on FreeBSD?

I committed the changes to headers.h.  For consistency, I used __BSD__.  The complete list of defines is at http://docs.wxwidgets.org/stable/wx_cppconst.html
#ifdef __BSD__
#include <netinet/in.h>
#endif

malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble.
BitcoinTalk
#30
From:
The Doctor
Subject:
Re: A few suggestions
Date:
Hi.  I would like to second the headless/non-GUI mode for /*nix/i systems.  It would be useful to be able to start the Bitcoin software from an initscript or one's ~/.bashrc (or equivalent) file and let it run in the background, silently cranking away.

Also, what would the feasibility of changing the location of the wallet.dat file be for the Win32 client?  I ask this because I was playing around with the .zipped Windows Bitcoin client yesterday, and it struck me that it would make a good portable application.  I was toying with the idea of decompressing it into a TrueCrypt volume on a USB drive so that it could, say, be taken on the road, run for a few hours, and then shut down just before the volume was unmounted, but it created the wallet.dat file in the C:\Documents and Settings\username\Application Data\Bitcoin directory.  In effect, using a portable version of Bitcoin to eventually grow a portable wallet.
BitcoinTalk
#31
From:
satoshi
Subject:
Re: A few suggestions
Date:
What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized.  The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI.  Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty.

We didn't have time to implement the "Start Bitcoin on system startup" feature on Linux in time for 0.2 so it's greyed out.  I figured Linux people wouldn't mind doing that manually anyway.  I guess they need to know about the -min switch to do it right.

You can locate the data directory where you want with the "-datadir=<directory>" switch.  I know someone is already doing that to put it on a TrueCrypt USB drive.