public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2015-08-21  6:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-23 14:30 [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks) Jorge Timón
2015-07-23 14:57 ` Milly Bitcoin
2015-07-23 21:02   ` Jorge Timón
2015-07-23 21:30     ` Milly Bitcoin
2015-07-28  6:40 ` Eric Voskuil
2015-07-28  8:47   ` Wladimir J. van der Laan
2015-07-28  9:58   ` Jorge Timón
2015-07-29 20:38     ` Eric Voskuil
2015-07-29 21:46       ` Jorge Timón
2015-08-20  0:53         ` Jorge Timón
2015-08-20  7:14           ` Tamas Blummer
2015-08-20  8:06             ` Jorge Timón
2015-08-20  8:35               ` Tamas Blummer
2015-08-20 17:44                 ` Matt Corallo
2015-08-20 21:26                   ` Tamas Blummer
2015-08-20 21:35                     ` Matt Corallo
2015-08-21  6:46                       ` Tamas Blummer [this message]
2015-08-21 19:46                 ` Jorge Timón
2015-08-21 20:07                   ` Eric Lombrozo
2015-08-22 11:04                   ` Tamas Blummer
2015-08-23  1:23                     ` Eric Lombrozo
2015-08-23  2:19                       ` Eric Lombrozo
2015-08-23  6:42                       ` Tamas Blummer
2015-08-29 23:30                         ` Jorge Timón
2015-08-29 23:25                       ` Jorge Timón
2015-08-29 22:08                     ` Jorge Timón
2015-07-28  8:43 ` Wladimir J. van der Laan
2015-07-28 10:09   ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DE81C494-FB9F-49FA-9281-BF274345E411@bitsofproof.com \
    --to=tamas@bitsofproof.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox