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 83E13BBD for ; Fri, 24 Aug 2018 09:50:23 +0000 (UTC) X-Greylist: delayed 00:15:03 by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB2C22C3 for ; Fri, 24 Aug 2018 09:50:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1535103316; cv=none; d=zoho.com; s=zohoarc; b=QYwYbs2SiVd0zgrK3EsCohl1Vn1UUDshxrkQd89eUUfMjoSSFCnZk4iwUxWtIRMqYClBNuj71itWoKI+xk93QWxH/YMiRD612VY8mGb6FObJkeaOwdgDGugE8BcFtdZTE1ElA67L3zNHW6/aR/i8eVoeCIwNkzx3UcEIh5Zraug= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1535103316; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=MwFac5IQ9l2nIuZL52al4QMBqOsZZQxtb2jB3/5cTPQ=; b=hx9xa2XdXEAJFSlAdAzzxkFrnmbGOkHnpEQH/greYvWK1KOFjZBftvauRPWT50peOP1nD3ltaXHh0o1LBAeD+FNwgm5EmNLJjPykNl0DUNggXIUkyVIO14QhbV1WJko9A+7P5ZsKAoiykzN/Xe9uMhtOPhE7vWABVzLRLyslREo= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.103] (n218103136198.netvigator.com [218.103.136.198]) by mx.zohomail.com with SMTPS id 1535103314520453.2628338877438; Fri, 24 Aug 2018 02:35:14 -0700 (PDT) From: Johnson Lau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 24 Aug 2018 17:35:11 +0800 References: To: Gregory Maxwell , bitcoin-dev In-Reply-To: Message-Id: <50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk> X-Mailer: Apple Mail (2.3445.8.2) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 25 Aug 2018 12:10:20 +0000 Subject: Re: [bitcoin-dev] Getting around to fixing the timewarp attack. 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: Fri, 24 Aug 2018 09:50:23 -0000 To determine the new difficulty, it is supposed to compare the = timestamps of block (2016n - 1) with block (2016n - 2017). However, an = off-by-one bug makes it compares with block (2016n - 2016) instead. A naive but perfect fix is to require every block (2016x) to have a = timestamp not smaller than that of its parent block. However, a = chain-split would happen even without any attack, unless super-majority = of miners are enforcing the new rules. This also involves mandatory = upgrade of pool software (cf. pool software upgrade is not mandatory for = segwit). The best way is to do it with something like BIP34, which also = requires new pool software.=20 We could have a weaker version of this, to require the timestamp of = block (2016x) not smaller than its parent block by t-seconds, with 0 <=3D = t <=3D infinity. With a bigger t, the fix is less effective but also = less likely to cause intentional/unintentional split. Status quo is t =3D = infinity. Reducing the value of t is a softfork. The aim is to find a t which is = small-enough-to-prohibit-time-wrap-attack but also = big-enough-to-avoid-split. With t=3D86400 (one day), a time-wrap = attacker may bring down the difficulty by about 1/14 =3D 7.1% per round. = Unless new blocks were coming incredibly slow, the attacker needs to = manipulate the MTP for at least 24 hours, or try to rewrite 24 hours of = history. Such scale of 51% attack is already above the 100-block = coinbase maturity safety theshold and we are facing a much bigger = problem. With t=3D86400, a non-majority, opportunistic attacker may split the = chain only if we have no new block for at least 24 - 2 =3D 22 hours = (2-hours is the protocol limit for using a future timestamp) at the = exact moment of retarget. That means no retarget is possible in the next = 2016 blocks. Doing a time-wrap attack at this point is not quite = interesting as the coin is probably already worthless. Again, this is a = much bigger problem than the potential chain spilt. People will yell for = a difficulty (and time wrap fix, maybe) hardfork to resuscitate the = chain. =20 > On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev = wrote: >=20 > Since 2012 (IIRC) we've known that Bitcoin's non-overlapping > difficulty calculation was vulnerable to gaming with inaccurate > timestamps to massively increase the rate of block production beyond > the system's intentional design. It can be fixed with a soft-fork that > further constraints block timestamps, and a couple of proposals have > been floated along these lines. >=20 > I put a demonstration of timewarp early in the testnet3 chain to also > let people test mitigations against that. It pegs the difficulty way > down and then churned out blocks at the maximum rate that the median > time protocol rule allows. >=20 > I, and I assume others, haven't put a big priority into fixing this > vulnerability because it requires a majority hashrate and could easily > be blocked if someone started using it. >=20 > But there haven't been too many other network consensus rules going on > right now, and I believe at least several of the proposals suggested > are fully compatible with existing behaviour and only trigger in the > presence of exceptional circumstances-- e.g. a timewarp attack. So > the risk of deploying these mitigations would be minimal. >=20 > Before I dust off my old fix and perhaps prematurely cause fixation on > a particular approach, I thought it would be useful to ask the list if > anyone else was aware of a favourite backwards compatible timewarp fix > proposal they wanted to point out. >=20 > Cheers. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev