-
Notifications
You must be signed in to change notification settings - Fork 992
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
Header version cleanup #2809
Header version cleanup #2809
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -239,9 +239,19 @@ impl Default for ProofOfWork { | |
} | ||
} | ||
|
||
impl ProofOfWork { | ||
/// Read implementation, can't define as trait impl as we need a version | ||
pub fn read(_ver: u16, reader: &mut dyn Reader) -> Result<ProofOfWork, ser::Error> { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think you can do this. You're going to be adding that version back for our scheduled hard fork, aren't you? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think the check is going to happen here during deserialization. We have I think we originally had this passed in here when we first introduced the AR/AT dual PoW impl or when we opened up the C31+ flexibility. That said - this change was one of the things I wanted to discuss via this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know much about the format of our PoW, but I assumed the hardfork would change how we have to serialize/deserialize ProofOfWork. If that's not true, then I agree with your change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd leaning toward simplifying and standardizing how we There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ideally the PoW change wouldn't change its format, but just details about graph construction or cycle finding. Not sure we'll be able to keep it that way every time but still a good goal to start with. |
||
impl Writeable for ProofOfWork { | ||
fn write<W: Writer>(&self, writer: &mut W) -> Result<(), ser::Error> { | ||
if writer.serialization_mode() != ser::SerializationMode::Hash { | ||
self.write_pre_pow(writer)?; | ||
writer.write_u64(self.nonce)?; | ||
} | ||
self.proof.write(writer)?; | ||
Ok(()) | ||
} | ||
} | ||
|
||
impl Readable for ProofOfWork { | ||
fn read(reader: &mut dyn Reader) -> Result<ProofOfWork, ser::Error> { | ||
let total_difficulty = Difficulty::read(reader)?; | ||
let secondary_scaling = reader.read_u32()?; | ||
let nonce = reader.read_u64()?; | ||
|
@@ -253,20 +263,11 @@ impl ProofOfWork { | |
proof, | ||
}) | ||
} | ||
} | ||
|
||
/// Write implementation, can't define as trait impl as we need a version | ||
pub fn write<W: Writer>(&self, ver: u16, writer: &mut W) -> Result<(), ser::Error> { | ||
if writer.serialization_mode() != ser::SerializationMode::Hash { | ||
self.write_pre_pow(ver, writer)?; | ||
writer.write_u64(self.nonce)?; | ||
} | ||
|
||
self.proof.write(writer)?; | ||
Ok(()) | ||
} | ||
|
||
impl ProofOfWork { | ||
/// Write the pre-hash portion of the header | ||
pub fn write_pre_pow<W: Writer>(&self, _ver: u16, writer: &mut W) -> Result<(), ser::Error> { | ||
pub fn write_pre_pow<W: Writer>(&self, writer: &mut W) -> Result<(), ser::Error> { | ||
ser_multiwrite!( | ||
writer, | ||
[write_u64, self.total_difficulty.to_num()], | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it makes sense to implement Default for HeaderVersion. In 2 months, all new blocks will have to be version 2, and having a default at that point seems like a good way to introduce logical errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default post-HF should be version 2 at that point. At least that's the intent here.
We may want to make it more explicit though and not use "default".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's assume for a second that it will be version 2 post hard fork. How do you manage that? Do we want default to look up the current height to know if we're >= block 250000? I would assume no. My vote is to remove default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was slightly agreeing with @DavidBurkett but then realized versions are rarely built by themselves, they're built with their headers. And then we have a bunch of code (mostly tests) that just want a header without caring much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I was thinking about this was in terms of two ways we need to create headers -
But to be honest I have not thought too deeply about this -