public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dan Libby <dan@osc.co.cr>
To: Andrew Quentson <andrewquentson@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
Date: Fri, 15 Sep 2017 13:15:36 -0700	[thread overview]
Message-ID: <a4ed81de-68ed-1c72-2302-139a88ee886f@osc.co.cr> (raw)
In-Reply-To: <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>

Thanks for this link.  From my reading though, it seems that only
soft-forks that attempt to freeze funds are problematic on ethereum.

From the article:
> The soft fork creates a new and fundamentally different class of 
> transactions in contrast with those that currently exist within the 
> protocol. Currently, transactions either complete successfully and
> cause a state transition, or run into an exception, in which case
> state is reverted but the maximum possible gas is still charged. With
> the soft fork, transactions which interact with a DAO will not fit
> within these two classes: they will fail execution but no gas will be
> charged. This must inevitably be the case in any soft fork that aims
> to freeze the stolen funds;

So in the general case ethereum can still soft-fork I think...


On 09/15/2017 04:19 AM, Andrew Quentson wrote:
> From my understanding, the blockchain can be designed in such a way as
> to make soft-forks be impossible or at least impractical due to attack
> vectors.
> 
> http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
> 
> Ethereum, for example, can't soft-fork. They have to always hardfork. 
> 
> On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     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?
> 
> 
> 
> 
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 


-- 
Dan Libby

Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359


  parent reply	other threads:[~2017-09-15 20:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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=a4ed81de-68ed-1c72-2302-139a88ee886f@osc.co.cr \
    --to=dan@osc.co.cr \
    --cc=andrewquentson@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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