Future of Btcsuite and Btcd?

[bitcartel]

Hi @davecgh,

re: https://blog.companyzero.com/2015/12/iterating-bitcoin/

Sounds like the project is moving to Proof of Activity, as part of a new governance structure. As the consensus model will change, this implies that going forward, the project will be incompatible with Bitcoin.

Will the majority of Btcd developers be focused on this new project or will there still be some resources available to help maintain Btcd in its current form and track Bitcoin developments?

Thanks.

 

[davecgh]

It is a completely separate project that has already been under development concurrently with btcsuite by a different team for a while now. Those of us on btcsuite will remain and are still fully committed to continue developing it.

Also, another benefit will be the symbiotic relationship between the two since the other project is based on btcsuite, it shares a lot of the same code. That in turn means that many enhancements that happen to btcsuite will be able to benefit the other project and vice versa.

To that point, I would expect there are quite a few PRs coming to btcsuite as a result of the work done by the other team once it's all public.

 

[bitcartel]

Thanks for you reply. So with respect to a version of BU based on btcd, what would be the way forward? Create patches and submit PRs to btcd - assuming all features are opt-in? Or maintain a separate fork of btcd?

 

[davecgh]

Good question!

I think that probably mostly depends on the intended class of changes of BU will end up making. For example, an option to remove the block size limit completely (as I understand is one of the aims of the BU project) I think makes sense as a separate option. However, a change that completely changes the fundamental properties of Bitcoin such as moving to a different Proof-of-X system probably wouldn't make much sense as an option.

As I've said elsewhere, I don't believe developers should be dictating economic policy and I'm all for the idea of giving all stakeholders a choice, so I want to make sure this doesn't come across otherwise. That said, one thing I would be concerned about from a BU perspective is usability. A plethora of flags that all are consensus incompatible has a lot of implications in regards to maintenance complexity and usability alike.

Given that, I suspect something like a single flag that enables the BU ruleset would be much more usable than a series of flags which all modify consensus in different incompatible ways. For example, compare `--ruleset=bitcoinunlimited` versus something like `--rulea --ruleb --rulec --notruled`, etc. If there is desire to have some combination, then perhaps even having different bitcoin unlimited rulesets would make sense. The key point I'm making though is I think it's much more usable to have rulesets as opposed to individual flags that create a quadratic scaling issue in regards to options.

 

[Zangelbert Bingledack]

@davecgh

Thoughts on this BUIP?

 

[davecgh]

@Zangelbert Bingledack

I responded in the linked thread. Thanks for the ping.

 

[bitcartel]

@davecgh Are you solely focused on Btcsuite or will you be helping out on Decred? It would be interesting to take some of the Decred features (where it makes sense) and port them to Btcsuite / BU as options for users to enable if they wiseh.
https://www.decred.org/

 

[Zangelbert Bingledack]

@davecgh

I was more wondering you had any thoughts on putting BU-style options into Btcd? (Blocksize especially)

 

[davecgh]

@bitcartel Yes, I personally am focused on btcsuite. I did have varying levels of design input on some of the decred features and it will end up gaining all of my new database and chain optimizations, multi-peer support, and other code that is in the pipeline. As was also previously mentioned, it is also based off the btcsuite code base, so there is quite a lot of my code in there as well. However, outside of that, I haven't personally done any of the new code on it short of helping with some optimizations and other minor fixes that were found in btcsuite during decred development.

As far as porting changes back and forth, that is the plan both once the code goes public and moving forward. For example, I know there are some refactoring changes around the proof of work and chain packages which further abstract some things making them easier to change for alts (which could also apply to BU). Also, if things go well with decred, it will be self funding, so it will likely end up getting most of the new features first by virtue of having more paid developers on it. Since it's a common code base, those changes should be fairly easily back ported to btcsuite.
[doublepost=1451526024][/doublepost]@Zangelbert Bingledack

Oh, I'm not against providing rulesets (options) at all. I already have plans to add BIP101 support to it, but I ended up running into some issues on the utxo cache I'm working on that made it take longer than I thought, so I haven't got to it yet.

 

[bitcartel]

Thanks for the update @davecgh. Would you be up for running a btcd-unlimited project? Or would you prefer if someone else managed the process while you provide input/help when required so that the project tracks btcd as closely (and as cleanly) as possible?

 

[davecgh]

Ideally the BU options could simply be added to btcd as something like `--ruleset=bu`. I realize however that might not be possible depending on the changes that end up being made.

If there is to be a separate btcd-unlimited project, it would have to managed by someone else as I unfortunately don't have any additional bandwidth to take on another project at the moment. I would certainly be happy to provide any input needed when required however and think it's a great idea to have a btcd-unlimited in one form or another. I think having multiple implementations fits in very well with both the BU mindset and our own.

 

[Zangelbert Bingledack]

@davecgh

Rather than trying to copy what the BU team is doing, how about just incorporating some of the approach/philosophy? Practically, it would just mean not locking down the blocksize settings (or whatever consensus parameters you find controversial).

I see BU as more of a movement, a flowering of the division of labor in the industry. Instead of miners and nodes "hiring" developers for their guidance on consensus parameters, they only hire them for the other aspects of the code. The idea is that it's time to unbundle the consensus-parameter-setting and let clients just be services that allow users to set the consensus parameters such that consensus is emergent - its value maximization enforced by billions of dollars' worth of economic incentive to get it right, its uniformity enforced by the overwhelming game-theoretic incentives for uniformity.

The hope is that Core will "BU-ize" itself more and more, as will btcd, XT, and so on. Not meaning that they will take on the specific settings of BU (oversize block acceptance depth, etc.), but that they will step back from the approach of locking down the consensus parameters (at least when there's a controversy).

 

[davecgh]

I definitely agree with trying to keep it within the existing project if possible. That is why I said "Ideally the BU options could simply be added to btcd...". However, since @bitcartel was asking about the possibility for a separate project, I was addressing that if such a thing were to happen, I personally don't have the bandwidth to manage it.

Part of my goal when doing BIP101 will be to move the block size check out of wire into the next higher layer. Mainly, that is required for BIP101 (and several others) since they essentially make the block size dependent on the current chain position whereas today it's just a constant and thus the wire package enforces it. Once that change is made, options related to block size such as the other BIPs and even completely unlocking it (naturally there is still the maximum protocol message size limit of 32MB, so it would still be limited by that) would be fairly easy to implement.

 

[Zangelbert Bingledack]

@davecgh

Are you in support of Classic's move to 2MB for now in btcd? It might help to publicize it if you are.