On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil <[email protected]> wrote: > [cross-posted to libbitcoin] > > On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug > 19, 2015 at 10:04 PM, Eric Lombrozo <[email protected]> wrote: >>> But the consensus code should NOT be subject to the same commit > policies…and we should make an effort to separate the two clearly. And > we should find a way to communicate the difference succinctly and > clearly to laypeople (which is something I think the XT opponents have > been horrible at doing so far). >> >> I think that effort is in progress (again, much slower that I would >> like it to be) and it's called libconsensus. >> Once we have libconsensus Bitcoin Core it's just another >> implementation (even if it is the reference one) and it's not "the >> specification of the consensus rules" which is a "privileged" position >> that brings all sorts of misunderstandings and problems (the block >> size debate is just one example). > > Jorge, > > I applaud your efforts and objectives WRT libconsensus independence. But > as you know I differ with you on this point: > >> Once we have libconsensus Bitcoin Core it's just another >> implementation > > I do not consider Bitcoin Core just another implementation as long as > libconsensus is built directly out of the bitcoind repository. It's a > finer point, but an important one. Eric makes this point emphatically as > well: > >>> But the consensus code should NOT be subject to the same commit > policies...and we should make an effort to separate the two clearly. > > As you have implied, it's not likely to happen in the Bitcoin Core repo. > Taking a dependency on Bitcoin Core is a metaphorical deal with the > devil from our perspective. So my question is, how do you expect other > implementations to transition off of that repository (and commit > policies)? Or do you expect the dependency to be perpetual?
No, as previously explained, once libconsensus is complete it can be moved to a separate repository like libsecp256k1. At first it will need to be a subtree/subrepository of Bitcoin Core (like libsecp256k1 currently is), but I still don't undesrtand how that can possibly be a problem for alternative implementations (they can use a subtree as well if they want to). Depending on a separated libconsensus doesn't "make Bitcoin Core a dependency" more than depending on libsecp256k1 currently does. > In our discussion leading up to libbitcoin building libbitcoin-consensus > we disagreed on whether intentional hard forks would (or even could) > happen. I think that issue is now settled. So my question remains how do > stakeholders (users/miners) maintain consensus when it's their > individual intent (the first objective of libconsensus), and diverge > when intended (which a direct dependency on libconsensus makes harder)? > IMO it's unreasonable to operate as if this won't happen, given that it has. I believe the simplest option would be to fork the libconsensus project and do the schism/controversial/contentious hardfork there. But of course modifying libconsensus will be much easier than modifying Bitcoin Core (if anything, because the amount of code is much smaller). > There are a very small number of implementations that rely on consensus > (fewer that aren't also forks of Bitcoin Core). I think it's time we > discuss how to work together to achieve our mutual goal. I assume you > have been in contact with all of us. If you would like to facilitate > this I'd be happy to join in an offline discussion. Unfortunately I only directly contacted libbitcoin because I was subscribed to the list at the time (maybe I'm still subscribed, not really sure). The other attempts to get feedback from other alternative implementations have been just mostly-ignored threads in bitcoin-dev. So, no, I cannot facilitate such a discussion, but I'm more than happy to collaborate to achieve our mutual goal. _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
