[bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)

[bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)

[Adam Back]

> 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>:

Re: [bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4347 bytes --]