[bitcoin-dev] Proposing the SiTAH-fork, a mechanism for compromise.

[bitcoin-dev] Proposing the SiTAH-fork, a mechanism for compromise.

[SHAroshima Nakamati]

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

Soft-fork - A soft-fork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a soft-fork is backward-compatible.

Hard-fork - A hard-fork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.

The difficulty about pulling off a hard-fork is that for it to happen safely and without a massive disruption, everyone needs to be ready for it before it occurs. Coordinating this is a daunting task, however, safe hard-forks *will* be necessary in Bitcoin's future. Furthermore, the majority of stakeholders - devs, miners as well as users - want both soft-fork SegWit and a hard-fork TX block size increase, but favor one over the other and want to perform their favorite fork first out of fear that activating the other prevents their choice from being activated at a later point. This is a proposal to solve this stalemate by providing a path to activating both.

I propose the Soft-into-Time-Activated-Hard fork, or SiTAH-fork in short. The core concept is that it is a soft-fork that comes with a lock-in to transitioning into a hard-fork at a predetermined later point in time, drawing elements from Spoonnet. This means that, after the soft-fork takes place, there is a transition period during which everyone has the opportunity and incentive to upgrade their software, before the hard-fork inevitably happens. As a consequence of this, those who want the hard-fork have incentive to support activating the the soft-fork, and those who want the soft-fork have the incentive to pledge to activate the hard-fork, rather than opposing their secondary choice out of fear of their primary choice being indefinitely postponed.

As for how this can be implemented for SegWit; SegWit is made soft-fork compatible by virtue of the block weight function. From BIP-0141:

> Block weight is defined as Base size * 3 + Total size.
>
> Base size is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.
>
> Total size is the block size in bytes with transactions serialized as described in BIP144, including base data and witness data.
>
> The new rule is block weight ≤ 4,000,000.

This block weight function can be replaced by a version that allows for >1MB of pure TX data when the median time-past of the last 11 blocks is greater than the HardForkTime. In other words:

BlockWeight = MedianTimePast < HardForkTime ? BaseSize * 3 + TotalSize : TotalSize;

The post-hard-fork part of this formula can of course be tweaked.

I pose that implementing this would greatly improve support for the introduction of SegWit as it provides a pledge to increase space for pure TX data, which is something many are asking for. LN is a great long-term scaling solution but is not ready yet, and this measure provides a way to enable SegWit so that LN can later be built on top, while at the same time providing a promise of TX-space relief to those skeptical or unconvinced of SW/LN providing this relief in the short to medium term.

- SHAroshima

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