Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EF2AC63 for ; Tue, 9 Feb 2016 21:54:05 +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 7CC71167 for ; Tue, 9 Feb 2016 21:54:04 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 127C55CDA0; Tue, 9 Feb 2016 21:54:02 +0000 (UTC) To: Anthony Towns , Bitcoin Dev References: <56B8EBF8.4050602@mattcorallo.com> <20160209090002.GB18324@sapphire.erisian.com.au> From: Matt Corallo X-Enigmail-Draft-Status: N1110 Message-ID: <56BA5FF9.6090905@mattcorallo.com> Date: Tue, 9 Feb 2016 21:54:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160209090002.GB18324@sapphire.erisian.com.au> 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 X-Mailman-Approved-At: Tue, 09 Feb 2016 21:56:08 +0000 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 21:54:05 -0000 Thanks for keeping on-topic, replying to the proposal, and being civil! Replies inline. On 02/09/16 09:00, Anthony Towns via bitcoin-dev wrote: > 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?)? It's intended to activate when we have clear and broad consensus around a hard proposal across the community. >> 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? The goal isnt really to get a "gain" here...its mostly to decrease the worst-case (4MB is pretty crazy) and keep the total size in-line with what the network could handle. Getting 1MB blocks through the network in under a second is already incredibly difficult...2MB is pretty scary and will take lots of work...3MB is over the bound of "yea, we can pretty for sure get that to work pretty well". >> 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? Hmmmmmm...you make a valid point. I was trying to avoid breaking old transactions, but didnt think too much about time-locked ones. Hmmmmmm...we could apply the limits to txn that dont have at least one "newer than the fork input", but I'm not sure I like that either. >> 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. There is a clear goal here of NOT using block-based limits and switching to transaction-based limits. By switching to transaction-based limits we avoid nasty issues with mining code either getting complicated or enforcing too-strict limits on individual transactions. >> 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?