Re: [bitcoin-dev] Moving towards user activated soft fork activation

From: Eric Voskuil <eric@voskuil•org>
To: David Vorick <david.vorick@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Date: Sun, 5 Mar 2017 10:48:33 -0800	[thread overview]
Message-ID: <CF179411-8790-4CD9-A785-D7DA7C9AB865@voskuil.org> (raw)
In-Reply-To: <CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3623 bytes --]

There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large consensus is more secure in that it is more resistant to change (forks) than a system with a small consensus.

The fact that mining is highly centralized makes it relatively easy to enforce a fork via miner collaboration, and hard to do so without it.

So clearly the other option, as being discussed here, is to enforce a fork via the economy. Given the highly centralized nature of the economy, described below as "economic hubs", it is also relatively easy as well.

Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has been done) and negotiate a change to any rule, Bitcoin is a purely political money.

If "we" can do this, so can "they".

e

> On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> 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.
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5355 bytes --]