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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
