public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dan Libby <dan@osc•co.cr>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
Date: Wed, 13 Sep 2017 02:50:53 -0700	[thread overview]
Message-ID: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr> (raw)

Hi, I am interested in the possibility of a cryptocurrency software
(future bitcoin or a future altcoin) that strives to have immutable
consensus rules.

The goal of such a cryptocurrency would not be to have the latest and
greatest tech, but rather to be a long-term store of value and to offer
investors great certainty and predictability... something that markets
tend to like.  And of course, zero consensus rule changes also means
less chance of new bugs and attack surface remains the same, which is
good for security.

Of course, hard-forks are always possible.  But that is a clear split
and something that people must opt into.  Each party has to make a
choice, and inertia is on the side of the status quo.  Whereas
soft-forks sort of drag people along with them, even those who oppose
the changes and never upgrade.  In my view, that is problematic,
especially for a coin with permanent consensus rule immutability as a
goal/ethic.

As I understand it, bitcoin soft-forks always rely on anyone-can-spend
transactions.  If those were removed, would it effectively prevent
soft-forks, or are there other possible mechanisms?  How important are
any-one-can spend tx for other uses?

More generally, do you think it is possible to programmatically
avoid/ban soft-forks, and if so, how would you go about it?







             reply	other threads:[~2017-09-13  9:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13  9:50 Dan Libby [this message]
2017-09-15  4:01 ` ZmnSCPxj
2017-09-15  9:14   ` Adam Back
2017-09-15 11:47     ` Tier Nolan
2017-09-15 20:01     ` Dan Libby
2017-09-15 19:55   ` Dan Libby
2017-09-15 20:40     ` Simone Bronzini
2017-09-15 21:48       ` Dan Libby
2017-09-16  1:42       ` Andrew Poelstra
2017-09-16  3:38     ` ZmnSCPxj
     [not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>
2017-09-15 20:15   ` Dan Libby
2017-09-18  6:40 Daniel Wilczynski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr \
    --to=dan@osc$(echo .)co.cr \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox