From: David Vorick <david.vorick@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Chris Belcher <belcher@riseup•net>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Sun, 5 Mar 2017 13:10:15 -0500 [thread overview]
Message-ID: <CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com> (raw)
In-Reply-To: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
The success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.
I think it would be pretty easy to get high confidence of the success of a
UASF. Basically you need all the major economic hubs to agree to upgrade
and then exclusively accept UASF coins. I don't have a comprehensive list,
but if we could sign on 75% of the major exchanges and payment processors,
and get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would be unable to sell
their coins or pay their bills by stubbornly sticking to the old chain.
It's less risky than a hard fork by far, because there is zero risk of coin
split if the UASF has majority hashrate, which will follow majority
economic value.
A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.
That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.
If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade, the flag day should remain upset, as the risk of
coin split will be non-zero.
I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.
[-- Attachment #2: Type: text/html, Size: 3323 bytes --]
next prev parent reply other threads:[~2017-03-05 18:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 14:33 Chris Belcher
2017-03-05 18:10 ` David Vorick [this message]
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='CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com' \
--to=david.vorick@gmail$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--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