From: Tom Zander <tomz@freedommail•ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Changing the transaction version number to be varint
Date: Fri, 20 Jan 2017 15:02:22 +0100 [thread overview]
Message-ID: <3264264.qpyyi8nbyQ@strawberry> (raw)
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
next reply other threads:[~2017-01-20 14:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-20 14:02 Tom Zander [this message]
2017-01-26 12:57 ` Johnson Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3264264.qpyyi8nbyQ@strawberry \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox