public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Edmund Edgar <ed@realitykeys.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Mon, 6 Mar 2017 19:29:35 +0900	[thread overview]
Message-ID: <CA+su7OV0Cpe=4AKdNhJXOCbYVriEN1vHSoA_0r31GXCAP1=NCA@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnyr4QoU5Rn2ryQ-jG8sZ18J7NKcpd3Cg+uN1sfiA=FiB+Q@mail.gmail.com>

On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> User activated soft forks, or perhaps more accurately called 'economically
> forced soft forks' are a tool to use if the miners are in clear opposition
> to the broader economy.

I don't think they work for that, at least not for new features,
because miners will presumably just head the whole thing off by
orphaning the whole class of non-standard transactions that are the
subject of the fork. In the SegWit case, they'd just orphan anything
that looks like a SegWit transaction, valid or not. That way they
don't need to worry about ending up on the wrong side of the upgrade,
because no transaction affected by the proposed rule change will ever
get into the longest chain. Rational node operators (particularly
exchanges) will likely also adopt their stricter rule change, since
they know any chain that breaks it will end up being orphaned, so you
don't want to act on a payment that you see confirmed in it. So then
you're back where you started, except that your soft-fork is now a
de-facto hard-fork, because you have to undo the new, stricter rule
that the miners introduced to head off your shenannigans.

Where they're interesting is where you can do something meaningful by
forcing some transactions through on a once-off basis. For example, if
the Chinese government identified an address belonging to Uighur
separatists and leaned on Chinese miners to prevent anything from that
address confirming, it might be interesting for users to say, "If
these utxos are not spent by block X, your block is invalid".

They might also be interesting for feature upgrades in a world where
mining is radically decentralized and upgrades are fighting against
inertia rather than opposition, but sadly that's not the world we
currently live in.

-- 
-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
support@realitykeys.com
https://www.realitykeys.com


  reply	other threads:[~2017-03-06 10:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 14:33 [bitcoin-dev] Moving towards user activated soft fork activation Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48   ` Eric Voskuil
2017-03-05 21:31   ` Nick ODell
2017-03-06  9:18     ` David Vorick
2017-03-06 10:29       ` Edmund Edgar [this message]
2017-03-06 23:23         ` Gareth Williams
2017-03-07  1:07           ` Edmund Edgar
2017-03-07 17:37             ` Eric Voskuil
2017-03-07  9:17           ` Tom Zander
2017-03-07 18:13             ` Eric Voskuil
2017-03-07 19:13             ` Alphonse Pace
  -- strict thread matches above, loose matches on Subject: below --
2017-02-25 23:55 shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02   ` shaolinfry
2017-02-27 16:50     ` Eric Voskuil
2017-02-28 21:20 ` Luke Dashjr
2017-03-12 15:47 ` shaolinfry

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='CA+su7OV0Cpe=4AKdNhJXOCbYVriEN1vHSoA_0r31GXCAP1=NCA@mail.gmail.com' \
    --to=ed@realitykeys.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