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 297C8B73 for ; Mon, 27 Feb 2017 16:50:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DA2818B for ; Mon, 27 Feb 2017 16:50:10 +0000 (UTC) Received: by mail-pg0-f52.google.com with SMTP id p5so22956895pga.1 for ; Mon, 27 Feb 2017 08:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yYkrwUlirpC+lQJyHeWHuBT7/QbUnJAA4QUwqcSFfDI=; b=ib7uTnz+fIl6/ZLpWqkp/ht62zuqG2MUCYVxxEezdPZSucx6KDwZjGkHX4IKUpSV61 0fuCZCpdmfEFbR52eVlN/OvodLeAA3BUtbEVbuycFuTPRnI9aaGkw13DPNKDxRVoSnnk P7kPDQ9hmqvd3UtnLqSt3T5iqEv5/yxZWd5Qfh6EkfZL9CSWnZsYF5ulDA8ChBDTz5DC mzrxg+OOAPbqcfCYImJdvAxklgDVyO3zICGqpDgyE9yvWGL2z2+Eh0uWXrBJaQiViAqv HSKDujuq/8nr8SDR0s+wRbZcuLhdeZMN0g45SyPvewTesZ+G4t5W4zeLpSW9nzV/Lh0Y gujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yYkrwUlirpC+lQJyHeWHuBT7/QbUnJAA4QUwqcSFfDI=; b=o6ju4QdFzeqOn5f/HXVN6Wo2gv0NYefHcgAsWaW8XaqwfE7i5kUszY0vagjufsBD10 AdqsTZXTvbf+z7kTkl4f3CwEdlgKH8JP3gf15GeWGPoYKpTr7Sr28oLUqcMcDvZzubrn aXoJJf2j3NEDj9bcOdh4jICui4rR2F12s0Lx9eX91jXVdqaR0gVnEWTd+xiZYzhslUt1 3++UlwkMV5xAX/FOm2wpUFgVXE1P1KYekPKRAIOS3q5ZAARC+KGRDrAlwScxfXJODf4T pRIfNSpQE/xTy4Ymh+t8xp8at75bAT5UIUSE37kawn+bm4fMOC8jVYmPVb8EcSGBuYGX OV6A== X-Gm-Message-State: AMke39kaJughXcTVtW6YQZ1Xb5OKUh5VlWfyaWz8QLD/V3jKc2ppRK77g3obJ8PnLFumLA== X-Received: by 10.98.63.24 with SMTP id m24mr21821797pfa.143.1488214209991; Mon, 27 Feb 2017 08:50:09 -0800 (PST) Received: from [10.200.137.56] (mobile-166-176-187-41.mycingular.net. [166.176.187.41]) by smtp.gmail.com with ESMTPSA id 9sm31652846pfk.121.2017.02.27.08.50.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 08:50:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Mon, 27 Feb 2017 08:50:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <09746CD6-10FB-4F3B-B4E1-AE12E504141B@voskuil.org> References: To: shaolinfry , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MIME_QP_LONG_LINE,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] Moving towards user activated soft fork activation 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: Mon, 27 Feb 2017 16:50:11 -0000 On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev wrote: >> 3) In terms of complexity for mining pool operators, how well does this m= odel scale if there are N soft forks and the pool doesn't want to opt-in to a= ny of them? Couldn't this result in those pool operators having to run not j= ust one border node, but a multitude of "chained" border nodes if the soft f= orks are spread across different software implementations? >=20 > While BIP9 allows for 29 parallel deployments I think it is unrealistic to= expect there would be such a high number of active parallel deployments at a= ny one time: History shows soft forks take a minimum of 6 months design, con= sensus building, coding and testing before deployment. With such a high bar,= I do not envisage more than a couple of parallel deployments at any given t= ime. I also do not envisage "conflicting" soft forks, as that would not meet= consensus from the technical community on the basis of safety and sanity. I= n any case, the deployment strategy of each soft fork should be considered o= n a case by case basis. The relationship between a codebase and chain fork implementations is simila= r to vendor lock-in, and is being used in a similar manner. There is nothing preventing a single codebase from implementing all forks an= d exposing the option to apply any non-conflicting combination of them. While this has not been the norm libbitcoin now utilizes this approach. Curr= ently the options to apply any activated Bitcoin forks are exposed via confi= g. I personally am not working to implement non-activated forks at this poin= t, but that's just prioritization. Recently I objected to BIP90. This hard fork is presented as a code simplifi= cation and a performance optimization. I showed in the discussion that it wa= s neither. Nevertheless we implemented this additional code and give the use= r the option to apply it or not. It's application produces no performance be= nefit, but it ensures that the choice of forks remains in the hands of the u= ser. e=