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 E33EBAD0 for ; Tue, 8 Dec 2015 12:27:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ED5AAF for ; Tue, 8 Dec 2015 12:27:28 +0000 (UTC) Received: by igl9 with SMTP id 9so94879486igl.0 for ; Tue, 08 Dec 2015 04:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=procabiak.com; s=procabiakindustries; h=mime-version:date:message-id:subject:from:to:content-type; bh=7EICnuQaQHclPR7o8qxbEllA4fwrlyPdL7Ezj3f5I0U=; b=ZFhFxYIQEs4BdMhJ2NqTRzOZVfJHxpik7c9m6EcZaWTZY+cRtX/8FCCBMrwnLTfK1H mRXCChwdDmQMQ3DbskALERbq/5nr/3XhMZuZZp7inox9ukcidW8uARFS/AivkEpwOCsw hG91SMfxTorFZRxS5zXnniTCpw8got0TBH52o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=7EICnuQaQHclPR7o8qxbEllA4fwrlyPdL7Ezj3f5I0U=; b=CxKygPww65CN1oej5jwPUG43R6PfG6X3xbAqMY0EBC9Veo1QKGly+ffMDNPHDmoPTs pEhEcYvr94XdQJlHHLIoFITQbgxSb5m+GK7VwUCN/OEtm7wcMjpp2H1fQUvhS11hBeYQ 1n//+70nGkic0yJEJG2BbT6fSXPVt3uLmHSFos5oyPd5Juou84A1a2z0+r8eSuRRdjb7 hrbnvr9N1P0z5z5Sjk+YvVNyZarop7ACCBFNqKtkDKIACb+3kdpsed7KURioJa8vEK3K kRlapLflJmgkk3lNVrlrMahAroxcm7vSHjp5nAt78ndTcgcT7BhkhRGOdfcfb050qy8o ZDyA== X-Gm-Message-State: ALoCoQmGNW8HKBP1b0WofFOTwUftyd1YltmlIPwE6+e3nPthplqVJCocrmS8AjU22LnIYs5aOnz4/oai62oe9o1Tm9rVORv1ZQ== MIME-Version: 1.0 X-Received: by 10.50.33.20 with SMTP id n20mr21461231igi.17.1449577647618; Tue, 08 Dec 2015 04:27:27 -0800 (PST) Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 04:27:27 -0800 (PST) X-Originating-IP: [14.202.127.219] Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 04:27:27 -0800 (PST) Date: Tue, 8 Dec 2015 23:27:27 +1100 Message-ID: From: Vincent Truong To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e01537a54c2d46d0526621803 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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: Tue, 08 Dec 2015 14:27:20 +0000 Subject: [bitcoin-dev] BIP 9 style version bits for txns 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, 08 Dec 2015 12:27:29 -0000 --089e01537a54c2d46d0526621803 Content-Type: text/plain; charset=UTF-8 So I have been told more than once that the version announcement in blocks is not a vote, but a signal for readiness, used in isSupermajority(). Basically, if soft forks (and hard forks) won't activate unless a certain % of blocks have been flagged with the version up (or bit flipped when versionbits go live) to signal their readiness, that is a vote against implementation if they never follow up. I don't like this politically correct speech because in reality it is a vote... But I'm not here to argue about that... I would like to see if there are any thoughts on extending/copying isSupermajority() for a new secondary/non-critical function to also look for a similar BIP 9 style version bit in txns. Apologies if already proposed, haven't heard of it anywhere. If we are looking for a signal of readiness, it is unfair to wallet developers and exchanges that they are unable to signal if they too are ready for a change. As more users are going into use SPV or SPV-like wallets, when a change occurs that makes them incompatible/in need of upgrade we need to make sure they aren't going to break or introduce security flaws for users. If a majority of transactions have been sent are flagged ready, we know that they're also good to go. Would you implement the same versionbits for txn's version field, using 3 bits for versioning and 29 bits for flags? This indexing of every txn might sound insane and computationally expensive for bitcoin Core to run, but if it isn't critical to upgrade with soft forks, then it can be watched outside the network by enthusiasts. I believe this is the most politically correct way to get wallet devs and exchanges involved. (If it were me I would absolutely try figure out a way to stick it in isSupermajority...) Miners can watch for readiness flagged by wallets before they themselves flag ready. We will have to trust miners to not jump the gun, but that's the trade off. Thoughts? --089e01537a54c2d46d0526621803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So I have been told more than once that the version announce= ment in blocks is not a vote, but a signal for readiness, used in isSuperma= jority(). Basically, if soft forks (and hard forks) won't activate unle= ss a certain % of blocks have been flagged with the version up (or bit flip= ped when versionbits go live) to signal their readiness, that is a vote aga= inst implementation if they never follow up. I don't like this politica= lly correct speech because in reality it is a vote... But I'm not here = to argue about that... I would like to see if there are any thoughts on ext= ending/copying isSupermajority() for a new secondary/non-critical function = to also look for a similar BIP 9 style version bit in txns. Apologies if al= ready proposed, haven't heard of it anywhere.

If we are looking for a signal of readiness, it is unfair to= wallet developers and exchanges that they are unable to signal if they too= are ready for a change. As more users are going into use SPV or SPV-like w= allets, when a change occurs that makes them incompatible/in need of upgrad= e we need to make sure they aren't going to break or introduce security= flaws for users.

If a majority of transactions have been sent are flagged rea= dy, we know that they're also good to go.

Would you implement the same versionbits for txn's versi= on field, using 3 bits for versioning and 29 bits for flags? This indexing = of every txn might sound insane and computationally expensive for bitcoin C= ore to run, but if it isn't critical to upgrade with soft forks, then i= t can be watched outside the network by enthusiasts. I believe this is the = most politically correct way to get wallet devs and exchanges involved. (If= it were me I would absolutely try figure out a way to stick it in isSuperm= ajority...)

Miners can watch for readiness flagged by wallets before the= y themselves flag ready. We will have to trust miners to not jump the gun, = but that's the trade off.

Thoughts?

--089e01537a54c2d46d0526621803--