From 5a3105ecbd31ffe0474e5e7276dc685af25d0187 Mon Sep 17 00:00:00 2001
From: Andrew <44542704+Endermanch@users.noreply.github.com>
Date: Sun, 28 May 2023 14:22:39 +0300
Subject: [PATCH] Update README.md

---
 README.md | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index 450c578..569c995 100644
--- a/README.md
+++ b/README.md
@@ -68,15 +68,13 @@ Based on that calculation, we unpack the 114-bit Product Key into 4 ordered segm
 
 | Segment   | Capacity | Data                                      |
 |-----------|----------|-------------------------------------------|
-| Flag      | 1 bit    | Reserved, always set to `0x01`*           |
+| Upgrade   | 1 bit    | Upgrade version flag                      |
 | Serial    | 30 bits  | Raw Product Key (RPK)                     |
 | Hash      | 28 bits  | RPK hash                                  |
 | Signature | 55 bits  | Elliptic Curve signature for the RPK hash |
 
-For simplicity' sake, we'll combine `Flag` and `Serial` segments into a single segment called `Data`. By that logic we'll be able to extract the RPK by
-shifting `Data` right and pack it back by shifting bits left.
-
-*It's not fully known what that bit does, but all a priori valid product keys I've checked had it set to 1.
+For simplicity' sake, we'll combine `Upgrade` and `Serial` segments into a single segment called `Data`. By that logic we'll be able to extract the RPK by
+shifting `Data` right and pack it back by shifting bits left, because most a priori valid product keys I've checked had the Upgrade bit set to 1.
 
 ### Elliptic Curves