Segwit is not implemented, though we will do so as applicable to the
above documented policy.
> I know there are a lot of heated opinions on the
> subject, and unless you are looking to change the
> name to 'libbitcoinclassic' and change the difficulty
> adjustment to deal with lower hash rate, it might be
> worth some effort to do some interop tests with BTC1
> and Catoshi in the event that segwit2x ends up with
> the most chain work.
IAW the above policy, we don't implement specific support for altcoins
(regardless of their level of work). Changing the difficulty adjustment
would itself produce an alt, just as would a change to the block size limit.
If a given Bitcoin soft fork is active on the strong chain, we include
support for the rule change and give users the option via config to
As a rule I personally avoid advocating for any forks, limiting my
comments to explanation of behavior. This is based on a desire to
maintain focus with limited resources, given that there is no end to the
flow of fork proposals.
> Is it feasible to at least interoperate, based on the
> end-users choice, with the proposed Segwit2x behavior
> of forcing at least 1 single large block at the fork
> point, even if you don't have any Segwit code ready?
This would be more easily achieved by setting a checkpoint (via config)
for the first such block once it is determined, and changing the block
size constant (via sources). This is a trivial change.
> I imagine you could still validate all the orginal TXes
> and ignore any segregated witness versions.
As a soft fork SW does not break validation, its restrictions would just
not be enforced.
Feel free to ask if you have other questions. You can also use #libbitcoin.
This message was posted to the following mailing lists: