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 EA4F214E6 for ; Wed, 16 Sep 2015 21:52:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 89B101F0 for ; Wed, 16 Sep 2015 21:52:56 +0000 (UTC) Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id CE9F1583EF; Wed, 16 Sep 2015 21:52:47 +0000 (UTC) To: Jeff Garzik , Bitcoin development mailing list References: From: Matt Corallo X-Enigmail-Draft-Status: N1110 Message-ID: <55F9E47D.50507@mattcorallo.com> Date: Wed, 16 Sep 2015 21:51:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] Scaling Bitcoin conference micro-report 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 Sep 2015 21:52:57 -0000 I only have one "correction", included inline. On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote: > > During Scaling Bitcoin, Bitcoin Core committers and notable contributors > got together and chatted about where a "greatest common denominator" > type consensus might be. The following is a without-attribution > (Chatham House) summary. This is my own personal summary of the chat; > any errors are my own; this is _not_ a consensus statement or anything > formal. > > - Background (pre-conference, was on public IRC): "net-utxo", > calculating transaction size within block by applying a delta to > transaction size based on the amount of data added, or removed, from the > UTXO set. Fee is then evaluated after the delta is applied. This > aligns user incentives with UTXO resource usage/cost. Original idea by > gmaxwell (and others??). > > - Many interested or at least willing to accept a "short term bump", a > hard fork to modify block size limit regime to be cost-based via > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > were debated and seemed "in range" with what might work as a short term > bump - net after applying the new cost metric. I would be careful to point out that hard numbers were deliberately NOT discussed. Though some general things were thrown out, they were not extensively discussed nor agreed to. I personally think 2-4 is "in range", though 8 maybe not so much. Of course it depends on exactly how the non-blocksize limit accounting/adjusting is done. Still, the "greatest common denominator" agreement did not seem to be agreeing to an increase which continues over time, but which instead limits itself to a set, smooth increase for X time and then requires a second hardfork if there is agreement on a need for more blocksize at that point. > - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard > fork Y months in the future. Set high bit in version, resulting in a > negative number, to more cleanly fork away. "miner advisement" - > miners, as they've done recently, signal non-binding (Bitcoin Core does > not examine the value) engineering readiness for a hard fork via > coinbase moniker. Some fork cancellation method is useful, if > unsuccessful after Z time elapses. > > - As discussed publicly elsewhere, other forks may be signaled via > setting a bit in version, and then triggering a fork'ing change once a > threshold is reached. > > Chat participants are invited to reply to this message with their own > corrections and comments and summary in their view. > > For the wider community, take this as one of many "inputs" described at > Scaling Bitcoin. Over the next few months developers and the community > should evaluate everything discussed and work towards some concrete > proposal(s) that are implemented, tested and simulated in December in > Hong Kong.