From: Chris Belcher <belcher@riseup•net>
To: bitcoin-dev@lists•linuxfoundation.org, shaolinfry@protonmail•ch
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Sun, 5 Mar 2017 14:33:06 +0000 [thread overview]
Message-ID: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net> (raw)
I think UASF is a great idea for the reasons mentioned before that it
more closely matches the balance of powers in bitcoin, and that its much
more opt-in.
Many people are comparing an UASF fork with a hard fork. I disagree with
this view and I think there is a difference between the two kinds of
forks. The situation between hard and soft forks is reversed.
In a fork between segwit-invalid and segwit-valid after a UASF, if the
segwit-valid chain ever ends up with more work then the segwit-invalid
chain will be annihilated in a big re-organization as
non-segwit-enforcing nodes move to the segwit-valid chain. The less-work
chain will simply cease to exist.
Only a miner that recodes their software can initiate such a fork,
because segwit transactions are non-standard and won't be relayed by
default.
A closer situation is the accidental fork created soon after the BIP66
soft fork. The fork lasted a few blocks and did not mine any
transactions except the coinbase. It was annihilated with a monetary
loss to any miner that took part.
Here is an argument for why chain fork is unlikely to last long or be
created by a rational self-interested miner, assuming the bitcoin
economic majority even slightly enforces the UASF.
Because the segwit-invalid coins can be annihilated in this way and
segwit-valid coins cannot, segwit-invalid coins are more risky to hold
as an asset, all else equal.
A more risky asset has a lower price, all else equal. Because investors
demand higher risk premiums for holding it and also short sellers may
sell down the price in the hopes of making a profit if it's value goes
to zero.
In cryptocurrencies like bitcoin, hashpower follows price. This is very
clear from historical trends and the underlying economic forces.
A lower-hashrate chain will eventually be overtaken in work by a
higher-hashrate chain.
Therefore, the segwit-invalid chain will be annihilated sooner or later
if the price of its coin is higher.
Of course as the old saying goes markets can stay irrational longer than
we can stay solvent, which is why I think UASF should only go ahead if
we're sure that a big part of the economic majority will enforce it.
This will make the value and liquidity of the segwit-invalid chain very
low and make the annihilating re-organization happen faster.
User-activated means it _must_ be done by the users of bitcoin.
next reply other threads:[~2017-03-05 14:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 14:33 Chris Belcher [this message]
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
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=0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shaolinfry@protonmail$(echo .)ch \
/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