Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EAA46C for ; Sun, 5 Mar 2017 18:48:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AAAC818E for ; Sun, 5 Mar 2017 18:48:36 +0000 (UTC) Received: by mail-pf0-f170.google.com with SMTP id o126so3934722pfb.3 for ; Sun, 05 Mar 2017 10:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JiQLh3DkO3e8Pg4Ns+UdNCOLxKDCtyoIN0ZZJI6K1z4=; b=x9M1bn3pqE+nU8BVcISbN0M5GXdI73XF7I+YtuE2A/ffTJlWRJ4J4c4ztZ8UrLRqXh b3c8i4ABn3mqh9kLsnJ0WcOl8QwkjkUEIf+cZDIKcRIsLA7jGzmab/7Etumkpf6WXtL+ AKwGMgORrYwQsGnmqSBPQBFiRiSf11WmxbKMBTqoWiMPHD4IgKPvvyoLGKNV1gs3w27b +jez66ijkmo2mf2ZFVnPMxYrxyxmTqlfRVfukdA1WP+w030pa/7fr5heu6Lp0eJtYqVe t1uG7hw1pMokpuiG1jC2y6Jei+cYfe/2yt2doC34MDx1IeFqtbtaqn0uMBwqW2hPccVX 6Jzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JiQLh3DkO3e8Pg4Ns+UdNCOLxKDCtyoIN0ZZJI6K1z4=; b=nb++yb9C2NaH3bzH75rkRGDSIK8x/MsStXAkkgpEgSlUKJ2nuZyImmMlXCY36JYsMH dsOX7QQjClxMedb4Qr9TaErpVV13gVOpUwmduK3xVxV7i/KJCuX9znlR833ptXcp/EsH +4u9P8mytQAY8zqtiLpd972wBwreuPkSPvMD7XvPA4IPIQl85w0B1+GVX2jx4hDL1HS9 obf0OmwL8YRXcxLU5PJCiSDLmNsEGNvmuq8Fm5iFmrEYAhi31zewYuqJtAuxwmLvXias D6PPgcCI27A5vQTcORF9P6h3xE9MZG8pEfWeQ/6N+8irjwjF1sabCijwyTcJhcfqyT1D J3WA== X-Gm-Message-State: AMke39lM7WgV9vQUBDEtqK9rgQlqK+GXf8ZX7Znx6vkI/83FG8dPV1JsJNj1dFDnNRCO6Q== X-Received: by 10.99.7.206 with SMTP id 197mr8008322pgh.95.1488739716058; Sun, 05 Mar 2017 10:48:36 -0800 (PST) Received: from [10.86.254.225] (mobile-166-176-185-182.mycingular.net. [166.176.185.182]) by smtp.gmail.com with ESMTPSA id 185sm34814736pfg.13.2017.03.05.10.48.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 10:48:35 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sun, 5 Mar 2017 10:48:33 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net> To: David Vorick , Bitcoin Protocol Discussion X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 18:48:37 -0000 --Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 lev= el of decentralization. Another way to think of it is that a system with les= s decentralization has a smaller community (consensus). A large consensus is= more secure in that it is more resistant to change (forks) than a system wi= th a small consensus. The fact that mining is highly centralized makes it relatively easy to enfor= ce 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 v= ia the economy. Given the highly centralized nature of the economy, describe= d 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 d= own with 75% of the economy and/or 90% of the hash power (which of course ha= s been done) and negotiate a change to any rule, Bitcoin is a purely politic= al money. If "we" can do this, so can "they". e > On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev wrote: >=20 > 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). >=20 > The success of the UASF depends entirely on the price. And actually, the p= rice is easy to manipulate. If you, as an economically active full node, ref= use to acknowledge the old chain and demand that incoming coins arrive over t= he UASF chain. In doing so, you drive down the utility of the old chain and d= rive up the utility of the new chain. This ultimately impacts the price. >=20 > 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 an= d 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 g= et 75% of the wallets to upgrade, then the UASF would be very likely to succ= essfully obliterate the old rules, as miners would be unable to sell their c= oins or pay their bills by stubbornly sticking to the old chain. It's less r= isky than a hard fork by far, because there is zero risk of coin split if th= e UASF has majority hashrate, which will follow majority economic value. >=20 > A serious proposal I think would get all the code ready and merged, but wi= thout setting a flag day. Then we would get signatures from the major instit= utions promising to use the software and saying that they are ready for a fl= ag day. After that, you release a patch with a flag day 12 months in the fut= ure. People can upgrade immediately, and have a full year to transition. >=20 > That gives tons of time for people to upgrade, and tons of confidence that= the UASF will end up as the majority chain. >=20 > If we cannot get enough major exchanges, payment processors, and other eco= nomic hubs to upgrade, the flag day should remain upset, as the risk of coi= n split will be non-zero. >=20 > I would suggest that a carefully executed UASF is much riskier than a soft= fork, but far, far less risky than a hard fork. >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are two aspects of sy= stem security in Bitcoin, mining (hash power) and payment validation (econom= y). The security of each is a function of its level of decentralization. Ano= ther way to think of it is that a system with less decentralization has a sm= aller community (consensus). A large consensus is more secure in that it is m= ore resistant to change (forks) than a system with a small consensus.
<= div>
The fact that mining is highly centralized makes it relat= ively easy to enforce a fork via miner collaboration, and hard to do so with= out it.

So clearly the other option, as being discu= ssed here, is to enforce a fork via the economy. Given the highly centralize= d nature of the economy, described below as "economic hubs", it is also rela= tively easy as well.

Independent of one's opinion o= n the merits of one fork or another, the state of centralization in Bitcoin i= s 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 ch= ange to any rule, Bitcoin is a purely political money.

<= div>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.linuxfounda= tion.org> wrote:

I also think that the UASF is a g= ood 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, t= he user activated chain can still exist (though their coins can be trivially= stolen on the majority chain).

The success of the UASF depends entirely o= n the price. And actually, the price is easy to manipulate. If you, as an ec= onomically active full node, refuse to acknowledge the old chain and demand t= hat incoming coins arrive over the UASF chain. In doing so, you drive down t= he utility of the old chain and drive up the utility of the new chain. This u= ltimately impacts the price.

I think it would be pretty easy to get high c= onfidence of the success of a UASF. Basically you need all the major economi= c hubs to agree to upgrade and then exclusively accept UASF coins. I don't h= ave 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 UAS= F would be very likely to successfully obliterate the old rules, as miners w= ould 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 follo= w majority economic value.

A serious proposal I think would get all the c= ode ready and merged, but without setting a flag day. Then we would get sign= atures from the major institutions promising to use the software and saying t= hat they are ready for a flag day. After that, you release a patch with a fl= ag day 12 months in the future. People can upgrade immediately, and have a f= ull year to transition.

That gives tons of time for people to upgrade, an= d tons of confidence that the UASF will end up as the majority chain.
<= div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto">
If w= e cannot get enough major exchanges, payment processors, and other economic h= ubs to upgrade,  the flag day should remain upset, as the risk of coin s= plit will be non-zero.

I would suggest that a carefully executed UASF is m= uch riskier than a soft fork, but far, far less risky than a hard fork.

<= /div>
<= br>
____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222--