Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Change object_id to more than 32 bit #1088
According to the code,
That means the maximum value is
As of writing, the object with biggest
The chain is now running at around 1M operations per day, which is around
This is an important issue, but we still have some time to fix it.
Things to be done:
Since it affects serialization, after fixed in core, client libraries will need to adapt, so we need to at least notify them. Old client libs should be compatible before we reach the 32bit limit. Known client libraries include:
By the way,
added this to New -Awaiting Core Team Evaluation
in Project Backlog
Jun 24, 2018
moved this from New -Awaiting Core Team Evaluation
to Unassigned - Protocol Upgrades
in Project Backlog
Jun 25, 2018
Of course you can try. But I still think it's better (for you) to get familiar with the code base with smaller issues first. Just my own opinion though.
By the way, this issue is now labeled "discussion needed". We need to evaluate it, figure out the scope, the direction, before start coding.
I am just thinking about the serialization issue. To test:
My question is where are the places that use serialization? Persisting to disk and p2p are what come to mind. Any others? I may be able to create a test if everyone thinks it is worthwhile.
I'm just thinking of the un-serialization of a 32-bit value by a peer running old code, where the stream was serialized by a machine running new code. So during the
I'm not saying it is broken. I just want to provide a scenario that may not have been tested for. I think the only way to test that is to
As I have not gone through the particulars of pack and unpack, I may be thinking of a problem that simply does not exist.