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 1DC50486 for ; Sat, 13 May 2017 04:24:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEDB212A for ; Sat, 13 May 2017 04:24:02 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id x71so27052021vkd.0 for ; Fri, 12 May 2017 21:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NAI0jPjgeoVsLRfWhYkl4E7G8yomnMhOPRP09DZUfJM=; b=WBDZ+cmLS9BzMf8OsmZzdSx0Ki7pyKpOqgQGWsFE088vlk1qUFBRFZTGGQhiSAAaWX Id0E+moduH7Z3yyL+1YiFpevg+bzLqunAPKKqZ4/iwMMlVnTxByetaKpQH+c1HoYaxeQ UyUEliZjRzzBJf9j7Dd1DnYeg0Lcn3PPA57dxWWloUDc0P/Cp0fItam3dodl1p+UhtYq c47BpA1moLbK4EApMf9t332uQT29QO2gPLteQmWTOsECN/knLBKR6FbrIMmJ+2X7VSeZ Wwnv0vuRVIL/rvefSJOOajlUtRtBQxUBDODzXm20dRoi3J6c9mYav/8JXmqR5q9Nmw/y PsLA== 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; bh=NAI0jPjgeoVsLRfWhYkl4E7G8yomnMhOPRP09DZUfJM=; b=byluiOcZ1jyuC35hibl1w5cTAhWN8bflcS3k7zGNO2W//AsD1MHtlg+PbFbLfGcTml ED01Xn6jkdTOjrzen/HUqiFpyDu35GA55frDoVKlxg+nDc+j11tY02TDjMEwl3cC+G7N RsTD3Ri9RhMap04hRIFLG4/0SyOvPF2fTcN2SVs0Ly7AIQn/Mt4ATANNXm0Bb9jd3BxG Imdz7+2m27XXY8j9Jea1ccb1MsbjY32U9hXKrqJ2tpd6Mttm3lX1A2zv7Y+L+HYv5Qoy kS0P7KKfcvAgXFE/23ZQeLeEngzsVa4V2rJOflBCvcFjjNaMCxcaVpg2zje5RXVyBYCR WTeA== X-Gm-Message-State: AODbwcBb/4ce2oiejlpXCMGkWVQDreqF0/YDH0DyXSfAWQjuarOk3l3r jAjfGn3FbUIDZykKpEvjPN8+kqn9jP+m X-Received: by 10.31.65.73 with SMTP id o70mr3635411vka.85.1494649441897; Fri, 12 May 2017 21:24:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.48 with HTTP; Fri, 12 May 2017 21:23:41 -0700 (PDT) In-Reply-To: <201705121922.57445.luke@dashjr.org> References: <201705121922.57445.luke@dashjr.org> From: "Russell O'Connor" Date: Sat, 13 May 2017 00:23:41 -0400 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="001a114db5fc0c65b2054f60314e" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees 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: Sat, 13 May 2017 04:24:04 -0000 --001a114db5fc0c65b2054f60314e Content-Type: text/plain; charset="UTF-8" I recall chatting about this idea recently and my conclusion was the same as Peter Todd's conclusion: this will just encourage miners to false signal readiness with undermines both BIP 9 and BIP 8. I felt that rather than using script system for this construction, it would be better to use the transaction version number instead by soft-forking in a rule that says when the most significant bits of a transaction version are 001 then the transaction can only be included in blocks whose lower 29 version bits are set at the same position as the lower 29 version bits set in the transaction version. That is to say, if we have block version blkVersion and transaction version txVersion, we soft fork in a rule that requires that (txVersion & 0xe0000000 != 0x020000000) || ((blkVersion & 0xe0000000 = 0x020000000) && (blkVersion & txVersion = txVersion)) While I think that making use of the transaction version number is superior to adding an opcode, because it doesn't interfere with caching of script validity and because it doesn't use any more transaction space by making use of the otherwise useless transaction version number, I still think it is a bad proposal. On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the > community > to put economic pressure on miners to deploy softforks without the extreme > of > a UASF. > > https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki > > Due to the potential for miners to maliciously block this softfork, it is > suggested that we deploy it using BIP 8 to ensure it eventually activates > even > if encountering hostility. > > This is intended to be an alternative to BIP 8 in the long term. > It is NOT intended to make BIP 148 obsolete, given the timeframes involved. > > An implementation is available (based on top of BIP 115's implementation): > > https://github.com/luke-jr/bitcoin/compare/cbah...luke- > jr:checkblockversion > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114db5fc0c65b2054f60314e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I recall chatting about this idea rece= ntly and my conclusion was the same as Peter Todd's conclusion: this wi= ll just encourage miners to false signal readiness with undermines both BIP= 9 and BIP 8.

I felt that rather than using script system for = this construction, it would be better to use the transaction version number= instead by soft-forking in a rule that says when the most significant bits= of a transaction version are 001 then the transaction can only be included= in blocks whose lower 29 version bits are set at the same position as the = lower 29 version bits set in the transaction version.

That is = to say, if we have block version blkVersion and transaction version txVersi= on, we soft fork in a rule that requires that

(txVersion &= 0xe0000000 !=3D 0x020000000) || ((blkVersion & 0xe0000000 =3D 0x020000= 000) && (blkVersion & txVersion =3D txVersion))

Wh= ile I think that making use of the transaction version number is superior t= o adding an opcode, because it doesn't interfere with caching of script= validity and because it doesn't use any more transaction space by maki= ng use of the otherwise useless transaction version number, I still think i= t is a bad proposal.

On Fri, May 12, 2017 at 3:22 PM, Luke Dashjr via bitcoin-dev <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org> w= rote:
I've written a new BIP draft fo= r OP_CHECKBLOCKVERSION to allow the community
to put economic pressure on miners to deploy softforks without the extreme = of
a UASF.

=C2=A0 =C2=A0 https://github.com/luke-= jr/bips/blob/bip-cbv/bip-cbv.mediawiki

Due to the potential for miners to maliciously block this softfork, it is suggested that we deploy it using BIP 8 to ensure it eventually activates e= ven
if encountering hostility.

This is intended to be an alternative to BIP 8 in the long term.
It is NOT intended to make BIP 148 obsolete, given the timeframes involved.=

An implementation is available (based on top of BIP 115's implementatio= n):

=C2=A0 =C2=A0https://gith= ub.com/luke-jr/bitcoin/compare/cbah...luke-jr:checkblockversion

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114db5fc0c65b2054f60314e--