On Sun, Aug 23, 2015 at 8:42 AM, Tamas Blummer ta...@bitsofproof.com 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
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
On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc wrote:
On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com
mailto:ta...@bitsofproof.com wrote:
Every re-implementation, re-factoring even copy-paste introduces a risk of
disagreement,
but also open the chance of
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
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
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
On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com 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,
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 lf-li...@mattcorallo.com wrote:
On 08/20/15 21:26, Tamas Blummer wrote:
I know what you mean as I already
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
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
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
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 can
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 the
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
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 e...@voskuil.org wrote:
libsecp256k1 has it's own repository, libbitcoinconsensus doesn't. A
separate repository was what
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 consensus
On Thu, Jul 23, 2015 at 4:57 PM, Milly Bitcoin via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote:
[4] http://lmgtfy.com/?q=mike+hearn+dictatorl=1
Mike has sincerely said that he would like Bitcoin Core to have a
benevolent
17 matches
Mail list logo
