fork types (Re: An implementation of BIP102 as a softfork.)

> I guess the same could be said about the softfork flavoured SW implementation

No, segregated witness https://bitcoin.org/en/bitcoin-core/capacity-increases-faq is a soft-fork maybe loosely similar to P2SH - particularly it is backwards and forwards compatible by design.

These firm forks have the advantage over hard forks that there is no left-over weak chain that is at risk of losing money (because it becomes a consensus rule that old transactions are blocked).

There is also another type of fork a firm hard fork that can do the same but for format changes that are not possible with a soft-fork.

Extension blocks show a more general backwards and forwards compatible soft-fork is also possible. Segregated witness is simpler.

Adam

On 30 December 2015 at 13:57, Marcel Jamin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> I guess the same could be said about the softfork flavoured SW
> implementation. In any case, the strategy pattern helps with code structure
> in situations like this.
>
> 2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org>:

On Wed, Dec 30, 2015 at 5:05 PM, Adam Back via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> There is also another type of fork a firm hard fork that can do the
> same but for format changes that are not possible with a soft-fork.
>

I was drafting an email for a new thread with some links about this topic, instead I'll just send this as a reply now that we are writing down fork types...

auxiliary blocks and evil soft-forks or forced soft-forks: https://bitcointalk.org/index.php?topic=283746.0 https://bitcointalk.org/index.php?topic=874313.0

soft-fork block size increase using extension blocks: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html

generalized soft-forks: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html

bip102 forced soft-fork: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

extension blocks were also discussed in this interview: http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/ .... also there was something about a "soft-hard fork".

some discussion from today re: origin of the term evil fork, evil soft-fork, forced soft-fork: https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg2g7q

some much older discussion about extension blocks and sidechains: http://gnusha.org/bitcoin-wizards/2015-01-01.log

some discussion about "generalized soft-forks" and extension blocks and evil soft-forks: http://gnusha.org/bitcoin-wizards/2015-12-20.log

some discussion about evil forks and evil soft-forks and extension blocks: http://gnusha.org/bitcoin-wizards/2015-12-30.log

segwit soft-fork makes use of a similar idea: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html https://bitcoin.org/en/bitcoin-core/capacity-increases-faq http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

Note: I am taking the term "forced soft-fork" from petertodd; it's pretty much the same thing as "evil fork" in every way but intent.

This is an x-post from https://bitcointalk.org/index.php?topic=1296628.msg13400092#msg13400092

- Bryan http://heybryan.org/ 1 512 203 0507