Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protocol clean up: version & transaction type #1011

Open
scravy opened this issue Apr 19, 2019 · 3 comments
Open

Protocol clean up: version & transaction type #1011

scravy opened this issue Apr 19, 2019 · 3 comments
Assignees
Labels
brainstorming Needs input, ideas are welcome
Milestone

Comments

@scravy
Copy link
Member

scravy commented Apr 19, 2019

#1004 changes the type which transaction type is encoded as from uint16_t to uint8_t, which gives a maximum of 256 possible transaction types. The structure we inherit from bitcoin supports uint32_t transaction versions.

I for one do not see the need to distinguish "version" and "type", as "regular transaction version 2" can as well be just the type "regular transaction version 2". Same with votes, etc. It also makes little sense to differentiate "type X of version Y" etc. (too granular). We can simply have types like "vote" and "new_vote" (should it ever come to this).

In the code we so far overloaded the uint32_t version field to mean both version: uint16_t and txtype: uint16_t. This was kind of a hack and does not clearly distinguish these fields. Which leads to strange effects given bitcoins little-endian serialization. For example we technically have a "dead byte" as #1004 was merged.

The proper clean up would be to clean up the protocol and have the implementation follow suite. My proposal is:

  • Re-label the existing version field as "txtype" (effectively drops notion of "version" in favor of "type")
  • Reduce it to "uint8_t" (as has been done more-or-less already)
  • In code: Drop GetVersion / SetVersion / etc.

Other benefits:
This frees 3 byte per transaction :-)

Forwards compatibility:
In case we need a higher range in the future we can use the then-last-remaining txtype and have the new type of transaction define a discriminator for additional versions, i.e. we can say "txtype 256 requires a tx layout which itself is versioned".

@scravy scravy added this to the 0.2 milestone Apr 19, 2019
@cmihai cmihai added the brainstorming Needs input, ideas are welcome label Apr 19, 2019
@dtr-org dtr-org deleted a comment from mergeable bot Apr 19, 2019
@dtr-org dtr-org deleted a comment from mergeable bot Apr 19, 2019
@cmihai
Copy link
Member

cmihai commented Apr 19, 2019

In case we need a higher range in the future we can use the then-last-remaining txtype and have the new type of transaction define a discriminator for additional versions, i.e. we can say "txtype 256 requires a tx layout which itself is versioned".

So basically, make TxType a varint?

@dtr-org dtr-org deleted a comment from mergeable bot Apr 19, 2019
@dtr-org dtr-org deleted a comment from mergeable bot Apr 19, 2019
@scravy
Copy link
Member Author

scravy commented Apr 19, 2019

So basically, make TxType a varint?

Basically.

@kostyantyn
Copy link
Member

I support dropping Version and use only types.
As an intermediate approach (if we find cases that Version is convenient to have), would suggest separating txtype and version. Instead of having one uint32_t field, have two: txtype(uint8_t) and version(uint16_t)

About:

For example we technically have a "dead byte" as #1004 was merged

I confirm that now we have unused 1 byte in nVersion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming Needs input, ideas are welcome
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants