public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Cameron Garnham <da2ce7@gmail.com>,
	"Andreas M. Antonopoulos" <andreas@antonopoulos.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Date: Fri, 26 May 2017 01:15:56 -0700	[thread overview]
Message-ID: <c771e922-1121-e323-f4b8-ad99e0d930b8@voskuil.org> (raw)
In-Reply-To: <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Cameron,

Presumably the "very serious security vulnerability" posed is one of
increased centralization of hash power. Would this danger exist
without the patent risk?

e

On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote:
> Thank you for your reply Andreas,
> 
> I can assure you that I have many motivations for activating
> SegWit.
> 
> Before studding ASICBOOST I wanted to activate SegWit as it is a
wonderful upgrade for Bitcoin. It seems to me that virtually the
entire Bitcoin Ecosystem agrees with me.  Except for around 67% of the
mining hash-rate who very conspicuously refuse to signal for it’s
activation.
> 
> So, I started searching for the motivations of such a large amount
of the mining hash-rate holding a position that isn’t at-all
represented in the wider Bitcoin Community. My study of ASICBOOST lead
to a ‘bingo’ moment:  If one assumes that the 67% of the hash rate
that refuse to signal for SegWit are using ASICBOOST. The entire
picture of this political stalemate became much more understandable.
> 
> This only strengthened my resolve to activate SegWit: not only is
SegWit great, it partially mitigates a very serious security
vulnerability.
> 
> This is why I call into question why you would suggest:
> 
> “This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.”
> 
> 1. I am not conflating the issues.  I would argue that very fact
that SegWit has not been activated yet is directly because of
CVE-2017-9230.
> 2. I have no reason to believe that SegWit is contentious, except
for the attackers who it would frustrate.
> 3. I have no negative responses to my endeavours to get ASICBOOST
> as
regarded as a legitimate security vulnerability.  This would suggest
that it is not contentious in the wider technical community.
> 
> If SegWit is NOT contentious within the technical community and it
is NOT contentious to regard CVE-2017-9230 as a credible security
vulnerability. Then using it as partial security fix for a security
vulnerability SHOULD NOT be contentious.
> 
> If you believe that SegWit is contentious within the technical
community.  Or you believe CVE-2017-9230 should not be regarded as a
credible security vulnerability. Then I would logically agree with you
that we should separate the issues so that we may gain consensus.
However, I just don’t see this as the case.
> 
> Cameron.
> 
> 
>> On 26 May 2017, at 09:52 , Andreas M. Antonopoulos
<andreas@antonopoulos.com> wrote:
>> 
>> I rarely post here, out of respect to the mailing list. But
>> since
my name was mentioned...
>> 
>> I much prefer Gregory Maxwell's proposal to defuse covert
>> ASICBOOST
(only) with a segwit-like commitment to the coinbase which does not
obligate miners to signal Segwit or implement Segwit, thus disarming
any suspicion that the issue is being exploited only to activate Segwit.
>> 
>> This proposal is unnecessarily conflating two contentious issues
and will attract criticism of self serving motivation.
>> 
>> Politicising CVE  is damaging to the long term bitcoin
>> development
and to its security. Not claiming that is the intent here, but the
damage is done by the mere appearance of motive.
>> 
>> 
>> 
>> On May 26, 2017 16:30, "Cameron Garnham via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Hello Bitcoin-Dev,
>> 
>> CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a
>> severe
(3) (4) and actively exploited (5) security vulnerability.
>> 
>> To learn more about this vulnerability please read Jeremy
>> Rubin’s
detailed report:
>> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>> 
>> Andreas Antonopoulos has an excellent presentation on why
>> asicboost
is dangerous:
>> https://www.youtube.com/watch?v=t6jJDD2Aj8k
>> 
>> In decisions on the #bitcoin-core-dev IRC channel; It was
>> proposed,
without negative feedback, that SegWit be used as a partial-mitigation
of CVE-2017-9230.
>> 
>> SegWit partially mitigates asicboost with the common reasonable
assumption that any block that doesn’t include a witness commit in
it's coinbase transaction was mined using covert asicboost.  Making
the use of covert asicboost far more conspicuous.
>> 
>> It was also proposed that this partial mitigation should be
>> quickly
strengthened via another soft-fork that makes the inclusion of witness
commits mandatory, without negative feedback.
>> 
>> The security trade-offs of deploying a partial-mitigation to
CVE-2017-9230 quickly vs more slowly but more conservatively is under
intense debate.  The author of this post has a strong preference to
the swiftest viable option.
>> 
>> Cameron.
>> 
>> 
>> (1) CVE Entry: 
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230
>> 
>> (2) Announcement of CVE to Mailing List:
>> 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.
html
>> 
>> (3) Discussion of the perverse incentives created by 'ASICBOOST'
>> by
Ryan Grant:
>> 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.
html
>> 
>> (4) Discussion of ASICBOOST's non-independent PoW calculation by
Tier Nolan:
>> 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.
html
>> 
>> (5) Evidence of Active Exploit by Gregory Maxwell:
>> 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/01399
6.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZJ+Q1AAoJEDzYwH8LXOFOqakH/R1YCifIGjV07vnnsxeC/77x
d6w5tBmtEd5MLzrX/6VtMoI8UzgLEcDM1WfFox3jDVz/HurkTVorliyJrr14BVsc
rL2nTbfychYh1rAdTIsNwFt15Wgjcp/5eAq7Lw5TM5OJ3YbPn2zWJY19QmjEAJ+M
kGz26R+IJL1095yed5RN2JoN8O9x+HVdtIjaHJJRJzLsy+3g22zMWgN1nZN0olhX
mFQJZbvS0gQyiRGJmNku3zP5Qg2cFzWt+VBtFrzNu1QTTkbK2e1owHOmpgfygTD3
g3F4VoDfyA7pBnpMMMjjTaCaG34Am3CvYu8iYnZXy85s2ZjC+XeKgqMkBLj4+q8=
=A3ne
-----END PGP SIGNATURE-----


  reply	other threads:[~2017-05-26  8:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  6:30 [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 Cameron Garnham
2017-05-26  6:52 ` Andreas M. Antonopoulos
2017-05-26  8:02   ` Cameron Garnham
2017-05-26  8:15     ` Eric Voskuil [this message]
2017-05-26 19:20       ` Cameron Garnham
2017-05-26  9:21     ` Tom Zander
2017-05-26 14:39       ` Erik Aronesty
2017-05-26 14:54         ` Tom Zander
2017-05-27  6:37     ` Anthony Towns
2017-05-27 20:07       ` Eric Voskuil
2017-05-29 11:19         ` Anthony Towns
2017-05-31  6:17           ` Eric Voskuil

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=c771e922-1121-e323-f4b8-ad99e0d930b8@voskuil.org \
    --to=eric@voskuil.org \
    --cc=andreas@antonopoulos.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=da2ce7@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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