strip the reference client to a border router - page 2.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: Mike Hearn on October 07, 2013, 02:25:26 PM

The Satoshi client does have a kind of internal API, if you look at how the wallet and GUI interacts with the rest of the code then you can see it. It's not perfect but polishing it hardly seems the highest priority.

I think you're right that lots of people use their software connected to a trusted Satoshi node that they run themselves, but realistically the wallet and GUI aren't just going to be deleted from the core Bitcoin code - people use them!

I wish for an isolation much higher than a more or less defined set of function signatures and structures within the same code base.
Such isolation was not a goal for Satoshi and is apparently not a priority for the core team.

I suggested such a fork (of code) to reduce the pain of code reviews and increase the pace of innovation.
It would come at a cost. Do you think it is feasible to branch and regularly rebase such a code subset for a "border router" ?

Mike Hearn

legendary

Activity: 1526

Merit: 1129

The Satoshi client does have a kind of internal API, if you look at how the wallet and GUI interacts with the rest of the code then you can see it. It's not perfect but polishing it hardly seems the highest priority.

I think you're right that lots of people use their software connected to a trusted Satoshi node that they run themselves, but realistically the wallet and GUI aren't just going to be deleted from the core Bitcoin code - people use them!

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: gweedo on October 07, 2013, 12:50:36 PM

https://github.com/jgarzik/pynode this is kinda what you are talking about, this would be better suited than stripping out things from the reference client, which would be the hacky way to do this.

Thinks I have that kinda stuff too, check my signature.

The question is if we want more that kind of stuff or rather make satoshi welcoming to extensions.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: gmaxwell on October 07, 2013, 12:46:02 PM

If Gavin was interested in (/thought his time was best spent on) those other things he would spent them on them. You can't dictate how Gavin spends his time by creating a fork.

I certainly can't or want to dictate what he does or doesn't. We could however lower the barrier for those who could do stuff that does not require in depth knowledge of the real core, so he gets more help and can consider if that is where he want to be (too).

Quote from: gmaxwell on October 07, 2013, 12:46:02 PM

As an aside, though the code ends up in the same binary, as I recall the payment protocol didn't touch consensus mechanism stuff, it was largely self contained and nowhere near the core stuff. Increased modularity is a long term goal to making review easier, though it's currently come a long way from the original code that freely intermixed the GUI wallet stuff with the consensus code.

Even if it is better separated than older cross-cutting concepts, would't be nice if it was built on top of an API isolating the consensus layer and be in a separate project?

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

gweedo

legendary

Activity: 1498

Merit: 1000

https://github.com/jgarzik/pynode this is kinda what you are talking about, this would be better suited than stripping out things from the reference client, which would be the hacky way to do this.

gmaxwell

staff

Activity: 4172

Merit: 8419

If Gavin was interested in (/thought his time was best spent on) those other things he would spent them on them. You can't dictate how Gavin spends his time by creating a fork.

As an aside, though the code ends up in the same binary, as I recall the payment protocol didn't touch consensus mechanism stuff, it was largely self contained and nowhere near the core stuff. Increased modularity is a long term goal to making review easier, though it's currently come a long way from the original code that freely intermixed the GUI wallet stuff with the consensus code.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

The goal is to
1. better support for feature development without touching or re-implementing functions of the reference client.
2. reduce number of lines of code and complexity in reference client to increase stability and scaleability.

Although wallet or RPC is harmless at runtime if not used, I do believe that every line of extra code is harmful at development as it makes code review and refactoring more complex and risky.

To give a practical example:
I think payment protocol is much needed, but I wish it could be implemented without touching the code base running the consensus and it would be implemented by other than Gavin. His in depth knowledge of the Satoshi code would be better spent on DoS protection and scaleability issues. With a stripped down reference client and a better API that development could be much better outsourced to the community.

gmaxwell

staff

Activity: 4172

Merit: 8419

Wouldn't this increase the amount of software which must be reviewed, tested, patched, and otherwise maintained? Is this just for the sake of removing parts which are largely inactive and harmless when not used?

I often don't understand proposals stated in terms of mechanisms rather than goals. Perhaps the benefits are apparent to those who would want it, but for my sake what benefit(s) would this serve which would justify the costs?

There is already have code to turn off the wallet. If there is a real application for turning off other things I don't see a reason that a fork would be required.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Would you welcome a fork of satoshi aimed to strip it of all but the consensus algorithm, that is without wallet and the RPC replaced with a bus?

Motivation
I recommend using the 'reference' client as border router to the P2P network in production environments, then connect the BOP server inside your company to it, to get a convenient API to Bitcoin in form of a message bus that serves applications and client side wallets.

I guess that above suggestion is not unique to BOP but is how those operate who developed significant added value around satoshi client and wonder if this use case should be the priority for reference client development instead of further extending the feature set of that fragile and crucial code base.

Topic: strip the reference client to a border router - page 2. (Read 1857 times)