Bitcoin Forum
October 01, 2016, 04:55:46 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoin is "Growing Up" : Feature Request  (Read 5901 times)
throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 10, 2010, 08:46:50 AM
 #21

add more configuration / command line options:
Quote
  • Address to bind for outgoing connections - required for multihomed hosts with source-based routing, for firewalls also.
  • Address(es) to bind the listening socket (if any at all) for the incoming connections, with port ofcourse! Required for multihomed hosts.
  • For bitcoind - whether to fork and detach or not. BTW, bitcoind does not fully detach from the tty, it receives SIGINT (^C) if run from script. There are lot of UNIX commands to make any program run like a daemon. Don't reinvent the wheel. Perhaps Windows need that?
  • Static list of addresses to exclusively connect to, with ports. Read list from a file, it may be too large for command line.
  • Option to set the externally visible address (if any) with port, and turn off the IP automatic detection via third party services. Let the sysadmin decide what is the correct IP, OK?
  • UNIX-socket based JSON-RPC service, to allow to securely run bitcoind in multiuser environment

PS: Port, to which the listening socket is bound to is not always the same port, that is externally visible to the Internet, especially if you use firewall, so do not always derive one from another, please let the users decide too.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
nimnul
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW
August 10, 2010, 03:34:33 PM
 #22

1) Bundle the first 80% of the blocks with the client download!
   It really hammered the network to slowly distribute the blocks, and a lot of people talked about how annoying a problem this was for new users.
In early versions BitCoin wrote each single block synchronously - according to Satoshi, it flushed disk cache after each block and probably performed other operations required to make writes transactional. That performance problem has been fixed since that.

Also, is it possible for clients to start generating without the whole chain? Could clients download only "last block" (or something like that) and start solving it immediately? The previous blocks would be only necessary to validate that the last block is genuine, and that validation can be performed later.

Quote
2) Disconnect from the IRC when the outside port (8333) isn't connectible.
   We gain NOTHING by having Bitcoin idle on the IRC channel when nobody can connect to it, and we hit the server harder and annoy privacy-minded people.
IRC is often forbidden by hosting TOS, so ability to operate without IRC and to use IRC only when necessary is important. I think we should bundle a host list with bitcoin and client should only try to use IRC if it cannot connect using that list.

Quote
The other request was to drop wxWidgets from the daemon, but having read the code, that seems like too much trouble to do now.
This in fact has already been implemented by Satoshi - building bitcoind does not require wxWidgets any more.[/quote]

My wishlist is:

1) RPM or at least binaries for CentOS (it has incompatible Boost and OpenSSL, so it's hard to build)
2) a pacman package for Arch

3) Pluggable hash cruncher.
4) Pluggable network layer.

5) An alternate implementation in Haskell, Erlang or Node.js (Python is fine too)

6) A graphical front-end to Bitcoind (it would be nice to run bitcoind in background and only run GUI sometimes to check balance/transactions. Now bitcoin cannot operate as a front-end to (a possibly remote) Bitcoind.)

A pluggable hash cruncher will allow one to implement plugins to use BitCoin on MPI clusters, Condor grids, BOINC workers, CUDA, cryptoaccelerators, specific processor features such as found in Via C7, Cray XT4 FPGA nodes, whatever. Also it will allow for slave workers with tiny memory requirements and minimal dependencies. Official bitcoin would send work to the cruncher, and the cruncher would distribute it to slaves and collect results. Slaves would only implement SHA256, so Boost and OpenSSL would not be necessary any more.

BOINC slaves are good because BOINC has much finer detection of idle resources than BitCoin.

A pluggable network layer will allow BitCoin to operate over other networks - for example, over Skype, XMPP/Jabber, Tor (clients could advertise their .Onion addresses instead of ips). It will also allow to switch to a network with higher degree of anonymity in the future if such network emerges and provides transport and node discovery services).

throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 11, 2010, 01:45:23 PM
 #23

Oh yes, how about using autoconf & automake to provide beautiful configure script to generate makefiles,
instead of hand-editing them for every build environment?

Just for the software to be taken seriously by the GNU people.
nimnul
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW
August 11, 2010, 02:11:39 PM
 #24

Autotools are evil. I heard someone was already working on CMake build system for bitcoin. Boost.Build would be fine too, as Bitcoin requires non-header only Boost libraries anyway, and building those libraries (at least Boost.Filesystem) requires Boost.Build to be configured.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 11, 2010, 06:40:59 PM
 #25


You may dislike autotools, but they are supported by every packaging system out there.  Fedora, Debian, Slackware, etc. all have macros and other tools to help with packaging autotool packages.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
nimnul
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW
August 12, 2010, 10:09:48 AM
 #26

Well, Windows (namely, MSVC) doesn't. And autotools are not installed by default, just like CMake, SCons etc. And installing autotools are not any harder than other build systems. So autotools are not better in terms of availability on *nix than any other build tools. Of course having autotools is better than manual make we have now, but I don't see how CMake or Boost.Build are worse.

throughput
Full Member
***
Offline Offline

Activity: 158


View Profile
August 12, 2010, 12:42:51 PM
 #27

Well, Windows (namely, MSVC) doesn't. And autotools are not installed by default, just like CMake, SCons etc. And installing autotools are not any harder than other build systems. So autotools are not better in terms of availability on *nix than any other build tools. Of course having autotools is better than manual make we have now, but I don't see how CMake or Boost.Build are worse.

Don't confuse me!

CMake is not installed by default on my Debian. And MSVC is not installed too Smiley.

autotools are only required to generate configure scripts, they are not needed to build the source distribution
on the build environments.
Only gcc (g++), binutils and GNU make will be required to build from the generated makefile, not other tools.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!