Topic: A few suggestions - page 2. (Read 35197 times)

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.

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?

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.

Okay, Mac PPC is EOL now anyway. Console mode would be awesome.

Suggestion:

Add IPv6-Support for payments.

I'd choose cmake instead of autoconf if we want build automation at some point.

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.

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.

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! 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.

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.

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!

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.

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.

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.

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*

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.

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!

Thank you for this effort. A P2P payment system has been needed for a long time.

Shane

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?

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).