public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] hypothetical: Could soft-forks be prevented?
@ 2017-09-13  9:50 Dan Libby
  2017-09-15  4:01 ` ZmnSCPxj
       [not found] ` <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>
  0 siblings, 2 replies; 12+ messages in thread
From: Dan Libby @ 2017-09-13  9:50 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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?







^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
@ 2017-09-18  6:40 Daniel Wilczynski
  0 siblings, 0 replies; 12+ messages in thread
From: Daniel Wilczynski @ 2017-09-18  6:40 UTC (permalink / raw)
  To: bitcoin-dev

Hi Dan.

What might be better aim is to have built in wipeout protection? In
softfork scenario this would protect a majority threatening a minority
with a wipeout if they do not opt in to some soft-fork consensus
change.


This could be partly done done by having automoated consensus critical
checkpoints, for example at 100 blocks deep. Maybe there are better
ways?


This would in effect turn softforks into hardforks.




Regards,


Daniel Wilczynski


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-09-18  6:40 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-13  9:50 [bitcoin-dev] hypothetical: Could soft-forks be prevented? Dan Libby
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox