:: Re: [Libbitcoin] Eric, what Bitcoi…
Kezdőlap
Delete this message
Reply to this message
Szerző: Juan Garavaglia
Dátum:  
Címzett: Eric Voskuil, mlmikael, Xinxi Wang, libbitcoin@lists.dyne.org
Tárgy: Re: [Libbitcoin] Eric, what BitcoinD compatibility guarantees does LibBitcoin have? (e.g. hardfork risk profile - Litecoin dev Xinxi asks)
Hello!

We have been running hundreds of tests with libbitcoin, with several nodes under every possible situation and is really hundreds for 6 months+.

In our opinion the fork risk is lower than any new version of Bitcoin Core.

And by design Libbitcoin is has a much better design to deal with corner cases.

Regards

Juan

-----Original Message-----
From: Libbitcoin [mailto:libbitcoin-bounces@lists.dyne.org] On Behalf Of Eric Voskuil
Sent: Thursday, January 19, 2017 4:01 PM
To: mlmikael <mlmikael@???>; Xinxi Wang <xinxi.wang@???>; libbitcoin@???
Subject: Re: [Libbitcoin] Eric, what BitcoinD compatibility guarantees does LibBitcoin have? (e.g. hardfork risk profile - Litecoin dev Xinxi asks)

On 01/19/2017 02:33 AM, mlmikael wrote:
> Hi Eric,
>
> Mr. Xinxi who is a Litecoin core contributor would like to ask you a
> question, with respect to the possibility that the Litecoin team would
> port LibBitcoin to Litecoin and hence create a fork by the name
> LibLitecoin, or similar solution:


The changes should be trivial.

Maintenance of a software fork is a challenge I'm sure they are familiar with. If Litecoin is maintaining sync with Bitcoin apart from configuration (which I assume to be the case) then there would be no need for a software fork. Libbitcoin does not hardwire concepts of mainnet or testnet into code apart from providing defaults for config.

> Which guarantees are in place so that LibBitcoin is guaranteed to be
> 100% compatible with BitcoinD, meaning that LibBitcoin not will cause
> any hard forks?


The same guarantees as offered by Bitcoin Core - 100% money back.

> He would like to understand this risk profile and then talk to the
> other Litecoin team.


The risks are best understood by reviewing the code. There's really no way to quantify.

IMO the chance of Core unintentionally hardforking across versions is very high (and has already happened).

e