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 06AA25B1 for ; Mon, 15 May 2017 01:15:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A49607C for ; Mon, 15 May 2017 01:15:49 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 3wR2hM0Xpgz9s8J; Mon, 15 May 2017 11:15:46 +1000 (AEST) From: Rusty Russell To: Russell O'Connor , Luke Dashjr In-Reply-To: References: <201705121922.57445.luke@dashjr.org> <201705130526.59467.luke@dashjr.org> Date: Mon, 15 May 2017 10:44:13 +0930 Message-ID: <87tw4mly56.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD 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: Mon, 15 May 2017 01:15:51 -0000 Russell O'Connor via bitcoin-dev writes: > 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. I have a similar proposal to Russell; use tx nVersion. However, my subset is simpler, and uses fewer precious nVersion bits: 1. Top version 26 bits must be 1 (say) 2. Next bit indicates positive (must have bit set) or negative (must NOT have bit set). 3. Bottom 5 bits refer to which BIP8/9 bit we're talking about. This only allows specifying a single bit, and only support BIP8/9-style signalling. I believe we can skip the timeout: miners don't signal 100% either way anyway. If a BIP is in LOCKIN, wallets shouldn't set positive on that bit (this gives them two weeks). Similarly, if a BIP is close to FAILED, don't set positive on your tx. Wallets shouldn't signal until any bit until see some minimal chance it's accepted (eg. 1 in 20 blocks). > 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. This is gentler on miners than a UASF flag day, and does offer some harder-to-game signalling from bitcoin users. False signalling miners still have the 2 week LOCKIN period to upgrade, otherwise they can already lose money. You could argue they're *more* likely to upgrade with a signal that significant parts of the economy have done so. Cheers, Rusty.