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 0B9096C for ; Sun, 2 Apr 2017 04:57:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18FDAA4 for ; Sun, 2 Apr 2017 04:57:49 +0000 (UTC) Received: by mail-ua0-f172.google.com with SMTP id d64so13385881uad.2 for ; Sat, 01 Apr 2017 21:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0hLZZHB7npnvHBGTi6kI2mWUA/JU5KeKBORhl4u6ZTs=; b=nQt76o6lyAqqusefIcdBbEFYjN5A9rgxlKblVpIo6L4WMZscPaA4wTmQuYKgjNqeLk h8bGkiRipolTmLTBnup411s362OMPCO+6rNh8O5xPGkfPu1DjENUTcA+c8gHdTGJRFSO Jas8eGnZWJpUHBAAUbPZTO5++DxNvFOZm7X2r8rSLHONYHWW2SOSztxofbkJ4oC9+OZL yBLrb4Wf2L4cn7+oycnOcTuQvWDmarpmSajmznXB2rke4qO4ffvy4ltfWBY89K4umkML 52bK1l0njCNSLPwAF/JyGebDiPuCjxJmmO30aY8bfszSVLpzAvPk28iv2NLTj6VAj2Xj nG+A== 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:content-transfer-encoding; bh=0hLZZHB7npnvHBGTi6kI2mWUA/JU5KeKBORhl4u6ZTs=; b=HiLFzBP1Lmsb8WN5XCDkPwlW7x1jnWY6H/92ofpWdAIoj1+Zwkf+BYhZ8KgxNwhi/K D5cbYfgCn29uRYYHUHRVbpu87tmNg1gAmNOOxyoVhFNUa9ouMOZNeM9F7WUST9QDI4uf XerPKqq9Trm2l8mZus2NWqzBY1a5hhCpqYo5fQA8+mhCftraefPgFCCevcAv2doCST+3 K8kfd2z8NsOAxFLIQXtorrkA++ygQCbgIAIfXQDHwn7GDxnq4P4diax1NG2xfX1HycxZ cIRqmlFSGDqXH5Ch4p4R2W+JMkutNFLYlnZcLeQs3k1WknR16uxn9s+CRxFtjbYa/hEj enCA== X-Gm-Message-State: AFeK/H0Zis1B7uCWZoGV/jsVfwnHTY2rrDE5p7dQ2vFTo4nMjrgOr5lLFY/6LzEJnHEi3UFFT3bAXJbBeG4yJQ== X-Received: by 10.159.48.81 with SMTP id i17mr5567062uab.65.1491109069012; Sat, 01 Apr 2017 21:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.151.136 with HTTP; Sat, 1 Apr 2017 21:57:48 -0700 (PDT) In-Reply-To: References: <1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sun, 2 Apr 2017 06:57:48 +0200 Message-ID: To: Natanael Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,URIBL_BLACK autolearn=no 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] Segwit2Mb - combined soft/hard fork - Request For Comments 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: Sun, 02 Apr 2017 04:57:51 -0000 On Sat, Apr 1, 2017 at 5:34 PM, Natanael wrote: > Den 1 apr. 2017 16:07 skrev "Jorge Tim=C3=B3n" : > On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: >> Den 1 apr. 2017 14:33 skrev "Jorge Tim=C3=B3n via bitcoin-dev" >> : >> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. >> That would make it a hardfork, not a softfork, if done exactly as you sa= y. > No, because of the way the weight is calculated, it is impossible to > create a block that old nodes would perceive as bigger than 1 mb > without also violating the weight limit. > After segwit activation, nodes supporting segwit don't need to > validate the 1 mb size limit anymore as long as they validate the > weight limit. > > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size > > Huh, that's odd. It really does still count raw blockchain data blocksize= . It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be a more restrictive rule than "< 1 mb size"? Well, it is, that's why segwit's size increase is a softfork. It is not that hard once you look at the actual weight formula: segregated_sigs_sise + (other_size * 4) < 4 "mb" It is impossible to produce to produce a block that violates the 1 mb size limit but doesn't violate the 4 mb weight limit too. There can be block that are < 1 mb size but 20 mb in weight, but those are invalid according to the new 4 mb weight rule. At the same time, any block that violates the < 1 mb rule for old nodes will be invalid not only to old nodes but also to any node validating the new 4mb rule. This is not by chance but a design choice for any block size increase within segwit to remain a softfork, which is what can be deployed faster. One extreme example would be any 1 mb block today. 1 "mb" of a block today times 4 is 4 mb, so it complies with the new 4 mb weight rule. The opposite extreme example would be 4 mb of signatures and 0 mb of "other data", but this example is not really possible in practice because signatures need some tx to be part of to be part of the block itself. The most extreme examples I have seen on testnet are 3.7 mb blocks, but those don't represent the average usage today (whenever you read this). One common misunderstanding is that users who aren't using payment channels (that includes lightning but also other smart contracts) or users that aren't using mutlisig can't enjoy the so called "discount": there's no reasonable argument for rejecting the "discount" on your own transactions once/if segwit gets activated. I would prefer to call the absence of "discount" *penalization*. Signatures are unreasonable penalized pre-segwit, and there's more things that remain unreasonably penalized with respect to their influence on the current utxo after segwit. But signatures are by far the biggest in data space and validation time, and the most important unreasonable yet unintended penalization pre-segwit. > It just uses a ratio between how many units each byte is worth for block > data vs signature data, plus a cap to define the maximum. So the current = max > is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x = =3D 4 > MB. That just means you replaced the two limits with one limit and a rati= o. Exactly, once one maximum limit is defined, no need for two limits. But the current max is 1 mb size, not 4 mb weight until/unless segwit is activated. Some people complain about 4 mb weight not being as much as 4 mb size, and that is correct, but both are bigger than 1 mb size. > A hardfork increasing the size would likely have the ratio modified too. If the single ratio needs to be modified, it can be modified now before any rule changes are activated, no need to change the consensus rules more than needed. > With exactly the same effect as if it was two limits... If you don't see any disadvantage on having one single limit if/when segwit gets activated, I don't see the point of maintaining two limits, but if you're happy to maintain the branch with the redundant one you may get my ack: I don't see any disadvantage on checking the same thing twice besides performance, > Either way, there's still going to be non-segwit nodes for ages. That's precisely why it's good segwit has been designed to be backward compatible as a bip9 softfork.