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 82C97B62 for ; Fri, 2 Jun 2017 19:40:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2F7E257 for ; Fri, 2 Jun 2017 19:40:37 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id x47so50465939uab.0 for ; Fri, 02 Jun 2017 12:40:37 -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:content-transfer-encoding; bh=qdWtv5pF7WET/L2s8libF7R60lx09c7SOu9Ut9cRrBI=; b=TJAH/McayH/8ctlKwcqseWKFl+HNx/alMwZ/9pbLc+ngci+UVNxqgq/Vzth36zshnx zI+OKJ9CYWqEjGYJBWD12x/AYPUt2XZXO4dXs9zRGh/wk5WZyi4K/SLJaTlTqdnFpEJ+ 7qJHKKQFU7g8HnBB1HZJRa6dBElonjcmfAXavNg16YeE/t7T9CL6rYM0rvswKF97efRJ W6Z1aZWAWo4xOlLF7Mb/g/F3LE9mDG9pfIqwUhmM4iJXhnUVh0W2YAFeceTR/hkEhti+ 79MtNVML4W8FBFQ3mZgKV/SPtAo1kCmn3CnUuSQoG6MVDaV/4aq41M/QYXGr+Z3Zo61G 0lAg== 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=qdWtv5pF7WET/L2s8libF7R60lx09c7SOu9Ut9cRrBI=; b=BoIJMQMpNMlZbusv9m4flXmTalEhfw0VTkG0T6Xnoh/9Xna73HFSC9HkLcAobUlXZH DnkoX0+iPhiCYbVUyOEmxEgxWOTfdGnJXJ6ZeERjzvWeSR7vOhZXD4sVGhOW5lqfEL2G UO3vpw9RfZbKouxQ1sakDOWOeyH3M6XIdzurSlj4T6ZPKze7RGRZuLz+P6B3AP6WN8OM O7zTtBcme/fgH/2I/kIbOCebCd2HqGBblGJT4wRoZrf5yhzv27sYZRObA4nC0HRYU12q Slzmp6GZODJaKcj7n0kguY4tuRjjte/CBc/ae+Y7t//2QIU8+PGGM1B1kGY6KnQ0diTp dKbA== X-Gm-Message-State: AODbwcDI+EIbsAK1XSIW8odgcbs0D1YVY32YyjoMgwhOfpxeGr2YzKSl D8tkgdLkFuu7Z0Ra6vO9M8v3qQ1PtA== X-Received: by 10.176.25.99 with SMTP id u35mr4739122uag.16.1496432436782; Fri, 02 Jun 2017 12:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.215 with HTTP; Fri, 2 Jun 2017 12:40:36 -0700 (PDT) In-Reply-To: References: <201705232023.40588.luke@dashjr.org> <004E1123-8346-48B6-9BCB-94BAE00EC34B@me.com> From: Jared Lee Richardson Date: Fri, 2 Jun 2017 12:40:36 -0700 Message-ID: To: Jacob Eliosoff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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 X-Mailman-Approved-At: Fri, 02 Jun 2017 21:26:58 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 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: Fri, 02 Jun 2017 19:40:39 -0000 > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has q= uadratic hashing risks, and maybe James' 10KB is too ambitious; but even if= so, a simple 1MB tx size limit would clearly do the trick. The broader po= int is that quadratic hashing is not a compelling reason to keep blockmaxsi= ze post-HF: does someone have a better one? I think this is exactly the right direction to head. There are arguments to be made for various maximum sizes... Maybe the limit could be set to 1mb initially, and at a distant future block height(years?) automatically drop to 500kb or 100kb? That would give anyone with existing systems or pre-signed transactions several years to adjust to the change. Notification could (?possibly?) be done with a non-default parameter that must be changed to continue to use 100kb - <1mb transactions, so no one running modern software could claim they were not informed when that future date hits. I don't see any real advantages to continuing to support transactions larger than 100kb excepting the need to update legacy use cases / already signed transactions. On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev wrote: > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even= if > so, a simple 1MB tx size limit would clearly do the trick. The broader > point is that quadratic hashing is not a compelling reason to keep > blockmaxsize post-HF: does someone have a better one? > > > > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" > wrote: >> >> That would invalidate any pre-signed transactions that are currently out >> there. You can't just change the rules out from under people. >> >> >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev >> wrote: >> >> >>> >>> The 1MB classic block size prevents quadratic hashing >>> problems from being any worse than they are today. >>> >> >> Add a transaction-size limit of, say, 10kb and the quadratic hashing >> problem is a non-issue. Donezo. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >