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 8768BE78 for ; Wed, 16 Dec 2015 21:36:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 322CBED for ; Wed, 16 Dec 2015 21:36:10 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id to4so85190229igc.0 for ; Wed, 16 Dec 2015 13:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s3So3Y08u3IYSowDzrcdtxlaDVf2/CO0e3ovG18gZ+4=; b=BmeD47hPlO5NOxatNqv5B+rQ8n9/uWtZcxBzsxteZq2KgfwJb4dt46vanYcf/exjre 0x9KZ1HVWjKaI7fkdzWfUvrXKpLsBV5/TNyd56Wp0B6ysMiL4Agaiel3pSRgtcnozYel /slsFXdONIJdS4xqEx7tQ1RbEfWGsDdm4OTqZ5hdPwDrlv88LlNzLDC0ejmJ3QPmHIbP VWVgJXys0Ve0xC8HGL1X6orAiC+FFyiYXA0+5URvoBWmgcJkEYE/QsV6WKMowSB0otPx DIUl/EG31sUU072FuUvGB+alc5KO6LhbFz82QD7FxL/wzSi2gEuEm2VW7bTdSQf2GZWM es/g== MIME-Version: 1.0 X-Received: by 10.107.165.197 with SMTP id o188mr21193442ioe.132.1450301769666; Wed, 16 Dec 2015 13:36:09 -0800 (PST) Received: by 10.36.80.6 with HTTP; Wed, 16 Dec 2015 13:36:09 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 22:36:09 +0100 Message-ID: From: Pieter Wuille To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list 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: Wed, 16 Dec 2015 21:36:10 -0000 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. Maybe I haven't explained this properly, so consider this example: A miner receives sets of 200 byte transactions with all identical fees. Non-witness ones (whose virtual size is thus 200 bytes) and a witness one (where 120 of the 200 bytes are witness data, so its virtual size is 80 + 120*0.25 = 110 bytes). The consensus rules would limit 1) the base size to 1000000 bytes 2) the virtual size to 1000000 bytes. However, as the virtual size is defined as the sum of the base size plus a non-negative number, satisfying (2) always implies satisfying (1). Thus, the miners' best strategy is to accept the witness transactions, as it allows 1000000/110=9090 transactions rather than 1000000/200=5000. In fact, the optimal fee maximizing strategy is always to maximize fee per virtual size. -- Pieter