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 E2FA7720 for ; Sat, 13 May 2017 17:11:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F3A9B0 for ; Sat, 13 May 2017 17:11:48 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id x71so31174424vkd.0 for ; Sat, 13 May 2017 10:11:48 -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=vEGCnCXstDW9Wh6RS2hFfYS4gBoItGKOSIEQ0pM3dTo=; b=w6vmzLBg9F993amQ7+f6kcROgYHdqrEF8J0ak0bw4tH4nGXsJ3TE50Fh4p6t8n0VXF m+yRcNFyxlsjCsTPmzFPlR3232iiRTKRPh2+ckJHbhxiIzs1W00S3Nn1c0aUuQD/stBs hPQywi2jCYqvbUX3dLc7sqz6XBoSurO1Y4EDfJDKmoZnR2KGk/33Cot9yKXIH+Z0KpKR uAWOcah6FQmf3bJKO5pT1Y0pxQsb8MOGp0zDRWtswaHnPaHd+DZLtKqwJL0xty5YT+A8 gSGgRAdAimiwVTiabZBBII5K5Uk/4QW646wfNS4rxdNSBWwxs3YebiAQ0IJHF1MBCAzX +0pg== 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=vEGCnCXstDW9Wh6RS2hFfYS4gBoItGKOSIEQ0pM3dTo=; b=cyzUXFFDir9myPPAiJX4d4aVizaGYh6ZobjjJb91XZ8RH4J5IMzXrbSAUmcotf0znq QdQPygPjyDUJZVfkURutL4TolIMj7pI6OU0S0XYGBchqmtH7ng0sUen2jy9C4QFGXd/x EMIIP6kwCiISNTt4iaOWWawT9tuuIkzrV0CYKSm3KQdW3v7Srxq/J4l40JMOvRzjkkNf RR5o+cq5ov3pqX1Zpgwh0CCKnG/gxi0cLWf9wO38Mb7Ko2kK6sZR1BnGc+j9htKpATG3 zYRI1tXpc07O8mA42ZcwH+KrgPrb16nwXi2lR7g2ljz7PFy0tdWudUukEEZ+wTs3Fl8o +9HQ== X-Gm-Message-State: AODbwcANIVvkViFnkX2SL65rR2ic2XOaSb2OyB2eR/oOpU6Lvg7MC3oa mmUqx8gMuETqjRY1a/8m64T6K3Lbesu7H+9MBg== X-Received: by 10.31.102.131 with SMTP id a125mr4700923vkc.6.1494695507722; Sat, 13 May 2017 10:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.48 with HTTP; Sat, 13 May 2017 10:11:27 -0700 (PDT) In-Reply-To: <201705130526.59467.luke@dashjr.org> References: <201705121922.57445.luke@dashjr.org> <201705130526.59467.luke@dashjr.org> From: "Russell O'Connor" Date: Sat, 13 May 2017 13:11:27 -0400 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="001a114df358c91910054f6aea37" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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 17:11:50 -0000 --001a114df358c91910054f6aea37 Content-Type: text/plain; charset="UTF-8" On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr wrote: > Versionbits change/lose their meaning after the deployment timeout. For > this > reason, the timeout must be specified so the check is skipped when that > occurs. > To add a timeout a user can optionally bundle a pair of similar transactions. One with the transaction version bits set and a second with a locktime set. The effect is the same. Also, doing it the way you describe would fail to enforce that BIP9 is > actually in use for the block version; you could simply add that as an > additional condition, but it seems pretty hacky since you wouldn't be able > to > upgrade versionbits anymore... > My formal condition does include a check for the block version (I've corrected the constants below): (txVersion & 0xe0000000 != 0x200000000) || (*(blkVersion & 0xe0000000 = 0x200000000)* && (blkVersion & txVersion = txVersion)) Nothing here prevents upgrading versionbits AFAICT. Any txVersion that does not begin with 0b001 is unconditionally acceptable and available for further soft-forking. --001a114df358c91910054f6aea37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr <luke@dashjr.org> wrote:
=
Versionbits change/lose their meaning after the deployment timeout. = For this
reason, the timeout must be specified so the check is skipped when that
occurs.

To add a timeout a user can opt= ionally bundle a pair of similar transactions.=C2=A0 One with the transacti= on version bits set and a second with a locktime set.=C2=A0 The effect is t= he same.

Also, doing it the way you describe would fail to enforce that BIP9 is
actually in use for the block version; you could simply add that as an
additional condition, but it seems pretty hacky since you wouldn't be a= ble to
upgrade versionbits anymore...


My formal condition does include a check for= the block version (I've corrected the constants below):

(txVers= ion & 0xe0000000 !=3D 0x200000000) || ((blkVersion &=20 0xe0000000 =3D 0x200000000) && (blkVersion & txVersion =3D= =20 txVersion))

Nothing here prevents upgrading versionbits AFAICT= .=C2=A0 Any txVersion that does not begin with 0b001 is unconditionally acc= eptable and available for further soft-forking.

--001a114df358c91910054f6aea37--