path: root/92/ee76f91be10253b00cc0657aca44aa7c976ea4

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CDF96481
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 13:55:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com
	[209.85.216.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD7FF79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 13:55:18 +0000 (UTC)
Received: by mail-qt0-f178.google.com with SMTP id g60so12469622qtd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 06:55:18 -0700 (PDT)
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
	:cc; bh=tHpzsK9i8fPxrdCMyxdnm96q6OVkc7iGhXE2DZrwqlE=;
	b=t4cqQQHAj6/kPIQliTE2FCBJZT3J6r1ZnJj5GwbOpQAQXoj3jnDqvoqOYut4OqC17b
	jJoWPSXqeCZWzswMSamLyda6Ke5Ib+cXOcCOdW7x6Yi7lYvDHIow61tqPgGbZTSlryAw
	XNnj8UEHN3CisgsWKRfnMCiv8780JjfJjQmHr7XdxecNrmfsPasa44/PRSF8XF6BiGIH
	U71FoU7K4e7IakFYyW0Os8XER+/N5qPAayIngPJmLdzl/4d8ysg2QBZTaWjm+ySEyKIj
	i4zn0hG+jXp4iXzX/kjNRZZ50H+4TJOOTJwK107G7pQ0bMqR5t3Nqa8u1pE/Fvnrr7Za
	Lk7g==
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:cc;
	bh=tHpzsK9i8fPxrdCMyxdnm96q6OVkc7iGhXE2DZrwqlE=;
	b=nM/vK60TmNM6LIGnEA2zMLm3Dlq9MHVrxXNYSBjhS7H4jvmqLGlSUWJCUTxFpmmgeD
	6QzxBtvm7kp3bxFlxzCtCe6g9tlJ6Az2Fo569xK/u1LCo5rYH7FPjEU0r8GH2+J2h8La
	IdBq3W1H9or4C98vtB3I4HYB3bJSw7aURa6+Tkv9U/TDgAUuFMYH8zeOMCt36TMyoLeX
	BwcvGYzQOQAOsHjBTi/XJOCrQ28IXLmNnMp9gTf2KQ/Vc2AC86BeQWOQ05nCg6Rcg1Rr
	BIIteROI7oAZmALnetXc3ICWFw8fhqQmWjs2MXHcvX57VsRBTDXCmppIMgs3OLEoNMcR
	wtmQ==
X-Gm-Message-State: AN3rC/5Ek220GSvrSfJBZWYgKJBrF+YcALfdG+/pVDfy4kfMXHOrzv6L
	KwcHzDZ2e2Mup1+Is6tfKMXFkHPskQ==
X-Received: by 10.200.40.72 with SMTP id 8mr2033165qtr.204.1492264517992; Sat,
	15 Apr 2017 06:55:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.137.174 with HTTP; Sat, 15 Apr 2017 06:54:57 -0700 (PDT)
In-Reply-To: <CAAt2M19-R83VS2PB6ppjqSH4cSXT--5M=QxUFLpYDr8iMnpGpQ@mail.gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<E7A3E345-15C9-4C4C-B3D7-C75634243430@gmail.com>
	<CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
	<2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net>
	<CAAt2M19-R83VS2PB6ppjqSH4cSXT--5M=QxUFLpYDr8iMnpGpQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sat, 15 Apr 2017 09:54:57 -0400
Message-ID: <CAB3F3DveN2PSYCpMSF+9hD5Np_omar=ZTs7QECpVtzSo3x7Z7Q@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=001a11410c648189f0054d34e872
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
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: Sat, 15 Apr 2017 13:55:19 -0000

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

> Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.

UASF can be just a flag day.

On Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>
> Not sure if you missed my previous reply to you, but I'm curious about
> your thoughts on this particular point. I contend that for any UASF,
> orphaning non-signalling blocks on the flag date is [maybe] safer [for
> those in on the UASF fork] than just
> considering the fork active on the flag date.
>
>
> Note my additions.
>
> Enforcement by orphaning non-compliance makes it harder to reverse a buggy
> softfork, since you necessarily increase the effort needed to return enough
> mining power to the safe chain since you now have mostly unmonitored mining
> hardware fighting you actively, whose operators you might not be able to
> contact. You'd practically have to hardfork out of the situation.
>
> There's also the risk of the activation itself triggering concensus bugs
> (multiple incompatible UASF forks), if there's multiple implementations of
> it in the network (or one buggy one). We have already seen something like
> it happen. This can both happen on the miner side, client side or both
> (miner side only would lead to a ton of orphaned blocks, client side means
> netsplit).
>
> It is also not economically favorable for any individual miner to be the
> one to mine empty blocks on top of any surviving softfork-incompatible
> chain. As a miner you would only volunteer to do it if you believe the
> softfork is necessary or itself will enable greater future profit.
>
> Besides that, I also just don't believe that UASF itself as a method to
> activate softforks is a good choice. The only two reliable signals we have
> for this purpose in Bitcoin are block height (flag day) and standard miner
> signaling, as every other metric can be falsified or gamed.
>
> But there's also more problems - a big one is that we have no way right
> now for a node to tell another "the transaction you just relayed to me is
> invalid according to an active softfork" (or "will become invalid". This
> matters for several reasons.
>
> The first one that came to my mind is that we have widespread usage of
> zero-confirmation payments in the network.
>
> This was already dangerous for other reasons, but this UASF could make it
> guaranteed cost-free to exploit - because as many also know, we ALSO
> already have a lot of nodes that do not enforce the non-default rejection
> policies (otherwise we'd never see such transactions on blocks), including
> many alternative Bitcoin clients.
>
> The combination of these factors means that you can present an UASF
> invalid transaction to a non-updated client that is supposedly protected by
> the deliberate orphaning effort, and have it accept this as a payment. To
> never see it get confirmed, or to eventually see it doublespent by an
> UASF-valid transaction.
>
> I would not at all be surprised if it turned out that many
> zero-confirmation accepting services do not reject non-default
> transactions, or if they aren't all UASF-segwit aware.
>
> This is why a flag day or similar is more effective - it can't be ignored
> unlike "just another one of those UASF proposals" that you might not have
> evaluated or not expect to activate.
>
> This is by the way also a reason that I believe that all nodes and
> services should publish all concensus critical policies that they enforce.
> This would make it far easier to alert somebody that they NEED TO prepare
> for whatever proposal that might conflict with their active policies.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">Besides that, I=
 also just don&#39;t believe that UASF itself as a method to activate softf=
orks is a good choice. The only two reliable signals we have for this purpo=
se in Bitcoin are block height (flag day) and standard miner signaling, as =
every other metric can be falsified or gamed.=C2=A0</span><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">UASF can be just a flag day.</span></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sat, Apr 15, 2017 at 9:23 AM, Natanael v=
ia bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=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:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><=
div data-smartmail=3D"gmail_signature" dir=3D"auto"><br></div><div class=3D=
"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote"><span class=3D"">=
Den 15 apr. 2017 13:51 skrev &quot;Chris Acheson via bitcoin-dev&quot; &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;:</span><blockquote class=
=3D"m_3404871864433641353quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D""><div class=3D"m_3404871864433=
641353quoted-text">
<br>
</div>Not sure if you missed my previous reply to you, but I&#39;m curious =
about<br>
your thoughts on this particular point. I contend that for any UASF,<br></s=
pan>
orphaning non-signalling blocks on the flag date is [maybe] safer [for thos=
e in on the UASF fork] than just<span class=3D""><br>
considering the fork active on the flag date.<br></span></blockquote></div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">Note my additions.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Enforcement by orpha=
ning non-compliance makes it harder to reverse a buggy softfork, since you =
necessarily increase the effort needed to return enough mining power to the=
 safe chain since you now have mostly unmonitored mining hardware fighting =
you actively, whose operators you might not be able to contact. You&#39;d p=
ractically have to hardfork out of the situation.=C2=A0</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">There&#39;s also the risk of the activation=
 itself triggering concensus bugs (multiple incompatible UASF forks), if th=
ere&#39;s multiple implementations of it in the network (or one buggy one).=
 We have already seen something like it happen. This can both happen on the=
 miner side, client side or both (miner side only would lead to a ton of or=
phaned blocks, client side means netsplit).=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">It is also not economically favorable for any ind=
ividual miner to be the one to mine empty blocks on top of any surviving so=
ftfork-incompatible chain. As a miner you would only volunteer to do it if =
you believe the softfork is necessary or itself will enable greater future =
profit.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Besides th=
at, I also just don&#39;t believe that UASF itself as a method to activate =
softforks is a good choice. The only two reliable signals we have for this =
purpose in Bitcoin are block height (flag day) and standard miner signaling=
, as every other metric can be falsified or gamed.=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">But there&#39;s also more problems - a big=
 one is that we have no way right now for a node to tell another &quot;the =
transaction you just relayed to me is invalid according to an active softfo=
rk&quot; (or &quot;will become invalid&quot;. This matters for several reas=
ons.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">The first one=
 that came to my mind is that we have widespread usage of zero-confirmation=
 payments in the network.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This was already dangerous for other reasons, but this UASF could=
 make it guaranteed cost-free to exploit - because as many also know, we AL=
SO already have a lot of nodes that do not enforce the non-default rejectio=
n policies (otherwise we&#39;d never see such transactions on blocks), incl=
uding many alternative Bitcoin clients.=C2=A0</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">The combination of these factors means that you can p=
resent an UASF invalid transaction to a non-updated client that is supposed=
ly protected by the deliberate orphaning effort, and have it accept this as=
 a payment. To never see it get confirmed, or to eventually see it doublesp=
ent by an UASF-valid transaction.=C2=A0</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I would not at all be surprised if it turned out that many =
zero-confirmation accepting services do not reject non-default transactions=
, or if they aren&#39;t all UASF-segwit aware.=C2=A0</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">This is why a flag day or similar is more effe=
ctive - it can&#39;t be ignored unlike &quot;just another one of those UASF=
 proposals&quot; that you might not have evaluated or not expect to activat=
e.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">This is by the =
way also a reason that I believe that all nodes and services should publish=
 all concensus critical policies that they enforce. This would make it far =
easier to alert somebody that they NEED TO prepare for whatever proposal th=
at might conflict with their active policies.=C2=A0</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>

--001a11410c648189f0054d34e872--