diff options
| author | Joseph Poon <joseph@lightning.network> | 2017-04-05 17:39:00 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-06 00:37:50 +0000 |
| commit | ff0aea49e84aa5907a635172d6d5db70551ca385 (patch) | |
| tree | c60bca83c5407a44abb998044901a5bf682bc85b | |
| parent | 894a86c9ca53f99857d3aa58eaf56c72db2dc09d (diff) | |
| download | pi-bitcoindev-ff0aea49e84aa5907a635172d6d5db70551ca385.tar.gz pi-bitcoindev-ff0aea49e84aa5907a635172d6d5db70551ca385.zip | |
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
| -rw-r--r-- | 2b/26e8e13ee58cea371feb8411a3e14f6d182b2f | 162 |
1 files changed, 162 insertions, 0 deletions
diff --git a/2b/26e8e13ee58cea371feb8411a3e14f6d182b2f b/2b/26e8e13ee58cea371feb8411a3e14f6d182b2f new file mode 100644 index 000000000..f3ea5ee99 --- /dev/null +++ b/2b/26e8e13ee58cea371feb8411a3e14f6d182b2f @@ -0,0 +1,162 @@ +Return-Path: <joseph@lightning.network> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 14BB7279 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Apr 2017 00:37:50 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7F4A015E + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Apr 2017 00:37:49 +0000 (UTC) +Received: by mail-pg0-f47.google.com with SMTP id g2so19386385pge.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 05 Apr 2017 17:37:49 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=lightning.network; s=google; + h=date:from:to:cc:subject:message-id:references:mime-version + :content-disposition:in-reply-to; + bh=kg32SspRjG2MQJKEv7dePyEqUmlFzPs8FhOcLjyAeHQ=; + b=YnEe/GaQI5Dr1rgWu71uYpX+LMCasvZV11dDz6AJdeGNkPMNqBGe8qwEgLexyCDuss + OIy9EJ8J0ExwCFyTDGQKkq2VniiIW0HicYN3wDpCqGMPETVoD5X81lxCi193Q9yTXbY2 + EE63cVcyygHRl4cyO3nZQWBLoP2jSmyb9PKCY= +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:date:from:to:cc:subject:message-id:references + :mime-version:content-disposition:in-reply-to; + bh=kg32SspRjG2MQJKEv7dePyEqUmlFzPs8FhOcLjyAeHQ=; + b=qwDjgKwmf8uer9p2pJoJlq8YjK5dIqqO2UOf/TG6QOfkM4sogTLFd+3XQoZGYOxNlC + i7hx5nltYhvioIGhBo5tXfinM/NJolPkOVYt4IRIQmSzyMDTbJgocwR5+1gNH0bCQPqw + hSO2XhQBjqGLRapshX4rIBHto8yWfA7wOyf0dcURhc5tCZT0EnJWR+UWUXgUgR82dowh + 4+sPv2QDCVMX9DhfFRAaeSKCDrUlmrHiVGwWAtAPeKkHECcMM7cVk3h6uGgvoPHlHSkf + +2BjSiIHtK6zrLDN7L2/o2mmp9ilyZbmzjjxfkXzIhkiUZiHcuCE/Mu1TDWNQsvZZuhv + 5NJQ== +X-Gm-Message-State: AFeK/H0efC922W08HGikObMHH7awCRWerrA7Ur4ou9uK4QjsVQX1S0Vi96XFIyioPvjsZw== +X-Received: by 10.99.181.86 with SMTP id u22mr33480227pgo.102.1491439068876; + Wed, 05 Apr 2017 17:37:48 -0700 (PDT) +Received: from localhost ([205.185.122.187]) by smtp.gmail.com with ESMTPSA id + q86sm11379538pfk.43.2017.04.05.17.37.47 + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 05 Apr 2017 17:37:48 -0700 (PDT) +Date: Wed, 5 Apr 2017 17:39:00 -0700 +From: Joseph Poon <joseph@lightning.network> +To: Gregory Maxwell <greg@xiph.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20170406003900.GB8379@lightning.network> +References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com> + <1491433518.2765667.935644008.2B153D86@webmail.messagingengine.com> + <CAAS2fgS9dOxJDU0WU87aSJhvYbYu60kVnO6acE0G7QJFw4AQLQ@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CAAS2fgS9dOxJDU0WU87aSJhvYbYu60kVnO6acE0G7QJFw4AQLQ@mail.gmail.com> +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, + 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 +Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the + Bitcoin POW function +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: Thu, 06 Apr 2017 00:37:50 -0000 + +#bitcoin@freenode: + 00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff. + +Are you *fucking* serious? Is this how you resolve all problems? I'm +taking you seriously and having second thoughts and want to make public +commitments to do the right thing without any evidence and you come out +and say *this*? + +On Thu, Apr 06, 2017 at 12:17:17AM +0000, Gregory Maxwell via bitcoin-dev wrote: +> On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +> > This seems to be a serious security problem. Would it be possible to have +> > a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger +> > 3-6 months from release should be sufficient for enough of the economy to upgrade, +> > given the severity of the issue. +> +> Not 0.14.1 because that is in RC already and will hopefully be out in a week. +> +> I think the speed of adoption depends a lot of the level of support +> from the community. I don't believe there are any technical hurdles to +> implementing this relatively quickly (and I specifically propose using +> the users choice of the segwit commitment or a modified form in order +> to lower the technical complexity and risk). +> +> > BIP 141 says that the the commitment is optional if there are no SegWit transactions in +> > the block, so will today's SegWit-ready miners always produce it even when optional +> > according to BIP 141, as required by this softfork? +> +> This is the default behavior as of 0.13.2, but I haven't gone out to +> measure this which is why the backwards compatibility section of the +> BIP isn't written yet. +> +> +> While I'm posting, I've had a dozen off-list emails that presented me +> with some FAQ: +> +> Many people asked what other protocol upgrades beyond segwit could run +> into the same incompatibility. +> +> Many proposed improvements to Bitcoin require additional +> transaction-dependent commitment data. +> +> Examples include: +> +> (1) Segwit. +> (2) UTXO commitments. (non-delayed, at least) +> (3) Committed Bloom filters +> (4) Committed address indexes +> (5) STXO commitments (non-delayed). +> (6) Weak blocks +> (7) Most kinds of fraud proofs +> -- to state a few. +> +> Unfortunately, putting *any* commitment to data dependent on the right +> hand side of the hash tree in the left hand side (e.g. coinbase) means +> a massive increase in the computation required for covert boosting, +> because it means you can't use the left+right side combinations to +> eliminate most of the hashing. +> +> It's plausible, in fact, that this extra computation could completely +> nullify the ASICBOOST advantage-- though this depends a lot on the +> fine details of the implementation. +> +> This proposal does not itself propose nullifying ASICBOOST entirely, +> it proposes severely handicapping the covert form of it, and +> eliminating the differential advantage for boosting miners related to +> the use of transaction-dependent commitments. +> +> Basically there are two completely separate concerns: that boosting +> can produce a monopoly advantage which could be severely harmful to +> the ecosystem, and that the efficient implementation of _covert_ +> boosting can severely harm many useful protocol improvements. My +> proposal only addresses the second concern, by (I believe) completely +> leveling the playing field so that opposing commitments will not break +> boosting any worse, and by making covert boosting less appealing in +> general. +> +> Use of the segwit-style commitment even in non-segwit blocks is sufficient +> because the segwit commitment commits to all transactions (except +> the coinbase) and not just segwit ones. +> (It was designed this way so that lite clients that needed witness +> data could work with just one tree). +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + +-- +Joseph Poon + |