[bitcoin-dev] Changing the transaction version number to be varint

[bitcoin-dev] Changing the transaction version number to be varint

[Tom Zander]

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

Re: [bitcoin-dev] Changing the transaction version number to be varint

[Johnson Lau]

> On 20 Jan 2017, at 22:02, Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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.

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 “lie” 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’s 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’s the segwit approach

2. through a hardfork. Forget the old clients and require new clients to understand the new format. That’s the FlexTran approach (in my understanding)

3. p2p only, which won’t 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.