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 45CA0723 for ; Sun, 2 Oct 2016 22:56:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BDBDD2 for ; Sun, 2 Oct 2016 22:56:50 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id y190so115380319vkd.3 for ; Sun, 02 Oct 2016 15:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pYAAWmSrR6LjTNCEWvHuy9acoCSuQAippuTe9dL20vs=; b=Fsb/9OpyKTJ2LUSrDFy/aveQ8SS2+742nsWsmPt1Fjph/zSSM65u3hS7KdrWKfcAIV iZEv8jFKFqsDjZwWuKe20hFRf9tWBkqzJvjmE4K/CDt6Ej4Jf0BYtWFwwC0g5HNTis5M rSt+I8LS2NikVaV2gk32Nwf2Ylvkul/diBDsgwh89lH3h1xOjoCcea/VV36URP5Hg9sX RWnwvc4TzfCaTPFbOLaRQb21XzzfQQnUE/PJiOCGQkYhdWT3sQd/E27+d1OpfI/x2POL bFLDdWWbVs9WLpvbqcdbKbziYw64uqeR40X2kvgzk51utEU1E82Kt3ceWVpjdF9EVmDn UsDw== X-Gm-Message-State: AA6/9Rkxoo1FJOMIFkbyW+gx7J0AGAZxVUvjcc78QLLje3Tqq52yqLUHEey8vofb56B8kQ== X-Received: by 10.31.234.194 with SMTP id i185mr4695937vkh.127.1475449009271; Sun, 02 Oct 2016 15:56:49 -0700 (PDT) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com. [209.85.213.53]) by smtp.gmail.com with ESMTPSA id k24sm6786603uaa.28.2016.10.02.15.56.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Oct 2016 15:56:48 -0700 (PDT) Received: by mail-vk0-f53.google.com with SMTP id 192so146727648vkl.2 for ; Sun, 02 Oct 2016 15:56:48 -0700 (PDT) X-Received: by 10.31.58.140 with SMTP id h134mr12221548vka.20.1475449008626; Sun, 02 Oct 2016 15:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.117.80 with HTTP; Sun, 2 Oct 2016 15:56:48 -0700 (PDT) In-Reply-To: References: From: Timo Hanke Date: Sun, 2 Oct 2016 15:56:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Btc Drak Content-Type: multipart/alternative; boundary=001a1143f94a0b27cf053de9be71 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] About ASICBoost 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: Sun, 02 Oct 2016 22:56:51 -0000 --001a1143f94a0b27cf053de9be71 Content-Type: text/plain; charset=UTF-8 > When you proposed the extra nonce space BIP [1], you had already > applied for your ASICBOOST patent [2] without disclosure in the BIP > [1] nor in your Bitcoin Core pull request #5102 [2]. There may be quite a few things to clarify here, and a possible misunderstanding: The BIP proposal [1] and accompanying pull request [3] does not increase or decrease the entanglement of Bitcoin consensus code with any patents. This is indicated by the title of the pull request: "No forking Extra nonce added to Bitcoin header." It is not a fork at all (soft or hard). The consensus is not changed. AsicBoost is possible with or without adoption of that BIP proposal. Of several ways to implement AsicBoost (all described in the patent application), making use of the version field is only one. And even that particular one has always been possible since the beginning of Bitcoin and is still possible today. It is not the case that the BIP proposal enables AsicBoost in a way that wasn't possible before. The rationale behind the BIP proposal was to eliminate incentives to mess with the merkle root and, in the extreme case, to mine empty blocks. This incentive is real, and it is real with or without AsicBoost. It costs hardware manufacturers real $ in additional hardware components right now to cope with the pre-hashing load. Timo On Sun, Oct 2, 2016 at 12:36 PM, Btc Drak via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Sergio, > > It is critically important to the future of Bitcoin that consensus > code avoid any unnecessary entanglements with patents because "the > free market" allows you and anyone else to make consensus change > proposals that rely on (unknown) patents - but this is something we > should all be working to avoid, as it unnecessarily hinders Bitcoin > development and everyone's ability to deploy. Consensus code must not > be hindered by patents and Bitcoin should retain its permissionless > qualities. > > When you proposed the extra nonce space BIP [1], you had already > applied for your ASICBOOST patent [2] without disclosure in the BIP > [1] nor in your Bitcoin Core pull request #5102 [2]. > > The ASICBOOST patent [2] describes the same process as in the BIP [1] > and proposed code [3] "As we explained in our Provisional Application, > it has been proposed to partition the 4-byte Version field in the > block header (see, Fig. 6) and use, e.g., the high 2-byte portion as > additional nonce range." > > Today when you proposed a new sidechain BIP [4], Peter Todd was > (rightly) concerned about the prior lack of disclosure of your patents > related to your prior consensus modification proposal. Hence the > concern is that this might be happening this time as well. > > There is no evidence that any of the other filers for the > ASICBOOST-like patents by mining companies other than your own were > going to be using it offensively as those other companies appeared to > understand the decentralization risk of having an advantage enforced > by legal and not technical means. > > It's great that you have now committed to looking into the Defensive > Patent License. This seems likely to mitigate some of the patent > concerns. Although it would be a show of good faith if you also agreed > to license ASICBOOST under the DPL. > > [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki > [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en > [3]: Extra nonce pull request: https://github.com/bitcoin/ > bitcoin/pull/5102 > [4]: COUNT_ACKS > [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/ > 013174.html > > On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev > wrote: > > Please Peter Todd explain here all what you want to say about a patent > of a > > hardware design for an ASIC. > > > > Remember that ASICBoost is not the only patent out there, there are at > least > > three similar patents, filed by major Bitcoin ASIC manufacturers in three > > different countries, on similar technologies. > > > > That suggest that the problem is not ASICBoot's: you cannot blame any > > company from doing lawful commerce in a FREE MARKET. > > > > It is a flaw in Bitcoin design that could be corrected if the guidelines > I > > posted in [1] had been followed. > > > > [1] > > https://bitslog.wordpress.com/2014/03/18/the-re-design-of- > the-bitcoin-block-header/ > > > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1143f94a0b27cf053de9be71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> When you proposed the extra nonce space BIP [1],= you had already
> applied for your ASICBOOST patent [2] witho= ut disclosure in the BIP
> [1] nor in your Bitcoin Core pull r= equest #5102 [2].

There may be quite a few things = to clarify here, and a possible misunderstanding:

= The BIP proposal [1] and accompanying pull request [3] does not increase or= decrease the entanglement of Bitcoin consensus code with any patents. This= is indicated by the title of the pull request:=C2=A0"No forking Extra= nonce added to Bitcoin header." It is not a fork at all (soft or hard= ). The consensus is not changed.

AsicBoost is poss= ible with or without adoption of that BIP proposal. Of several ways to impl= ement AsicBoost (all described in the patent application), making use of th= e version field is only one. And even that particular one has always been p= ossible since the beginning of Bitcoin and is still possible today. It is n= ot the case that the BIP proposal enables AsicBoost in a way that wasn'= t possible before.

The rationale behind the BIP pr= oposal was to eliminate incentives to mess with the merkle root and, in the= extreme case, to mine empty blocks. This incentive is real, and it is real= with or without AsicBoost. It costs hardware manufacturers real $ in addit= ional hardware components right now to cope with the pre-hashing load.=C2= =A0

Timo


On Sun, Oct 2, 2016 at 12:36 PM, Btc D= rak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
Sergio,

It is critically important to the future of Bitcoin that consensus
code avoid any unnecessary entanglements with patents because "the
free market" allows you and anyone else to make consensus change
proposals that rely on (unknown) patents - but this is something we
should all be working to avoid, as it unnecessarily hinders Bitcoin
development and everyone's ability to deploy. Consensus code must not be hindered by patents and Bitcoin should retain its permissionless
qualities.

When you proposed the extra nonce space BIP [1], you had already
applied for your ASICBOOST patent [2] without disclosure in the BIP
[1] nor in your Bitcoin Core pull request #5102 [2].

The ASICBOOST patent [2] describes the same process as in the BIP [1]
and proposed code [3] "As we explained in our Provisional Application,=
it has been proposed to partition the 4-byte Version field in the
block header (see, Fig. 6) and use, e.g., the high 2-byte portion as
additional nonce range."

Today when you proposed a new sidechain BIP [4], Peter Todd was
(rightly) concerned about the prior lack of disclosure of your patents
related to your prior consensus modification proposal. Hence the
concern is that this might be happening this time as well.

There is no evidence that any of the other filers for the
ASICBOOST-like patents by mining companies other than your own were
going to be using it offensively as those other companies appeared to
understand the decentralization risk of having an advantage enforced
by legal and not technical means.

It's great that you have now committed to looking into the Defensive Patent License. This seems likely to mitigate some of the patent
concerns. Although it would be a show of good faith if you also agreed
to license ASICBOOST under the DPL.

[1]: BIP: https://github.com/BlockheaderNonce2= /bitcoin/wiki
[2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=3Den
[3]: Extra nonce pull request: https://github.com/bitcoi= n/bitcoin/pull/5102
[4]: COUNT_ACKS
[https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013174.htm= l

On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Please Peter Todd explain here all what you want to say about a patent= of a
> hardware design for an ASIC.
>
> Remember that ASICBoost is not the only patent out there, there are at= least
> three similar patents, filed by major Bitcoin ASIC manufacturers in th= ree
> different countries, on similar technologies.
>
> That suggest that the problem is not ASICBoot's: you cannot blame = any
> company from doing lawful commerce in a FREE MARKET.
>
> It is a flaw in Bitcoin design that could be corrected if the guidelin= es I
> posted in [1] had been followed.
>
> [1]
> https://bits= log.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-h= eader/
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a1143f94a0b27cf053de9be71--