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 1543D978 for ; Thu, 26 Jan 2017 12:57:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D819135 for ; Thu, 26 Jan 2017 12:57:55 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1485435458265499.1695979901465; Thu, 26 Jan 2017 04:57:38 -0800 (PST) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 20:57:32 +0800 References: <3264264.qpyyi8nbyQ@strawberry> To: Tom Zander , bitcoin-dev In-Reply-To: <3264264.qpyyi8nbyQ@strawberry> Message-Id: X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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: Thu, 26 Jan 2017 12:57:56 -0000 > On 20 Jan 2017, at 22:02, Tom Zander via bitcoin-dev = wrote: >=20 > The way to do this is that from a certain block-height the current=20 > transaction format labels bytes 2, 3 & 4 to be unused. > =46rom that same block height the interpretation of the first byte is = as=20 > varint. > Last, we add the rule from that block-height that only transactions = that do=20 > not lie about their version number are valid. Which means version 1. >=20 > Do people see any problems with this? > This could be done as a soft fork. Yes, because: a) what you are talking is a hardfork, because existing nodes will not = be able to deserialise the transaction. They will forever interpret the = first 4 bytes as nVersion. b) it is not a =E2=80=9Clie=E2=80=9D to use non-version 1 txs. It is = permitted since v0.1. And version 2 txs is already used due to BIP68. c) if you are talking about changing the tx serialisation just for = network transfer, it=E2=80=99s just a p2p protocol upgrade, not softfork = nor hardfork ------------------------- There are 3 ways to introduce new tx formats: 1. through a softfork, and make the old clients blind to the new format. = That=E2=80=99s the segwit approach 2. through a hardfork. Forget the old clients and require new clients to = understand the new format. That=E2=80=99s the FlexTran approach (in my = understanding) 3. p2p only, which won=E2=80=99t affect consensus. No one could stop you = if you try to copy a block by writing in your native language and pass = to your peer. In either way, one could introduce whatever new format one wants.=