Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E9FF5A7 for ; Sat, 1 Apr 2017 15:34:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.161.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79C22136 for ; Sat, 1 Apr 2017 15:34:26 +0000 (UTC) Received: by mail-yw0-f172.google.com with SMTP id d191so49264103ywe.2 for ; Sat, 01 Apr 2017 08:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PoZ8HdNOOoj3okjbPdgYe4VqiPjktXiccC0t76+ACOA=; b=JGktNnwdJG/IIHnCjfUL6qJ8hMuOrxmmvDWKpyQgBVWS8vN5dOfC3izbGsHwYKaslH D8aWT+4WUhNBOklPZqhYRarY5fgwwajSpcilrcz6dM+GA7QDzxvy3BCMdKg6DL2C3oLi L4V/GdFgbRXH66oneQH9WevtnwHerITe1AOc356SiajipFffColwW8HOffaIBOqz94P1 dhq8q4b/D6aSzKjLqpep5ERuURxXRdHrdVoDJJxXbchvD4gt4/4813dm/8Hd/6i8Cg9t myGKJ8m6hqILcbbO/nYgAJR27WpMZwjUOV6ehdcPMFcaOvzt4GvNvRgIelkrw5WwrgvQ PvwA== 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; bh=PoZ8HdNOOoj3okjbPdgYe4VqiPjktXiccC0t76+ACOA=; b=eA+/BOy9vGv5/4YQn4Ah9Z6bH4zt9KZraT+PbnSpmsccCZ2BB1XQWoRshxOfLytEY7 smcYJvcGf7koEIxRLeO8999NfhR4lylYJSLXv9dkQPRvqev+3zK1dYmPg6qRgYRSQtNs XBLZbKhP55nTc1LOCE62VcRi0CXN16C6uCB80/zG3M1U8INhbIYOzX2ZvOjhwrKIAXv3 xQA7FwirnF4M0Ev+QgZqKbOC1rw4c4KsbXa07aP3U8ZV3TkYtB5FgG+E9cAA/wmHJbDq Y1VwlanVHnNEhNrJ+xseMS2W9H+a9aycaLhZ5WbXAQ17gGcXEJirOyrIYTmzTzebZWta 3x7w== X-Gm-Message-State: AFeK/H1kGmUJvF3LyAUK0cME5bVnJxW3Vm9qXnYinLZnuc6W4tMYS3nWwJrUP7uDvDbUYcLsKbbEnfrLmSyoow== X-Received: by 10.129.55.129 with SMTP id e123mr6265033ywa.251.1491060865602; Sat, 01 Apr 2017 08:34:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 08:34:24 -0700 (PDT) Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 08:34:24 -0700 (PDT) In-Reply-To: References: <1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com> From: Natanael Date: Sat, 1 Apr 2017 17:34:24 +0200 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a1149d3d83bb8cc054c1ca928 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 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: Sat, 01 Apr 2017 15:34:27 -0000 --001a1149d3d83bb8cc054c1ca928 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 say= . > > Segwit only separates out signature data. The 1 MB limit remains, but would > now only cover the contents of the transaction scripts. With segwit that > means we have two (2) size limits, not one. This is important to remember= . > Even with segwit + MAST for large complex scripts, there's still going to be > a very low limit to the total number of possible transactions per block. And > not all transactions will get the same space savings. 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 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 ratio. A hardfork increasing the size would likely have the ratio modified too. With exactly the same effect as if it was two limits... Either way, there's still going to be non-segwit nodes for ages. --001a1149d3d83bb8cc054c1ca928 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Den = 1 apr. 2017 16:07 skrev "Jorge Tim=C3=B3n" <jtimon@jtimon.cc&g= t;:
On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com<= /a>> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Tim=C3=B3n via bitcoin-dev&quo= t;
> <bitcoin-dev@lists.linuxfoundation.org>:
>
> 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 = say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but = would
> now only cover the contents of the transaction scripts. With segwit th= at
> means we have two (2) size limits, not one. This is important to remem= ber.
> Even with segwit + MAST for large complex scripts, there's still g= oing to be
> a very low limit to the total number of possible transactions per bloc= k. And
> not all transactions will get the same space savings.

No, because of the way the weight is calculated, it is impossible to<= br> 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.


Huh, that's odd. It really does still c= ount raw blockchain data blocksize.=C2=A0

It just uses = a ratio between how many units each byte is worth for block data vs signatu= re 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 ju= st means you replaced the two limits with one limit and a ratio.=C2=A0

A hardfork increasing the size would likely have the ratio = modified too. With exactly the same effect as if it was two limits...=C2=A0=

Either way, there's still going to be non-segwit n= odes for ages.=C2=A0
--001a1149d3d83bb8cc054c1ca928--