You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently once consensus among devs is reached, and a new soft fork is added to bitcoin, it's often pushed through on the application layer without much thought given to how the end user should deal with this soft fork. Soft forks are by definition optional and bitcoin can be used fine without them - using Taproot addresses is an example.
As one of our, and the wider bitcoin spaces core principles, is transparency we should be doing more to communicate to users about how these soft-forks may, or may not, effect their experience.
Users should be educated about what changes have been made that will be directly relevant to them (such as a new address type, why it's beneficial, when you should use it etc.) and given the option to not use them if they wish. I'd imagine most would be fine with them but its giving them the choice that is important. Soft-forks should always be opt-in as that's the whole point in them.
When should this be communicated?
When a soft-fork update is pushed to an app, say adding Taproot addresses, existing users should be educated of this change, how it may or may not benefit them, and confirm that they want to use it. This could be done with a simple modal wizard when they open the app for the first time after the update - Muun did something like this with their Taproot upgrade.
If the user is downloading and using an app for the first time and several soft-forks are already in the app they should have an easy opt-in / out toggle in an advanced settings for soft-forks (communicated in a human readable way). These should be accompanied with some educational material like the modal mentioned above.
An added benefit to this is it really helps bring end users a long with the journey and understand the nature of how changes are made in bitcoin on a soft level. End user education of these kind of things would make bitcoin more robust and resilient to attacks imo.
This discussion was converted from issue #731 on November 22, 2022 10:57.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently once consensus among devs is reached, and a new soft fork is added to bitcoin, it's often pushed through on the application layer without much thought given to how the end user should deal with this soft fork. Soft forks are by definition optional and bitcoin can be used fine without them - using Taproot addresses is an example.
As one of our, and the wider bitcoin spaces core principles, is transparency we should be doing more to communicate to users about how these soft-forks may, or may not, effect their experience.
Users should be educated about what changes have been made that will be directly relevant to them (such as a new address type, why it's beneficial, when you should use it etc.) and given the option to not use them if they wish. I'd imagine most would be fine with them but its giving them the choice that is important. Soft-forks should always be opt-in as that's the whole point in them.
When should this be communicated?
An added benefit to this is it really helps bring end users a long with the journey and understand the nature of how changes are made in bitcoin on a soft level. End user education of these kind of things would make bitcoin more robust and resilient to attacks imo.
Beta Was this translation helpful? Give feedback.
All reactions