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 C9DD6EF7 for ; Tue, 9 Feb 2016 09:00:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 382D3156 for ; Tue, 9 Feb 2016 09:00:08 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1aT49V-0007ai-KV for ; Tue, 09 Feb 2016 19:00:07 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 09 Feb 2016 19:00:02 +1000 Date: Tue, 9 Feb 2016 19:00:02 +1000 From: Anthony Towns To: Bitcoin Dev Message-ID: <20160209090002.GB18324@sapphire.erisian.com.au> References: <56B8EBF8.4050602@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B8EBF8.4050602@mattcorallo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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] On Hardforks in the Context of SegWit 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: Tue, 09 Feb 2016 09:00:08 -0000 On Mon, Feb 08, 2016 at 07:26:48PM +0000, Matt Corallo via bitcoin-dev wrote: > As what a hard fork should look like in the context of segwit has never > (!) been discussed in any serious sense, I'd like to kick off such a > discussion with a (somewhat) specific proposal. > Here is a proposed outline (to activate only after SegWit and with the > currently-proposed version of SegWit): Is this intended to be activated soon (this year?) or a while away (2017, 2018?)? > 1) The segregated witness discount is changed from 75% to 50%. The block > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a > maximum block size of 3MB and a "network-upgraded" block size of roughly > 2.1MB. This still significantly discounts script data which is kept out > of the UTXO set, while keeping the maximum-sized block limited. This would mean the limits go from: pre-segwit segwit pkh segwit 2/2 msig worst case 1MB - - 1MB 1MB 1.7MB 2MB 4MB 1.5MB 2.1MB 2.2MB 3MB That seems like a fairly small gain (20% for pubkeyhash, which would last for about 3 months if you're growth rate means doubling every 9 months), so this probably makes the most sense as a "quick cleanup" change, that also safely demonstrates how easy/difficult doing a hard fork is in practice? On the other hand, if segwit wallet deployment takes longer than hoped, the 50% increase for pre-segwit transactions might be a useful release-valve. Doing a "2x" hardfork with the same reduction to a 50% segwit discount would (I think) look like: pre-segwit segwit pkh segwit 2/2 msig worst case 1MB - - 1MB 1MB 1.7MB 2MB 4MB 2MB 2.8MB 2.9MB 4MB which seems somewhat more appealing, without making the worst-case any worse; but I guess there's concern about the relay networking scaling above around 2MB per block, at least prior to IBLT/weak-blocks/whatever? > 2) In order to prevent significant blowups in the cost to validate > [...] and transactions are only allowed to contain > up to 20 non-segwit inputs. [...] This could potentially make old, signed, but time-locked transactions invalid. Is that a good idea? > Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from > 1-per-50-bytes across the entire block to a per-transaction limit which > is slightly looser (though not too much looser - even with libsecp256k1 > 1-per-50-bytes represents 2 seconds of single-threaded validation in > just sigops on my high-end workstation). I think turning MAX_BLOCK_SIGOPS and MAX_BLOCK_SIZE into a combined limit would be a good addition, ie: #define MAX_BLOCK_SIZE 1500000 #define MAX_BLOCK_DATA_SIZE 3000000 #define MAX_BLOCK_SIGOPS 50000 #define MAX_COST 3000000 #define SIGOP_COST (MAX_COST / MAX_BLOCK_SIGOPS) #define BLOCK_COST (MAX_COST / MAX_BLOCK_SIZE) #define DATA_COST (MAX_COST / MAX_BLOCK_DATA_SIZE) if (utxo_data * BLOCK_COST + bytes * DATA_COST + sigops * SIGOP_COST > MAX_COST) { block_is_invalid(); } Though I think you'd need to bump up the worst-case limits somewhat to make that work cleanly. > 4) Instead of requiring the first four bytes of the previous block hash > field be 0s, we allow them to contain any value. This allows Bitcoin > mining hardware to reduce the required logic, making it easier to > produce competitive hardware [1]. > [1] Simpler here may not be entirely true. There is potential for > optimization if you brute force the SHA256 midstate, but if nothing > else, this will prevent there being a strong incentive to use the > version field as nonce space. This may need more investigation, as we > may wish to just set the minimum difficulty higher so that we can add > more than 4 nonce-bytes. Could you just use leading non-zero bytes of the prevhash as additional nonce? So to work out the actual prev hash, set leading bytes to zero until you hit a zero. Conversely, to add nonce info to a hash, if there are N leading zero bytes, fill up the first N-1 (or less) of them with non-zero values. That would give a little more than 255**(N-1) possible values ((255**N-1)/254) to be exact). That would actually scale automatically with difficulty, and seems easy enough to make use of in an ASIC? Cheers, aj