UIP-0027 - Independent service fields for transaction

[dsaveliev]

The given UIP-0027 describes the way to reimplement type and version transaction fields with a little pain.

Related to:
dtr-org/unit-e#1011
dtr-org/unit-e#1062

Signed-off-by: Dmitry Saveliev [email protected]

[frolosofsky]

In both Rationale and Motivation parts, I did not find a description of a real problem we're trying to solve. The essential proposed change is literally to shrink version from 16 bits to 8 bits that leads to having two dead bytes instead of one.

Personally, I'd rather replace nVersion (4 bytes) with two fields: version and txtype (each 1 byte). As for bitcoin tests which relies on "real" transactions, I think we can get rid of them in favor of new tests for unit-e transactions. Having this compatibility with bitcoin limits us in further transactions manipulations.

If we say that it's too hard to achieve and maintain (which is understandable), then I don't see a point in this UIP. We can pinch unused byte of nVersion anytime we need, as we already did it in UIP-18.

[Gnappuraz]

I don't wanna belittle the proposal, but it honestly does not seem to justify the amount of changes probably required. I understand that cleaning it up is nice, but until we actually need those extra bytes I don't see a big problem with the bit-masking we have right now.

[dsaveliev]

Well, if you'll take a look at dtr-org/unit-e#1062, you'll see my opinion. @scravy WDYT?

[scravy]

Transaction Type was already changed from 16 to 8 bits in dtr-org/unit-e#1004. It did not come with a UIP or anything, and introduced a dead byte which lead to the creation of dtr-org/unit-e#1011

I for one would drop version entirely, as expressed in that ticket, but #1062 shows that that's a lot of changes which make it harder to upstream sync. The suggested solution was to clean it up in the sense that there would be four explicit fields of which 2 are reserved for future changes, which I for one think is a good compromise.