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 69455516 for ; Thu, 6 Apr 2017 03:23:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B924B196 for ; Thu, 6 Apr 2017 03:23:24 +0000 (UTC) Received: by mail-wr0-f174.google.com with SMTP id t20so41089786wra.1 for ; Wed, 05 Apr 2017 20:23:24 -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; bh=M7r8M3DICnIZdcZugHQNYzXHgJ8CgutkYT06LhDnOCk=; b=SAVpssJGwYXcTmzQKTo59O/WU8exXQpyq9Y1vhwaRkKGnmYveviMKl33ZES5sUgo+g +G7MzKgqky3914VDwXdeuUpE8ts1dYWiLmWNph+ptlZAQGE2qbWlT635WIWf9yk6IgtJ Vi323G2btWMJNhbR8105IdGjQKU0DY0j/dE/goFC+dW0OagZOAFYSOQv805isXMBxFT+ YFmK3sXxS4YHaqMgW38mi0AcWELYsC9l/bbucDTCTQRXczectgJXNv27ScgiwivhcV85 Zq57TDOb1a1L0aFDxcRp9Yz8X7JYwLn/bINTDmqBZdIFBax0ss4HdQPogEkdGVVHstuG TqjA== 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; bh=M7r8M3DICnIZdcZugHQNYzXHgJ8CgutkYT06LhDnOCk=; b=UFghhKkr3sDXbO7nREDIrPSDgZXdJzQUpcRmNQkCbvTdqcXp3NDVLQG8K4btX73bY9 ya9oqlKWNx1BYWXdnth/V0v9zu8+cUwTxw+WdZC10FYfU3t2g3Yiyf+MwmKmA31X2QGu 7YDZUDmh9493V14LEZ6+f9vGHJjm8ywp0K5zJMHg8qUfwQqyp7Xkn7FF9nGZvxDbLmDs 9FFKqlLCFloAwB4ct8y22apJFmAgS3Kv6mcwcJVtitiXq0ghtX6hKb54OOoquBu3q8Ks 7HHP1FXIdOHq8Qdo+Yy+vy8d95NCeFfTAiI5V+a1Di4qta3Xh9hD/WiD6eU+66CRXYkT l2+Q== X-Gm-Message-State: AFeK/H2Z0R0LQ2P5/UcZ2viCrB1HhVmUyDOLieRsKeRo9nbT3Az2vZYLLxw1QqFiLiichxOlekiHUCOhOMUUdA== X-Received: by 10.223.148.102 with SMTP id 93mr25517273wrq.144.1491449003178; Wed, 05 Apr 2017 20:23:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.55.9 with HTTP; Wed, 5 Apr 2017 20:23:22 -0700 (PDT) In-Reply-To: <20170406024910.GA1271@savin.petertodd.org> References: <20170406023123.GA1071@savin.petertodd.org> <20170406024910.GA1271@savin.petertodd.org> From: David Vorick Date: Wed, 5 Apr 2017 23:23:22 -0400 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0d257409040f054c770857 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 03:23:25 -0000 --94eb2c0d257409040f054c770857 Content-Type: text/plain; charset=UTF-8 I have a practical concern related to the amount of activation energy required to get something like this through. We are talking about implementing something that would remove tens to hundreds of millions of dollars of mining revenue for miners who have already gambled that this income would be available to them. That's not something they are going to let go of without a fight, and we've already seen this with the segwit resistance. Further, my understanding is that this makes a UASF a lot more difficult. Mining hardware that has unique optimizations on one chain only can resist a UASF beyond a simple economic majority, because they can do more hashes on the same amount of revenue. Threshold for success is no longer 51%, especially if you are expecting the miners to struggle (and this is a case where they have a very good reason to struggle). Any resistance from the hashrate during the early days of a UASF will inevitably cause large reorgs for older nodes, and is not much better than a hardfork. I don't know what the right answer is. But I know that we are not going to get segwit without a fight. We are not going to invalidate covert asicboost without a fight. And we are working with a system that actively (and is demonstrably very effective at doing it) resists changes which are contentious. This is definitely a contentious change, because an important part of the community (the miners) is going to be actively resisting it. I urge everybody to realize how difficult something like this is going to be to pull off. We are literally talking about invalidating hardware (or at least the optimized bits). It's only going to succeed if everybody is conclusively on board. As you consider proposals, realize that anything which is not the simplest and least contentious is already dead. --94eb2c0d257409040f054c770857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a practical concern related to the amount= of activation energy required to get something like this through. We are t= alking about implementing something that would remove tens to hundreds of m= illions of dollars of mining revenue for miners who have already gambled th= at this income would be available to them.

That's not some= thing they are going to let go of without a fight, and we've already se= en this with the segwit resistance. Further, my understanding is that this = makes a UASF a lot more difficult. Mining hardware that has unique optimiza= tions on one chain only can resist a UASF beyond a simple economic majority= , because they can do more hashes on the same amount of revenue. Threshold = for success is no longer 51%, especially if you are expecting the miners to= struggle (and this is a case where they have a very good reason to struggl= e). Any resistance from the hashrate during the early days of a UASF will i= nevitably cause large reorgs for older nodes, and is not much better than a= hardfork.

I don't know what the right answer is. But= I know that we are not going to get segwit without a fight. We are not goi= ng to invalidate covert asicboost without a fight. And we are working with = a system that actively (and is demonstrably very effective at doing it) res= ists changes which are contentious. This is definitely a contentious change= , because an important part of the community (the miners) is going to be ac= tively resisting it.

I urge everybody to realize how diff= icult something like this is going to be to pull off. We are literally talk= ing about invalidating hardware (or at least the optimized bits). It's = only going to succeed if everybody is conclusively on board. As you conside= r proposals, realize that anything which is not the simplest and least cont= entious is already dead.
--94eb2c0d257409040f054c770857--