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 B7AA6B5D for ; Fri, 20 Jan 2017 14:00:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 947A1137 for ; Fri, 20 Jan 2017 14:00:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out01.mykolab.com (Postfix) with ESMTPS id E53E2623F9 for ; Fri, 20 Jan 2017 15:00:51 +0100 (CET) From: Tom Zander To: Bitcoin Protocol Discussion Date: Fri, 20 Jan 2017 15:02:22 +0100 Message-ID: <3264264.qpyyi8nbyQ@strawberry> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 26 Jan 2017 09:32:44 +0000 Subject: [bitcoin-dev] Changing the transaction version number to be varint 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: Fri, 20 Jan 2017 14:00:56 -0000 Hi all, In the transaction today we have a version field which is always 4 bytes. The rest of the integer encoding in a transaction is variable-size because it saves on bytes. Specifically, in practice this means that almost all of the transaction have bytes 2, 3 & 4 set to zero[1]. The question that I was pondering is that when we accept a new version of transaction format (flextrans uses 4), what would the impact be of also changing the way that the version number is actually serialized to be var int. The benefit would be that each and every transaction looses 3 bytes. These can be used differently in v1 transactions and are not needed at all to be there for newer transaction formats. The secondairy benefit is that, at least for FlexTrans[2], 100% of all the integers in the transaction are following exactly the same encoding, the var-int encoding. There is currently no consensus rule that rejects transactions which lie about their version, so obviously this rule should not and can not be introduced retro-actively. It will be from a certain block-height. The way to do this is that from a certain block-height the current transaction format labels bytes 2, 3 & 4 to be unused. >From that same block height the interpretation of the first byte is as varint. Last, we add the rule from that block-height that only transactions that do not lie about their version number are valid. Which means version 1. Do people see any problems with this? This could be done as a soft fork. 1) It should be 100% because there is no transaction version defined that sets them to non-zero, but there is no consensus rule that rejects transactions that lie about their version number. 2) https://bitcoinclassic.com/devel/Flexible%20Transactions.html -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel