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 9E55CC14 for ; Tue, 8 Dec 2015 19:40:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1274C199 for ; Tue, 8 Dec 2015 19:40:37 +0000 (UTC) Received: by ioc74 with SMTP id 74so35246262ioc.2 for ; Tue, 08 Dec 2015 11:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x9y1b7namevgxLEhhA2qjjmCjrfIys36IxVrKioz8Uo=; b=zxWxgXnpKsivrSFTP/BV8gHuhUXxOohVCAavu5SkHT0tz6PhqvzmH54gzHO1amkP1J HTxp1w+f9vp/IUOIAZ93udXW3/ZebzsxO3pbeqRFV/AKxQEHmBEL7MDrveicSU14DP79 UbHLgRpNxakOtoLxZibZ1AvA91AeNzvxUJc9r8kEa6PDD/VOcBptocs/mV0qSnLqQ6RL VuvoQ0oVanJ1XQ5TWfaP9gMeBOOsgLU2UErg1djKgPm8qSDYBmRBZGeqUkxhIePhvEon ejtTCJU6GfWikmopAyw/KihzFF88nBFlaACWRrXt84nBmpbtvnk6CsADehzM9WW5/Jdg m1TQ== MIME-Version: 1.0 X-Received: by 10.107.3.163 with SMTP id e35mr1430689ioi.157.1449603636322; Tue, 08 Dec 2015 11:40:36 -0800 (PST) Sender: nbvfour@gmail.com Received: by 10.36.20.130 with HTTP; Tue, 8 Dec 2015 11:40:36 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Dec 2015 11:40:36 -0800 X-Google-Sender-Auth: 3fIrObdWMaJP-sP6z2VnDS3QTFI Message-ID: From: Chris Priest To: Vincent Truong Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [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 19:40:37 -0000 I proposed in my Wildcard Inputs BIP that the version field be split in two. The first 4 bytes are version number (which in practice is being used for script version), and the second 4 bits are used for transaction type. I don't think the BIP9 mechanism really applies to transactions. A block is essentially a collection of transactions, therefore voting on the block applies to the many parties who have transactions in the block. A transaction on the other hand only effects at most two parties (the sender and the receiver). In other words, block are "communal" data structures, transactions are individual data structures. Also, the nature of soft forks are that wallets can choose to implement a new feature or not. For instance, if no wallets implement RBF or SW, then those features effectively don't exist, regardless of how many nodes have upgraded to handle the feature. Any new transaction feature should get a new "type" number. A new transaction feature can't happen until the nodes support it. On 12/8/15, Vincent Truong via bitcoin-dev wrote: > 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? >