strip the reference client to a border router

[wumpus]

Is it possible to build a "no dependency" client? Just integrate all (and only) necessary external codes, e.g. SSL, so people can build it without depending on any package.

You could use sipa's secp256 library instead of OpenSSL, that makes the blockchain handling code less dependent of third parties: https://github.com/sipa/secp256k1 (as a bonus, it's faster too!)
Note: this is at your own risk, the library is far from as well-tested as OpenSSL is. Handling cryptography is very fickle and a decision to switch the main client over is not taken lightly.

We agree that modularization is a goal, my question is if we should we tackle it with highest priority.

That's up to you! Everyone in the core team has their own priorities, and they may or may not overlap with yours (though we all agree that modularization is a good thing, but it's just not our pet project). You're welcome to join and patches are welcome!

[1538090378]

1538090378

[1538090378]

1538090378

[1538090378]

1538090378

[piotr_n]

Is it possible to build a "no dependency" client? Just integrate all (and only) necessary external codes, e.g. SSL, so people can build it without depending on any package.

With this code, just getting rid of boost seems quite impossible.

LevelDB - one would need to create a new db engine, from scratch, wanting to get rid of this one.
But LevelDB is an internal code already, so I guess it could stay. It's a fairly simple one and easy to audit.

As for OpenSSL - I guess you could embed the hashing functions into the code and use the ecdsa functions made by sipa.

The rest (berkeley, upnp, zlip, png & qr) should be much easier to remove.

EDIT:
Oh, wait... WTF is protobuf?
You guys are not giving up adding more crap in, are you?

[wumpus]

With this code, just getting rid of boost seems quite impossible.

Until the parts that we use of boost are part of the C++ library (which may happen in the future), getting rid of boost is not even a goal.
This means cross-platform thread handling, synchronization handling, asynchronous network handling, etc.
The only other option would be to embed cross platform compatibility layers in the code base itself, but that would increase the amount of code  (NIH syndrome) to audit, test and maintain not decrease it.

C++ is just not a good language if you want self-contained code. There are no batteries included. This improved with C++11 though and we do plan on switching over to that and using C++11 functionality where appropriate instead of boost.

[wumpus]

EDIT:
Oh, wait... WTF is protobuf?
You guys are not giving up adding more crap in, are you?

Protobuf is only used for the GUI (payment requests) and not for the core, so it is already optional. The only required external dependencies for the core are:

- boost (extended C++ library)
- berkelydb (wallets, would be nice if this was optional when nowallet mode is used)

And one of
- OpenSSL
- secp256k1 library

Believe me, that's not a lot for an open source project.

[piotr_n]

With this code, just getting rid of boost seems quite impossible.

Until the parts that we use of boost are part of the C++ library (which may happen in the future), getting rid of boost is not even a goal.

Yeah. Part of the C++ library, which I need like an hour to build.

EDIT:
Oh, wait... WTF is protobuf?
You guys are not giving up adding more crap in, are you?

Protobuf is only used for the GUI (payment requests) and not for the core, so it is already optional.

I thought someone once said here that the payment protocol does not add any more external libs.
Well, I guess he was wrong again...

[jl2012]

Is it possible to build a "no dependency" client? Just integrate all (and only) necessary external codes, e.g. SSL, so people can build it without depending on any package.

You could use sipa's secp256 library instead of OpenSSL, that makes the blockchain handling code less dependent of third parties: https://github.com/sipa/secp256k1 (as a bonus, it's faster too!)
Note: this is at your own risk, the library is far from as well-tested as OpenSSL is. Handling cryptography is very fickle and a decision to switch the main client over is not taken lightly.

We agree that modularization is a goal, my question is if we should we tackle it with highest priority.

That's up to you! Everyone in the core team has their own priorities, and they may or may not overlap with yours (though we all agree that modularization is a good thing, but it's just not our pet project). You're welcome to join and patches are welcome!

Can we just embed the relevant part of OpenSSL to the code, so we don't need to worry about compatibility?

[piotr_n]

Can we just embed the relevant part of OpenSSL to the code, so we don't need to worry about compatibility?

Personally, I would rather advise you to replace it with the code made by sipa, so you would not need to worry about NSA backdoors

[Pieter Wuille]

Can we just embed the relevant part of OpenSSL to the code, so we don't need to worry about compatibility?

Personally, I would rather advise you to replace it with the code made by sipa, so you would not need to worry about NSA backdoors

In due time. At this point, it hasn't by far received enough auditing to become responsible for securing millions of dollars in transfers.

[piotr_n]

Can we just embed the relevant part of OpenSSL to the code, so we don't need to worry about compatibility?

Personally, I would rather advise you to replace it with the code made by sipa, so you would not need to worry about NSA backdoors

In due time. At this point, it hasn't by far received enough auditing to become responsible for securing millions of dollars in transfers.

It's an admirable stand, but we are talking about wallet-less node here and something that only a small percentage of the net would use anyway.

I don't see a potential for a big damage - the worst thing that can happen is a chain fork, that would only speed up the process of maturing your fine lib.

If someone wants to secure receiving millions of dollars, I'd rather advise him to use more than one node while making sure that he received the money - a totally different ones, using not only different ECDSA libs, but basically different everything. And run them on different PCs..

[kjj]

Is it possible to build a "no dependency" client? Just integrate all (and only) necessary external codes, e.g. SSL, so people can build it without depending on any package.

Just FYI, I routinely make static-ish builds.  My mining distro is based on Debian, but the bitcoind binary on it is build on an ancient slackware box with wildly different libraries.  Fudging the makefile for a static build gives me a binary that will run just about anywhere.

On the original topic, rather than a fork, why not build options?  This would reduce the maintenance delta to a hopefully manageable level.  It is even something that could be done incrementally.