Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Cameron Garnham <da2ce7@gmail.com>]

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/013996.html
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev