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 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 <jti...@jtimon.cc >>>>> <mailto:jti...@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 >>> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
