Change format of gobject, store/transmit vchData instead of hex-encoded string of a string#1934
Conversation
codablock
left a comment
codablock
left a comment
There was a problem hiding this comment.
utACK with 2 small nits (I'm fine if you leave them)
| void CProposalValidator::Clear() | ||
| { | ||
| strData = std::string(); | ||
| strDataHex = std::string(); |
There was a problem hiding this comment.
Just a nit: There is .clear() on std::string
| { | ||
| std::vector<unsigned char> v = ParseHex(strDataHexIn); | ||
| strData = std::string(v.begin(), v.end()); | ||
| strDataHex = std::string(v.begin(), v.end()); |
There was a problem hiding this comment.
Just a nit: There is .assign(begin, end) on std::string
|
Hmm, no protobump? Do you plan to first upgrade all nodes and then release a new version with a protobump? |
|
No protobump is needed, it's backwards compatible on p2p level just like #1933 Missed a thing in serialization, fab47d0 should fix it. |
|
I see that it's backwards compatible, but as we keep the protoversion on 70208, the new code/signing will never trigger until we release a version with protoversion >= 70209. But now that I'm thinking about it it starts to make sense. If we protobump now, old nodes will immediately start to ban new nodes. |
|
re-utACK fab47d0 |
|
Yes, I mean, it's implemented in such a way that we talk to old nodes in old format and to new nodes in new format i.e. it always serializes/deserializes correctly on a per node basis, even though it does it differently for different versions. |
…ed string of a string (dashpay#1934) * Change format of gobject, store/transmit vchData instead of hex-encoded string * fix (limited string for old format)
…ed string of a string (dashpay#1934) * Change format of gobject, store/transmit vchData instead of hex-encoded string * fix (limited string for old format)
2 participants
It really makes no sense to store/pass around hex string of a string... This should shrink data size to half its size as of now.