Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-20 📝 Original message:I know what you mean as I ...
📅 Original date posted:2015-08-20
📝 Original message: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 and the rest of the hairball
is harder than a re-write from scratch, and the result will not be impressive, just hopefully working.
I think a slim API server was a lower hanging fruit in Core’s case.
BTW, support for refactoring is an example where you see if your tool set is modern.
Tamas Blummer
> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.sig>;
📝 Original message: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 and the rest of the hairball
is harder than a re-write from scratch, and the result will not be impressive, just hopefully working.
I think a slim API server was a lower hanging fruit in Core’s case.
BTW, support for refactoring is an example where you see if your tool set is modern.
Tamas Blummer
> On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/6b35bc18/attachment.sig>;