Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer wrote: > I see the huge amount of sweat and love that went into core and it actually > hurts to see that most is expended in friction and lack of a vision for the > software architecture. > > To be concrete, this was my plan if dealing with the Core c

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I completely agree and I share your frustration. The importance of modularization is often disregarded but in my opinion it has a deep positive impact in the long term: more people are able to contribute with code and review (in the areas they know better), the risks associated with each change bec

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Sat, Aug 22, 2015 at 1:04 PM, Tamas Blummer wrote: > On Aug 21, 2015, at 21:46, Jorge Timón wrote: > > On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer > wrote: > > Every re-implementation, re-factoring even copy-paste introduces a risk of > disagreement, > but also open the chance of doing th

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I see the huge amount of sweat and love that went into core and it actually hurts to see that most is expended in friction and lack of a vision for the software architecture. To be concrete, this was my plan if dealing with the Core code base: 1) I'd consider the separation of networking and st

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

One thing it occurs to me (and I don't know if this has been suggested before) we could do is separate the BIP process into at several distinct areas: 1) Commit structure changes/consensus rule change proposals - Consensus-building process (how are proposals debated, improved, vetted, and selected

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I've been pushing for greater modularization since I first got into bitcoin. I got quickly frustrated when I was only able to get through very few things (i.e. moving core structure serialization classes to a separate unit not called main). Working on Bitcoin has an added layer of frustration that

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

> On Aug 21, 2015, at 21:46, Jorge Timón wrote: > > On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer > wrote: >> Every re-implementation, re-factoring even copy-paste introduces a risk of >> disagreement, >> but also open the chance of doing the work better, in the

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Unfortunately we have no way of rigorously proving functional equivalence other than code review and unit testing. The simpler the consensus code (and the more we can write it in a style that affords provability of correctness) the easier it will be in the future to compare implementations. Prior

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer wrote: > Every re-implementation, re-factoring even copy-paste introduces a risk of > disagreement, > but also open the chance of doing the work better, in the sense of software > engineering. But you don't want something better, you want somethin

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Thinking in Bitcoins only on the level of technology unnecessarily narrows your view. OK, I hope to be pleasantly surprised. Tamas Blummer > On Aug 20, 2015, at 23:35, Matt Corallo wrote: > > > > On 08/20/15 21:26, Tamas Blummer wrote: >> I know what you mean as I already have such a compon

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 08/20/15 21:26, Tamas Blummer wrote: > I know what you mean as I already have such a component with pluggable > block store and networking. I'm not suggesting pluggable networking, I'm suggesting (and I think everyone thinks the design should be) NO networking. The API is ValidationResult lib

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I know what you mean as I already have such a component with pluggable block store and networking. While you are at it you could aim for isolation of bitcoin specific decisions and algos from generic block chain code. The magnitude of refactoring you would have to do to get there from main.cpp

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I dont think a libconsensus would have any kind of networking layer, nor is C++ an antique tool set (hopefully libconsensus can avoid a boost dependency, though thats not antique either). Ideally it would have a simple API to give it blocks and a simple API for it to inform you of what the current

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement, but also open the chance of doing the work better, in the sense of software engineering. > On Aug 20, 2015, at 10:06, Jorge Timón wrote: > > > But the goal is not reimplementing the consensus rules but ra

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Aug 20, 2015 at 9:14 AM, Tamas Blummer wrote: > Jorge, > > separating script engine into libconsensus was very helpful, since wrapped > the piece of consensus > that would least likely to be captured exactly with an implementation from > scratch. Thank you for your > effort there. Bits of

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Jorge, separating script engine into libconsensus was very helpful, since wrapped the piece of consensus that would least likely to be captured exactly with an implementation from scratch. Thank you for your effort there. Bits of Proof now uses its own or alternatively libconsensus for full va

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Moving it here from the other thread. On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil wrote: > On 08/19/2015 04:27 PM, Jorge Timón wrote: >> No, as previously explained, once libconsensus is complete it can be >> moved to a separate repository like libsecp256k1. > > I don't see this happening any t

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Wed, Jul 29, 2015 at 10:38 PM, Eric Voskuil wrote: > On 07/28/2015 02:58 AM, Jorge Timón wrote: > Oh, I misunderstood your ask then. I don't have a preference on > prioritizing VerifyTx vs VerifyHeader. Ok, let's assume we want to expose verifyHeader first (which I think will be easier). >> w

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 07/28/2015 02:58 AM, Jorge Timón wrote: >> I haven't looked at any of these commits, but I'll make some time to at >> least give a cursory review. > > Great. I mean, I wasn't asking about reviewing the commits themselves > (which is also great if you do), but rather on answering the questions >

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Tue, Jul 28, 2015 at 10:43 AM, Wladimir J. van der Laan 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 >> libsec

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

Ok, I'm going to separate terms: current-libconsensus from theoretical future-libconsensus (implementing ALL consensus rules). On Tue, Jul 28, 2015 at 8:40 AM, Eric Voskuil wrote: > libsecp256k1 has it's own repository, libbitcoinconsensus doesn't. A > separate repository was what I considered a

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Mon, Jul 27, 2015 at 11:40:42PM -0700, Eric Voskuil via bitcoin-dev wrote: > It's a performance sacrifice, and then there's the OpenSSL dependency, > but these are both optional within our stack - so the application > developer has the option. So the only downside is that we are > maintaining t

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Jul 23, 2015 at 04:30:06PM +0200, Jorge Timón via bitcoin-dev wrote: > I think there were some misunderstandings in our previous conversation > about this topic. > I completely agree with having a separated repository for libconsensus > (that's the whole point, alternative implementations

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 07/23/2015 07:30 AM, Jorge Timón wrote: > On Thu, Jul 23, 2015 at 2:49 AM, Eric Voskuil via bitcoin-dev wrote: >> On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote: >>> Only being partly serious - I strongly am in favor of a sufficiently >>> modularized codebase that swapping out conse

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

> Mike has sincerely said that he would like "Bitcoin Core to have a > benevolent dictator like other free software projects", and I wanted > to make clear that I wasn't putting words in his mouth He is just pointing out reality. Decentralization is really just a collection of centralized proces

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Jul 23, 2015 at 4:57 PM, Milly Bitcoin via bitcoin-dev wrote: > On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote: > >> [4] http://lmgtfy.com/?q=mike+hearn+dictator&l=1 Mike has sincerely said that he would like "Bitcoin Core to have a benevolent dictator like other free software p

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote: [4] http://lmgtfy.com/?q=mike+hearn+dictator&l=1 ___ You spend too much time on reddit. All this drama queen stuff is getting ridiculous. Russ __

[bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Jul 23, 2015 at 2:49 AM, Eric Voskuil via bitcoin-dev wrote: > On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote: >> Only being partly serious - I strongly am in favor of a sufficiently > modularized codebase that swapping out consensus rules is fairly > straightforward and easy