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 BE06F71F for ; Fri, 7 Apr 2017 12:59:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2AB30107 for ; Fri, 7 Apr 2017 12:59:36 +0000 (UTC) Received: by mail-qt0-f175.google.com with SMTP id x35so59755666qtc.2 for ; Fri, 07 Apr 2017 05:59:36 -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=eHXA7TeHXoC3grukdh6fczQJ0qm1YgmZY1u/1b6zM9Q=; b=eZqleaReBdZbIBgqQSFbMJV1OPSc9CsJr0IqElyqiFLnGhmR/j38/XQVCbQJqrBdFZ VLRkR7hIyh85I9DY4KlRAAoI/ktbFpjcc4mV0/lSur7xm3gicOQE7wOgtplETh0i6Uur T880TSCslqdCp7OuNZ8hWgJBdWt4RxDi1P2DOlILrxM9d36XtDyA2Cvd4VmMuv/jTnOo HzHJV4gc1SLXxGZJO3qaC+s3IjzPdCItjumhS+6Uov22dI3Y7Yr+g+7TCpenCaQJqzXD +dPzQ7Isn6IUZ2JKyeC/vYORTFSZUsu8Y3FYIkJypafET/hC1PderrPGHR20jqfNkJE3 6agw== 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=eHXA7TeHXoC3grukdh6fczQJ0qm1YgmZY1u/1b6zM9Q=; b=VxFITwug2yxiTbyYIZHgyjVeI/XkQvbs9a6+oIm9KP7cPa+fWXMwbGI4H5Ua16FP4p SPWF61knyqqd163Wye//moMymNR09IgHakK/RfCICRn4lUUOuS0gIWlnABks5BIOPehB TqlXGL4z1uFG3wDDayqv6V/tDKcX8yIxhZaex6m3FtrYBcK5LHxN8fEQDzfZh00Z9E+6 ELgMuYq2rcP344opHPlCswCS/8hUbC7kpDnrRzQIqVw1MUjriTUC1lCdMftG7OP7NDdf vJsnqDt5hsLfEnEdT1hENK2gYTLNu7qjNQdUAYBblLXfvLn0Rddw2CXZoSxcwKMI22BM jtIQ== X-Gm-Message-State: AFeK/H31W1M2z4tEIVm9tgJUm1UPs9nwUbrC++u+cxr5Nqzg78zT0aYmCL69tYzjMSII/Q== X-Received: by 10.200.45.59 with SMTP id n56mr40111322qta.137.1491569975194; Fri, 07 Apr 2017 05:59:35 -0700 (PDT) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com. [209.85.220.182]) by smtp.gmail.com with ESMTPSA id r13sm2999662qkh.24.2017.04.07.05.59.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 05:59:34 -0700 (PDT) Received: by mail-qk0-f182.google.com with SMTP id p68so36552455qke.1 for ; Fri, 07 Apr 2017 05:59:34 -0700 (PDT) X-Received: by 10.55.182.193 with SMTP id g184mr23934787qkf.20.1491569974146; Fri, 07 Apr 2017 05:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.4 with HTTP; Fri, 7 Apr 2017 05:59:13 -0700 (PDT) In-Reply-To: References: <20170406023123.GA1071@savin.petertodd.org> <20170406024910.GA1271@savin.petertodd.org> From: Jannes Faber Date: Fri, 7 Apr 2017 14:59:13 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alex Mizrahi , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c06e5fa779013054c9332cf X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 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: Fri, 07 Apr 2017 12:59:36 -0000 --94eb2c06e5fa779013054c9332cf Content-Type: text/plain; charset=UTF-8 On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Ethically, this situation has some similarities to the DAO fork. > > > Much better analogy: > > 1. An ISV make software which makes use of an undocumented OS feature. > 2. That feature is no longer present in the next OS release. > 3. ISV suffers losses because its software cannot work under new OS, and > thus people stop buying it. > > I think 99% of programmers would agree that this loss was inflicted by a > bad decision of ISV, and not by OS vendor changing OS internals. Relying on > undocumented features is something you do on your own risk. > Right. And in this case, code still is law: if the code specifies a version number field and some miner finds an optimization that only works when the version number == 1 then it's his own problem once the network upgrades to version 2. In no way is there anything ethical about blocking the upgrade. History is not an indicator of the possible values any field can hold in the future. Limiting your operation to some arbitrary subset is at your own risk. Regarding the comparison: I haven't heard anyone even suggest rolling back the last year of the blockchain to undo the damage already done, any comparison can end there. If Jonathan wants to persist with this comparison it would be more like people deciding to stop further funding of the hacked contract. Yeah, that evil. -- Jannes Faber --94eb2c06e5fa779013054c9332cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:

Ethica= lly, this situation has some similarities to the DAO fork.=C2=A0

Much better analogy:

= 1. An ISV make software which makes use of an undocumented OS feature.
2. That feature is no longer present in the next OS release.
3. ISV suffers losses because its software cannot work under new OS, and = thus people stop buying it.

I think 99% of program= mers would agree that this loss was inflicted by a bad decision of ISV, and= not by OS vendor changing OS internals. Relying on undocumented features i= s something you do on your own risk.

Right. And in this case, code still is law: if the code s= pecifies a version number field and some miner finds an optimization that o= nly works when the version number =3D=3D 1 then it's his own problem on= ce the network upgrades to version 2. In no way is there anything ethical a= bout blocking the upgrade.

History is not an indic= ator of the possible values any field can hold in the future. Limiting your= operation to some arbitrary subset is at your own risk.

Regarding the comparison: I haven't heard anyone even suggest ro= lling back the last year of the blockchain to undo the damage already done,= any comparison can end there. If Jonathan wants to persist with this compa= rison it would be more like people deciding to stop further funding of the = hacked contract. Yeah, that evil.

--
Jan= nes Faber

--94eb2c06e5fa779013054c9332cf--