Bitcoin Changes With User-Signaled Soft Forks

UASF versus URSF is one mechanism for proposed changes to Bitcoin’s code. This should be the way changes to Bitcoin are decided and implemented.

Watch This Episode On YouTube

Listen To The Episode Here:

AppleSpotifyGoogleLibsynOvercast

In this episode of “Bitcoin, Explained,” hosts Aaron van Wirdum and Sjors Provoost discuss URSFs, which stands for either User Rejected Soft Forks or User Resisted Soft Forks, depending on who you ask. URSFs are a recently introduced tool in Bitcoin’s upgrade mechanism toolkit.

In the first part of the episode, van Wirdum and Provoost explain that URSFs are best considered as the mirror equivalent of User Activated Soft Forks (UASFs) with mandated signaling. Whereas UASFs will reject blocks that don’t signal readiness for a soft fork toward the end of a soft-fork activation window, URSFs will reject blocks that do signal. If both UASF and URSF clients are deployed, they would in principle create a split in the blockchain.

In the second part of the episode, the duo outlines the various soft-fork upgrade mechanisms, ranging from Miner Activated Soft Forks (MASFs), flag day activated UASFs and mandated signaling UASFs. Van Wirdum then explains why he believes mandated signaling UASFs are his preferred method of deploying soft forks and why he thinks URSFs should be offered as an added option for users who prefer to reject the soft fork in the future. Van Wirdum shared, “The problem of course is that this would split the chain, but … If there is one group of people, an intolerant minority, that definitely wants something, and there’s another group of people that definitely don’t want that, then the chain should split … If people want different things, then they want different things.”

Finally, Provoost lays out the “rough consensus” guidelines as used in context of the Internet Engineering Task Force (IETF), and how this applies to Bitcoin upgrades.

Read More

UASF versus URSF is one mechanism for proposed changes to Bitcoin’s code. This should be the way changes to Bitcoin are decided and implemented.

UASF versus URSF is one mechanism for proposed changes to Bitcoin’s code. This should be the way changes to Bitcoin are decided and implemented.

Watch This Episode On YouTube

Listen To The Episode Here:

AppleSpotifyGoogleLibsynOvercast

In this episode of “Bitcoin, Explained,” hosts Aaron van Wirdum and Sjors Provoost discuss URSFs, which stands for either User Rejected Soft Forks or User Resisted Soft Forks, depending on who you ask. URSFs are a recently introduced tool in Bitcoin’s upgrade mechanism toolkit.

In the first part of the episode, van Wirdum and Provoost explain that URSFs are best considered as the mirror equivalent of User Activated Soft Forks (UASFs) with mandated signaling. Whereas UASFs will reject blocks that don’t signal readiness for a soft fork toward the end of a soft-fork activation window, URSFs will reject blocks that do signal. If both UASF and URSF clients are deployed, they would in principle create a split in the blockchain.

In the second part of the episode, the duo outlines the various soft-fork upgrade mechanisms, ranging from Miner Activated Soft Forks (MASFs), flag day activated UASFs and mandated signaling UASFs. Van Wirdum then explains why he believes mandated signaling UASFs are his preferred method of deploying soft forks and why he thinks URSFs should be offered as an added option for users who prefer to reject the soft fork in the future. Van Wirdum shared, “The problem of course is that this would split the chain, but … If there is one group of people, an intolerant minority, that definitely wants something, and there’s another group of people that definitely don’t want that, then the chain should split … If people want different things, then they want different things.”

Finally, Provoost lays out the “rough consensus” guidelines as used in context of the Internet Engineering Task Force (IETF), and how this applies to Bitcoin upgrades.

Feedzy

Leave a Reply

Your email address will not be published. Required fields are marked *