Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C105E8DC for ; Tue, 9 May 2017 19:43:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7D6F127 for ; Tue, 9 May 2017 19:42:58 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 520CF139126; Tue, 9 May 2017 19:42:57 +0000 (UTC) To: Gregory Maxwell , Sergio Demian Lerner References: From: Matt Corallo Message-ID: Date: Tue, 9 May 2017 19:42:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 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: Tue, 09 May 2017 19:43:00 -0000 There is something in between throwing the SegWit goals out the window (as Sergio seems to be advocating for) and having a higher discount ratio (which is required for the soft fork version to be useful). When I first started looking at the problem I very much wanted to reduce the worst-case block size (though have come around to caring a bit less about that thanks to all the work in FIBRE and other similar systems over the past year or two), but rapidly realized that just reducing the Segwit discount wasn't really the right solution here. You might as well take the real win and reduce the cost of the input prevout itself so that average inputs are less expensive than outputs (which SegWit doesn't quite achieve due to the large prevout size - 40 bytes). This way you can reduce the discount, still get the SegWit goal, and get a lower ratio between worst-case and average-case block size, though, frankly, I'm less interested in the last one these days, at least for reasonable parameters. If you're gonna look at hard forks, limiting yourself to just the parameters that we can tweak in a soft fork seems short-sighted, at beast. Matt On 05/09/17 19:30, Gregory Maxwell wrote: > On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev > wrote: >> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum >> block size is the same. > > And the UTXO bloat potential is twice as large and the cost of that > UTXO bloat is significantly reduced. So you're basically gutting the > most of the gain from weight, making something incompatible, etc. > > I'm not sure what to explain-- even that page on segwit.org explains > that the values are selected to balance worst case costs not to > optimize one to the total exclusion of others. Raw size is not very > relevant in the long run, but if your goal were to optimize for it > (which it seems to be), then the limit should be pure size. >