path: root/f7/e1342e6f3898554aab94b051b554d090030d2f

Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DED0259
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 21:31:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com
	[209.85.218.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D644AB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 21:31:27 +0000 (UTC)
Received: by mail-oi0-f48.google.com with SMTP id 126so25209174oig.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 05 Mar 2017 13:31:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=nvEIvolTxm96sOLv00h01dKxFyLt8ZBIDoJZlNluVCw=;
	b=b0np9SNdvJtl0ssy0ADVAedQkSoqkH27eGMERKX/984/2HfLSnLcuouRSMusCT5uPc
	07AE0A9u8QvtNN18hgRjPAuhec39UqiRnvr6gjVsudl3MVv+XGAbmGXWGcZKnBMhnBNE
	usIPiE+3Bj3hRlp0sshscAiSXVrrQCKHKXfLsU87D91Fjqkpg7wGEJ/Q6ZK+giC1/LiC
	mEpjdh3Aol1NQ80zJ/QUtUytyaIxF+4x5xBriyRBFlJLgE02EtLFfwsKSowHmR1s6eO2
	apj2/pv8NZIzzSHoaClLL3L1RN1uSe7NBcdtXXkSnnFvhXrPsgf4SWD3MJpm+6djvhN4
	BLeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=nvEIvolTxm96sOLv00h01dKxFyLt8ZBIDoJZlNluVCw=;
	b=B/QfZQ2mQmX9KMoHopF5T3jf5v8yTmwZcR0zmlzVrrdnLSjvRNYIf6w3fj6IgvmuBG
	kCbaEzn9mILowyGfatUs42t57PHK6xTWRPuuzHkYRjwviPlr8Yw3NeXdKsEndwTzFVfp
	FIzRXnka+dnKfPY9wxnf291pVouHtAn2hBXB81z32wnTAWAcabDX6f4ZzRc+iYtH4Avk
	LT05DBgzVxd+8vSO9er838NtsCEfy4wpNYsZKseZBrnKimonLb6F/jfc88XAhQc755ma
	qUgCLXFDQHAz18ItaP8PX5nNNua9wrU6YLisYLFy8D5rl+FpLDCHeyWkB4yfMgC5XHBS
	K2rQ==
X-Gm-Message-State: AMke39mr/7uDUopQTIntvjv4i0RijRD6J1qaY9KPtLsItJz9XKabroOzEYiW6UUozujFjKmlWVavsfqHuIx3hg==
X-Received: by 10.202.56.130 with SMTP id f124mr6694811oia.204.1488749486482; 
	Sun, 05 Mar 2017 13:31:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.73.231 with HTTP; Sun, 5 Mar 2017 13:31:26 -0800 (PST)
In-Reply-To: <CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
	<CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
Date: Sun, 5 Mar 2017 14:31:26 -0700
Message-ID: <CANN4kmcLTcqHL53tEFk=g9o0_PsGzwArm9wgd0__ZXZpvhrs1g@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113cdb764d2d04054a0280f4
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no 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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Mar 2017 21:31:28 -0000

--001a113cdb764d2d04054a0280f4
Content-Type: text/plain; charset=UTF-8

>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).

I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.

A year passes, and Alice and Bob meet again. Bob tells Alice that Fork B
has been doing much better than Fork A, and is trading at ten times the
price. Alice replies that it doesn't matter, since Fork B will soon split
into B1 and B2. After all, if Fork B surrendered its principles once, it
can do so again. Bob replies that Fork B represents the true spirit of
Blahcoin. Alice replies that all of the people whose opinion she respects
believe that Fork B violates principles set down by the Founder (peace be
upon him.)

Bob disagrees, and cites an annotated collection of the Founder's writings,
which clearly show that if a situation like what provoked the Great Fork
happens, Fork B is in the right. All of the people Bob knows (except Alice)
agree that this shows Fork A is invalid. Alice replies that Bob is
committing the bandwagon fallacy; even if a thousand people believe that
red is green, that does not make it true. Also, the collection takes
several of the Founder's comments out of context. If one looks at comments
made prior to the release of Blahcoin, they lay out a framework that
envisions Fork A. Bob replies that Alice can't use statements made prior to
the release of Blahcoin to establish original intent; the system hadn't
been designed yet.

Bob points out that Fork B has a higher total chainwork. Alice scoffs. She
posits a Fork C, which is exactly like Fork A, except that chainwork is
defined to be the previous definition plus a quadrillion. Bob finds that
ridiculous. Fork C would transgress upon intrinsic principles of Blahcoin.
No more than Fork B does, Alice replies.

----

Each sentence above is true from some point of view. Each person sincerely
believes in the rightness of their position. Is there some objective
measure, that both Alice and Bob can agree on, that resolves this? I don't
think there is. Bob and Alice will sneer at each other for being idiots
forever. The schism will never resolve.

Satoshi Bless,
--Nick

On Sun, Mar 5, 2017 at 11: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
>
>

--001a113cdb764d2d04054a0280f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;I also think that the UASF is a good idea. Hashra=
te follows coin price. If the UASF has the higher coin price, the other cha=
in will be annihilated. If the UASF has a lower coin price, the user activa=
ted chain can still exist (though their coins can be trivially stolen on th=
e majority chain).</div><div><br></div><div>I don&#39;t think that&#39;s tr=
ue. Say there are two forks of Blahcoin. Alice thinks there&#39;s a 55% cha=
nce that Fork A will succeed. Bob thinks there&#39;s a 55% chance that Fork=
 B will succeed. Alice trades all of her Fork B coins for all of Bob&#39;s =
Fork A coins. Now, Bob and Alice both have a stake in one fork or the other=
 succeeding. Alice starts spending more time around Fork A users; Bob start=
s spending his time with Fork B users.</div><div><br></div><div>A year pass=
es, and Alice and Bob meet again. Bob tells Alice that Fork B has been doin=
g much better than Fork A, and is trading at ten times the price. Alice rep=
lies that it doesn&#39;t matter, since Fork B will soon split into B1 and B=
2. After all, if Fork B surrendered its principles once, it can do so again=
. Bob replies that Fork B represents the true spirit of Blahcoin. Alice rep=
lies that all of the people whose opinion she respects believe that Fork B =
violates principles set down by the Founder (peace be upon him.)</div><div>=
<br></div><div>Bob disagrees, and cites an annotated collection of the Foun=
der&#39;s writings, which clearly show that if a situation like what provok=
ed the Great Fork happens, Fork B is in the right. All of the people Bob kn=
ows (except Alice) agree that this shows Fork A is invalid. Alice replies t=
hat Bob is committing the bandwagon fallacy; even if a thousand people beli=
eve that red is green, that does not make it true. Also, the collection tak=
es several of the Founder&#39;s comments out of context. If one looks at co=
mments made prior to the release of Blahcoin, they lay out a framework that=
 envisions Fork A. Bob replies that Alice can&#39;t use statements made pri=
or to the release of Blahcoin to establish original intent; the system hadn=
&#39;t been designed yet.</div><div><br></div><div>Bob points out that Fork=
 B has a higher total chainwork. Alice scoffs. She posits a Fork C, which i=
s exactly like Fork A, except that chainwork is defined to be the previous =
definition plus a quadrillion. Bob finds that ridiculous. Fork C would tran=
sgress upon intrinsic principles of Blahcoin. No more than Fork B does, Ali=
ce replies.</div><div><br></div><div>----</div><div><br></div><div>Each sen=
tence above is true from some point of view. Each person sincerely believes=
 in the rightness of their position. Is there some objective measure, that =
both Alice and Bob can agree on, that resolves this? I don&#39;t think ther=
e is. Bob and Alice will sneer at each other for being idiots forever. The =
schism will never resolve.</div><div><br></div><div>Satoshi Bless,</div><di=
v>--Nick</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Sun, Mar 5, 2017 at 11:10 AM, David Vorick via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div class=3D"gmail_extra=
" dir=3D"auto"><div style=3D"font-family:sans-serif;font-size:13.696px" dir=
=3D"auto">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 annih=
ilated. If the UASF has a lower coin price, the user activated chain can st=
ill exist (though their coins can be trivially stolen on the majority chain=
).</div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"aut=
o"><br></div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=
=3D"auto">The success of the UASF depends entirely on the price. And actual=
ly, 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 a=
rrive over the UASF chain. In doing so, you drive down the utility of the o=
ld chain and drive up the utility of the new chain. This ultimately impacts=
 the price.</div><div style=3D"font-family:sans-serif;font-size:13.696px" d=
ir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font-size:13.696=
px" dir=3D"auto">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 ag=
ree to upgrade and then exclusively accept UASF coins. I don&#39;t have a c=
omprehensive list, but if we could sign on 75% of the major exchanges and p=
ayment processors, and get 75% of the wallets to upgrade, then the UASF wou=
ld 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&#39;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 fo=
llow majority economic value.</div><div style=3D"font-family:sans-serif;fon=
t-size:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-seri=
f;font-size:13.696px" dir=3D"auto">A serious proposal I think would get all=
 the code ready and merged, but without setting a flag day. Then we would g=
et 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, a=
nd have a full year to transition.</div><div style=3D"font-family:sans-seri=
f;font-size:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans=
-serif;font-size:13.696px" dir=3D"auto">That gives tons of time for people =
to upgrade, and tons of confidence that the UASF will end up as the majorit=
y chain.</div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=
=3D"auto"><br></div><div style=3D"font-family:sans-serif;font-size:13.696px=
" dir=3D"auto">If we cannot get enough major exchanges, payment processors,=
 and other economic hubs to upgrade, =C2=A0the flag day should remain upset=
, as the risk of coin split will be non-zero.</div><div style=3D"font-famil=
y:sans-serif;font-size:13.696px" dir=3D"auto"><br></div><div style=3D"font-=
family:sans-serif;font-size:13.696px" dir=3D"auto">I would suggest that a c=
arefully executed UASF is much riskier than a soft fork, but far, far less =
risky than a hard fork.</div><div style=3D"font-family:sans-serif;font-size=
:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font=
-size:13.696px" dir=3D"auto"><br></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a113cdb764d2d04054a0280f4--