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

From: Tamas Blummer <tamas@bitsofproof•com>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
Date: Fri, 21 Aug 2015 08:46:26 +0200	[thread overview]
Message-ID: <DE81C494-FB9F-49FA-9281-BF274345E411@bitsofproof.com> (raw)
In-Reply-To: <55D64806.5060404@mattcorallo.com>

[-- Attachment #1.1: Type: text/plain, Size: 4488 bytes --]

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-lists@mattcorallo•com> wrote:
> 
> 
> 
> 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 libconsensus.HeyIFoundABlock(Block) and
> ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
> 
>> While you are at it you could aim for isolation of bitcoin specific
>> decisions and algos from generic block chain code.
> 
> Are you suggesting to support altcoins? I dont think anyone cares about
> supporting that.
> 
>> The magnitude of refactoring you would have to do to get there from
>> main.cpp and the rest of the hairball
>> is harder than a re-write from scratch,
> 
> I think you'd be very pleasantly surprised. It sounds like you havent
> dug into Bitcoin Core validation code in years.
> 
>> and the result will not be
>> impressive, just hopefully working.
> 
> Hmm? The result would be an obviously correct consensus implementation
> that everyone could use, instead of everyone going off and writing their
> own and either being wrong, or never updating in the case of forks. Its
> a huge deal to allow people to focus on making their libraries have good
> APIs/Wallets/etc instead of focusing on making a working validation
> engine (though maybe for that the p2p layer needs to also be in a library).
> 
>> I think a slim API server was a lower hanging fruit in Core’s case.
> 
> We have one, it just needs a few already obvious performance improvements.
> 
>> BTW, support for refactoring is an example where you see if your tool
>> set is modern.
> 
> There are a number of good development tools for C++ that allow this....
> 
>> Tamas Blummer
>> 
>>> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org
>>> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>> 
>>> 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 chain is. If you really want to get fancy maybe it has
>>> pluggable block storage, too, but I dont see why you couldnt use this in
>>> ~any client?
>>> 
>>> On 08/20/15 08:35, Tamas Blummer via bitcoin-dev 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.
>>>> 
>>>>> On Aug 20, 2015, at 10:06, Jorge Timón <jtimon@jtimon•cc
>>>>> <mailto:jtimon@jtimon•cc>> wrote:
>>>>> 
>>>>> 
>>>>> But the goal is not reimplementing the consensus rules but rather
>>>>> extract them from Bitcoin Core so that nobody needs to re-implement
>>>>> them again.
>>>> 
>>>> 
>>>> 
>>>> My goal is different. Compatibility with Bitcoin is important as I
>>>> also want to deal with Bitcoins,
>>>> but it is also imperative to be able to create and serve other block
>>>> chains with other rules and for those
>>>> I do not want to carry on the legacy of an antique tool set and a
>>>> spaghetti style.
>>>> 
>>>> Bits of Proof uses scala (akka networking), java (api service), c++
>>>> (leveledb and now libconsensus)
>>>> and I am eager to integrate secp256k1 (c) as soon as part of
>>>> consensus. The choices were
>>>> made because each piece appears best in what they do.
>>>> 
>>>> Tamas Blummer
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> 
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> <mailto:bitcoin-dev@lists•linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 
>> 
> 

[-- Attachment #1.2: Type: text/html, Size: 7382 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]