From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YiWxv-00041L-OF for bitcoin-development@lists.sourceforge.net; Wed, 15 Apr 2015 23:43:35 +0000 Received-SPF: neutral (sog-mx-2.v43.ch3.sourceforge.com: 162.222.225.17 is neither permitted nor denied by domain of sky-ip.org) client-ip=162.222.225.17; envelope-from=s7r@sky-ip.org; helo=outbound.mailhostbox.com; Received: from outbound.mailhostbox.com ([162.222.225.17]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YiWxg-00010k-KH for bitcoin-development@lists.sourceforge.net; Wed, 15 Apr 2015 23:43:31 +0000 Received: from [0.0.0.0] (67.ip-92-222-38.eu [92.222.38.67]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id EEFE4781301 for ; Wed, 15 Apr 2015 23:43:03 +0000 (GMT) Message-ID: <552EF785.7000207@sky-ip.org> Date: Thu, 16 Apr 2015 02:43:01 +0300 From: s7r User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bitcoin-development Content-Type: text/plain; charset=utf-8 X-CTCH-RefID: str=0001.0A020204.552EF789.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: s7r@sky-ip.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Headers-End: 1YiWxg-00010k-KH Subject: [Bitcoin-development] 75%/95% threshold for transaction versions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: s7r@sky-ip.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 23:43:35 -0000 Hi, Would it be wise to add a consensus rule like the one we have for blocks, (if > 75% from last 1000 blocks are version 'n' mark version 'n' as standard for blocks and if > 95% from the last 1000 blocks are version 'n' mark previous block versions as invalid) but for transaction versions? In simple terms, if > 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if > 95% from all the transactions in the latest 1000 blocks are version 'n' mark all previous transaction versions as invalid. At this moment, the standard in consensus is v1, but nothing is enforced in the network related to transaction versions. Regarding BIP62, as it can be read here [0] it is said that it requires v2 transactions. It is also said that transaction version 2 will be skipped and jump directly to v3, for an even version for transactions and blocks (?). Might as well add the rule for invalidating previous transaction versions if the majority updates - could this break anything or affect functionality in any way? BIP62 adds a newer transaction version which is optional and does not mark previous v1 as non-standard or invalid. This means bitcoin core will treat both v1 and v2/v3 transactions as standard and relay/mine them with the same priority, regardless of the tx version? Thanks. [0] https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-deal= ing-with-malleability-has-been-implemented