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 A559CE29 for ; Mon, 8 Feb 2016 22:24:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B6614138 for ; Mon, 8 Feb 2016 22:24:03 +0000 (UTC) Received: from homiemail-a4.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id 4E911918F6 for ; Mon, 8 Feb 2016 14:24:03 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 6B4F651C07B; Mon, 8 Feb 2016 14:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=Ci8mn11gAq+8yl5Sn +k9IsVCbaM=; b=LnMNS5gSI4aHtASa4au5HS2peUslLtnJHyb7dVjtBvefi6YoZ NGQXiB6uZRrPnBTZM3DKQILmD7z7beaB5WvDS24qa5CE5Of4Prog+qPVfJ4UZBHO CjRZqVHyElh0Xt8uMpnzGhYvzLmd5Pq54dNKBqOXSWOCxtvSraMdm9H6wM= Received: from [192.168.42.65] (50-0-163-57.dsl.dynamic.fusionbroadband.com [50.0.163.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 1BC8751C073; Mon, 8 Feb 2016 14:24:02 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9FB789D8-0CD4-43E8-8ABC-0E310E381D4A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Tao Effect In-Reply-To: <236601d162b0$8da286e0$a8e794a0$@xbt.hk> Date: Mon, 8 Feb 2016 14:24:01 -0800 X-Mao-Original-Outgoing-Id: 476663040.895384-98ae27bc6838e41c39ac20d46ddf7b7e Message-Id: <28C17F9B-AD69-4962-8C8F-0D983FA917ED@taoeffect.com> References: <56B8EBF8.4050602@mattcorallo.com> <236601d162b0$8da286e0$a8e794a0$@xbt.hk> To: jl2012@xbt.hk X-Mailer: Apple Mail (2.3112) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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: Mon, 08 Feb 2016 23:29:24 +0000 Cc: bitcoin-dev@lists.linuxfoundation.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: Mon, 08 Feb 2016 22:24:04 -0000 --Apple-Mail=_9FB789D8-0CD4-43E8-8ABC-0E310E381D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hard forks should always come in response to some major crisis that all = participants can agree is an actual crisis, as per the excellent = rational here: = http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to= -discuss/ And here: http://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/ Also, if you=E2=80=99re going to do a hard fork, you=E2=80=99d better = make the most of it as hard forks must be a *rare* = world-is-ending-if-we-don=E2=80=99t-do-it thing (otherwise Bitcoin = cannot be considered decentralized in any sense of the word). So for any sort of hard fork, be sure to address the real threats and = challenges that are facing Bitcoin today: 1. Mining centralization. 2. Privacy. Best regards, Greg Slepak > On Feb 8, 2016, at 12:37 PM, jl2012--- via bitcoin-dev = wrote: >=20 > Thanks for this proposal. Just some quick response: >=20 > 1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit > softfork). BIP141 doesn't need grace period. BIP HF will have around 1 = year > of grace period. >=20 > 2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) = BIP 141 > if BIP HF has already got 95%; d) BIP HF if BIP141 has already got = 95%. > Voting a and c (or b and d) at the same time is invalid. BIP 141 is > activated if a>95% or (a+c>95% and b+d>95%). BIP HF is activated if = b>95% or > (a+c>95% and b+d>95%). >=20 > 3. Fix time warp attack: this may break some SPV implementation >=20 > 4. Limiting non-segwit inputs may make some existing signed tx = invalid. My > proposal is: a) count the number of non-segwit sigop in a tx, = including > those in unexecuted branch (sigop); b) measure the tx size without = scripgSig > (size); c) a new rule is SUM(sigop*size) < some_value . This allows > calculation without actually running the script. >=20 >=20 > -----Original Message----- > From: bitcoin-dev-bounces@lists.linuxfoundation.org > [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of = Matt > Corallo via bitcoin-dev > Sent: Tuesday, 9 February, 2016 03:27 > To: Bitcoin Dev > Subject: [bitcoin-dev] On Hardforks in the Context of SegWit >=20 > Hi all, >=20 > I believe we, today, have a unique opportunity to begin to close the = book on > the short-term scaling debate. >=20 > First a little background. The scaling debate that has been gripping = the > Bitcoin community for the past half year has taken an interesting turn = in > 2016. Until recently, there have been two distinct camps - one = proposing a > significant change to the consensus-enforced block size limit to allow = for > more on-blockchain transactions and the other opposing such a change, > suggesting instead that scaling be obtained by adding more flexible = systems > on top of the blockchain. At this point, however, the entire Bitcoin > community seems to have unified around a single vision - roughly 2MB = of > transactions per block, whether via Segregated Witness or via a hard = fork, > is something that can be both technically supported and which adds = more > headroom before second-layer technologies must be in place. = Additionally, it > seems that the vast majority of the community agrees that segregated = witness > should be implemented in the near future and that hard forks will be a > necessity at some point, and I don't believe it should be = controversial > that, as we have never done a hard fork before, gaining experience by > working towards a hard fork now is a good idea. >=20 > With the apparent agreement in the community, it is incredibly = disheartening > that there is still so much strife, creating a toxic environment in = which > developers are not able to work, companies are worried about their = future > ability to easily move Bitcoins, and investors are losing confidence. = The > way I see it, this broad unification of visions across all parts of = the > community places the burden of selecting the most technically-sound = way to > achieve that vision squarely on the development community. >=20 > Sadly, the strife is furthered by the huge risks involved in a hard = fork in > the presence of strife, creating a toxic cycle which prevents a safe = hard > fork. While there has been talk of doing an "emergency hardfork" as an > option, and while I do believe this is possible, it is not something = that > will be easy, especially for something as controversial as rising = fees. > Given that we have never done a hard fork before, being very careful = and > deliberate in doing so is critical, and the technical community = working > together to plan for all of the things that might go wrong is key to = not > destroying significant value. >=20 > As such, I'd like to ask everyone involved to take this opportunity to > "reset", forgive past aggressions, and return the technical debates to > technical forums (ie here, IRC, etc). >=20 > 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. >=20 > First some design notes: > * I think a key design feature should be taking this opportunity to = add > small increases in decentralization pressure, where possible. > * Due to the several non-linear validation time issues in transaction > validation which are fixed by SegWit's signature-hashing changes, I = strongly > believe any hard fork proposal which changes the block size should = rely on > SegWit's existence. > * As with any hard fork proposal, its easy to end up pulling in = hundreds of > small fixes for any number of protocol annoyances. In order to avoid = doing > this, we should try hard to stick with a few simple changes. >=20 > Here is a proposed outline (to activate only after SegWit and with the > currently-proposed version of SegWit): >=20 > 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. >=20 > 2) In order to prevent significant blowups in the cost to validate > pessimistic blocks, we must place additional limits on the size of = many > non-segwit transactions. scriptPubKeys are now limited to 100 bytes in = size > and may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie = no > non-push opcodes), and transactions are only allowed to contain up to = 20 > non-segwit inputs. Together these limits limit total-bytes-hashed in = block > validation to under 200MB without any possibility of making existing = outputs > unspendable and without adding additional per-block limits which make > transaction-selection-for-mining difficult in the face of attacks or > non-standard transactions. Though 200MB of hashing (roughly 2 seconds = of > hash-time on my high-end > workstation) is pretty strongly centralizing, limiting transactions to = fewer > than 20 inputs seems arbitrarily low. >=20 > 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). >=20 > 3) Move SegWit's generic commitments from an OP_RETURN output to a = second > branch in the merkle tree. Depending on the timeline this may be = something > to skip - once there is tooling for dealing with the extra OP_RETURN = output > as a generic commitment, the small efficiency gain for applications = checking > the witness of only one transaction or checking a non-segwit = commitment may > not be worth it. >=20 > 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]. >=20 > I'll deliberately leave discussion of activation method out of this > proposal. Both jl2012 and Luke-Jr recently begun some discussions = about > methods for activation on this list, and I'd love to see those = continue. > If folks think a hard fork should go ahead without SPV clients having = a say, > we could table #4, or activate #4 a year or two after 1-3 activate. >=20 >=20 > [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. >=20 >=20 >=20 >=20 > Obviously we cannot reasonably move forward with a hard fork as long = as the > contention in the community continues. Still, I'm confident continuing = to > work towards SegWit as a 2MB-ish soft-fork in the short term with some = plans > on what a hard fork should look like if we can form broad consensus = can go a > long way to resolving much of the contention we've seen. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_9FB789D8-0CD4-43E8-8ABC-0E310E381D4A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJWuRWAAAoJEOxnICvpCVJHz3MQAJXqmaaO/k8vHJiZL5NQaVXw dX/LrT5ThGWbz1lhLvLaem0CDFTveoJvelqVXWIye3rEmiqQP+BRhXHfLDOznozZ rNyTuJ6QEY/TMXRxGAlP0Bxri4kGthzfDAj7O0AexV4dnTU6FUy3UK4MD7ZVJcVi TjxQ5/431uWK9IWFu8SvthgP3a82YBW49hb//FAB1uGVvx8x0o3tSy8VXzudNeAp vgDoD6i4QId5gHZNTEivxo37HKP8M1TmnmRQlLzE1AxhpwBWVRoTsHrrDlDcZ8lq eZ3fN+Ook4bL2njSjndjc4kZjZpBVLoG9+nPRSIn+sTiH9TG8qczd0YhbYhzHNi3 P79pfC/Dg9Fcru0URabnjUo7PhlsV7NKb3pzDlRZJXT11cwcRfmu9fFCFL0hrSre 9hbkfrhj6FZmezOCpRwXvL+imba3dApPCOm7tMgvf7XkCSSuIEQ2tLSmdw+W0bsI mx7NCJnHqkgYgjNs/sbDAJLcyyH40ByaonYRc3ziyv+56xjSMX1WjwdXl73Dbnfg 6L4joX5ryp2ma9dbL1ipiMzhQ8QsNB3gz0rc2drNs99s5nox1EIaQYoWJ3g5WEQl zRhYHP6lA2oEzlxVVtFmJdGk7lRRKlrlNAlCDeBd0YaxWMTJJMmM42XGGvzMcw4A Aw1eYFL9CkM9falAtQR2 =gFms -----END PGP SIGNATURE----- --Apple-Mail=_9FB789D8-0CD4-43E8-8ABC-0E310E381D4A--