On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan <laa...@gmail.com> wrote: > On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Timón via bitcoin-dev wrote: >> But I thought you also wanted Bitcoin Core to use libconsensus instead >> of just having a subtree/subrepository like it currently does with >> libsecp256k1. >> I'm not sure if that would ever be accepted, but in any case we're >> certainly far away from that goal. Here are some things that need to >> happen first: > > I don't see any reason why Bitcoin Core would not use the consensus library. > Eating our own dogfood and such.
As explained to Eric, it's not that I don't want Bitcoin Core to use future-libconsensu through the API instead of a subtree: it's just that that's more long-term and more work. And I don't see why other implementations should really care about it. > Biggest risk, as I've said before, is that the refactoring loading to a (more > complete) consensus library will result in code that is no longer bug-for-bug > compatible with previous versions, thus defeating its entire purpose and > introducing fork risk. > > If that can be avoided - for example by going from here to there using pure > code moves, as you're trying to do - I'm all for it. Well, pure movements will not be enough, parameters will have to change, incompatible dependencies have to be removed (ie util.h which contains globals), etc. But yes, I think we can do it with only low-risk and easy-to-review commits. >> 3) Move libconsensus to a separate repository as a >> subtree/subrepository of Bitcoin Core. > > If the rest is done, this is the easy part :) And still, this doesn't require Bitcoin Core to use the API, a subtree is enough at first. This "easy step" doesn't guarantee that Bitcoin Core is using future-libconsensus' API. > Code review capacity is still our greatest bottleneck. > And I don't see any way out of that, unfortunately. I really think these code separations help with this (ie there are many more people in the world with enough knowledge to review the qt or even policy parts than there's people able to review consensus changes). > I do really care about this. I know and I said so. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
