From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 38FA1B6D for ; Thu, 18 May 2017 13:57:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 369851E8 for ; Thu, 18 May 2017 13:57:10 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id h4so54746490oib.3 for ; Thu, 18 May 2017 06:57:10 -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:content-transfer-encoding; bh=l5hV05UORdw8XrR+gxe8YywuxtQ/QPtgI1P3RT29ag4=; b=Fgp/q2Z+I37Kk0mwh5nLCPO13HtBQQvybcESVu8q35hvFdYTJ/PwuDKkeDBQHu1lZZ jC4DqWYfMMFgU+mR+FiHgnPQjd2psNiYZ1izIYymnVoz4hVzdkBqec8BR31dfccnVOei mhRBB0yybdhb8EJK+r9GmbQq5KI86ZkgbYlKrWi6QmGFAmRBpqOaasAjNvRAvkwXZCC0 RLbO0XlUta0nsvy2FzqwR/vAVJS8f5k7DYdV2g7iP6gxcSgnOnvsPdYNrO8vyQ/2PWK9 TuIhE7PnDQ95SBNiGMpgM/j9dkt0psQEikOxuQUixg919z70v90q1j4iYuFT9hGZh0nh KaiA== 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:content-transfer-encoding; bh=l5hV05UORdw8XrR+gxe8YywuxtQ/QPtgI1P3RT29ag4=; b=aPJgGGYkO3UrdtdCuQCmRaOB8uAAsKKEjwsLSl4ykRqcriiN9A0tFEgNiwLK77UPnq ffcYPU9TORoOoHLTJnwoLQB+1y1MLoba95yHYHocSOWjdut1xcfZloDwqA6k7oX9Yz6H 2XvE/7Uq75dPcovpLhRzzZ4GQly59oVITTiZDzGBFRWoHDZUu3jmdrA1S7ED1F6Y1YT4 FF3S4YSVVi0d6U5vHfF1wdvw/E0f3ijlV+eGdgEQ7k8wD2Zy0AIXbWYJv0X9ililxN66 ZA7/NbrSgNsOmrFNavw9qYyNyCnVO4oC5oDqi5ujavwGPw47Ch4Yxvil5tT3UOCdyEj6 uoVw== X-Gm-Message-State: AODbwcAE8bqdHScb8ymlumJgz7713+x/In93lEHr2QPlA+aDtGEehdYq wIgoTh0cFCD3godmZLiYI2NqyJdhcg== X-Received: by 10.157.45.231 with SMTP id g94mr2793561otb.229.1495115829475; Thu, 18 May 2017 06:57:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.130.166 with HTTP; Thu, 18 May 2017 06:57:08 -0700 (PDT) In-Reply-To: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com> References: <4BA0FA5D-7B29-4A7F-BC5B-361ED00D5CB2@gmail.com> From: James Hilliard Date: Thu, 18 May 2017 08:57:08 -0500 Message-ID: To: Cameron Garnham Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] =?utf-8?b?VHJlYXRpbmcg4oCYQVNJQ0JPT1NU4oCZIGFzIGEg?= =?utf-8?q?Security_Vulnerability?= 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: Thu, 18 May 2017 13:57:11 -0000 Locking the lower bits on the timestamp will likely break existing hardware that relies on being able to roll ntime. On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev wrote: > Hello Bitcoin Development Mailing List, > > I wish to explain why the current approach to =E2=80=98ASICBOOST=E2=80=99= dose not comply with our established best practices for security vulnerabi= lities and suggest what I consider to be an approach closer matching establ= ished industry best practices. > > > 1. Significant deviations from the Bitcoin Security Model have been a= cknowledged as security vulnerabilities. > > The Bitcoin Security Model assumes that every input into the Proof-of-Wor= k function should have the same difficulty of producing a desired output. > > > 2. General ASIC optimisation cannot be considered a Security Vulnerab= ilities. > > Quickly being able to check inputs is not a vulnerability. However, being= able to craft inputs that are significantly easier to check than alternati= ve inputs is a vulnerability. > > > 3. We should assign a CVE to the vulnerability exploited by =E2=80=98= ASICBOOST=E2=80=99. > > =E2=80=98ASICBOOST=E2=80=99 is an attack on this Bitcoin=E2=80=99s securi= ty assumptions and should be considered an exploit of the Bitcoin Proof-of-= Work Function. > > For a more detailed look at =E2=80=98ASICBOOST=E2=80=99, please have a lo= ok at this excellent document by Jeremy Rubin: > http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf > > The Bitcoin Community should be able to track the progress of restoring t= he quality of the Bitcoin Proof-of-Work function to its original assumption= s. > > > 4. Work should be taken to prudently and swiftly restore Bitcoins Sec= urity Properties. > > I recommend the Bitcoin Community fix this vulnerability with expediency. > > > > Cameron. > > PS: > > With a soft-fork it probably is possible to completely fix this Proof-of-= Work vulnerability. > > (Here is my working list of things to do): > > 1. Include extra data in the Coinbase Transaction, such as the Witnes= s Root. > > 2. Lock the Version. (Use a space in the Coinbase Transaction for sig= nalling future upgrades). > > 3. Lock the lower-bits on the Timestamp: Block timestamps only need ~= 1minute granularity. > > 4. Make a deterministic ordering of transaction chains within a bloc= k. (However, I believe this option is more difficult). > > Of course, if we have a hard-fork, we should consider the Proof-of-Work i= nternal merkle structure directly. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev