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 0723FEEB for ; Thu, 17 Dec 2015 03:52:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCBFA89 for ; Thu, 17 Dec 2015 03:52:28 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1a9PcA-0007R1-5F for ; Thu, 17 Dec 2015 13:52:27 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 17 Dec 2015 13:52:22 +1000 Date: Thu, 17 Dec 2015 13:52:22 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151217035222.GA7713@sapphire.erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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] Segregated Witness in the context of Scaling Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 03:52:30 -0000 On Wed, Dec 16, 2015 at 10:36:09PM +0100, Pieter Wuille via bitcoin-dev wrote: > On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik wrote: > >> Not correct. I propose defining the virtual_block_size as base_size + > >> witness_size * 0.25, and limiting virtual_block_size to 1M. This > >> creates a single variable to optimize for. If accepted, miners are > >> incentived to maximize fee per virtual_block_size instead of per size. > > It is correct. There are two separate sets of economic actors and levels of > > contention for each set of space. > > That is true regardless of the proposed miner selection algorithm. You're right that the miner selection algorithm doesn't force it to be the way Pieter describe. But your claim is still incorrect. :) > Maybe I haven't explained this properly, so consider this example: Alternatively: With Pieter's segwit proposal (as it stands), there are two consensus-limited resources: number of signature ops in the base block must be no more than 20k, and the virtual block size must be no more than 1MB (where virtual block size = base block size plus a quarter of the witness data size). Nodes and miners have other constraints -- bandwidth, storage, CPU, etc, such that they might not want to max out these limits for whatever reason, but those limits aren't enforced by consensus, so can be adjusted as technology improves just by individual miner policy. > In fact, the optimal fee maximizing strategy is always to maximize fee > per virtual size. (modulo sigop constraints, same as today for fee per base block size) That's on the "supply" side (ie, miners are forced to be a single group of economic actors with alighned constraints due to consensus rules). On the demand side, there might be people who are able to trade off witness data for base data at different ratios. For most, it's just 1:1 up to a limit as they move scriptsig to witness data, and obviously if you have to trade 1B of base data for more than 4B of witness data it's uneconomic. But since the ratio is fixed, there's no bartering to be done, it's just the same simple calculation for everyone -- does 1B of base convert to <4B of witness? then do it; otherwise, don't. But once they've selected a tradeoff, all they can do is choose an absolute fee value for their transaction, and then you're just back to having some people who are willing to pay higher fees per virtual block size, and others who are only willing to pay lower fees. Cheers, aj