You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adopting this advice may make lightwalletd more solid, could possibly fix (currently-unknown) memory-use bugs and prevent future bugs, and could improve security (reduce memory-related attacks):
Probably should at least investigate. I have no idea how much work this would be.
I remember once we ran into a bug that this would have prevented, which was that the bytes of a block prevhash were reversed for display purposes (we always display block hashes big-endian, but they're stored little-endian), but instead of modifying a copy, we modified the actual stored hash, and that broke code that used that hash later. (The fix was to make a copy before reversing the bytes.)
The text was updated successfully, but these errors were encountered:
Adopting this advice may make lightwalletd more solid, could possibly fix (currently-unknown) memory-use bugs and prevent future bugs, and could improve security (reduce memory-related attacks):
https://levelup.gitconnected.com/building-immutable-data-structures-in-go-56a1068c76b2
Probably should at least investigate. I have no idea how much work this would be.
I remember once we ran into a bug that this would have prevented, which was that the bytes of a block prevhash were reversed for display purposes (we always display block hashes big-endian, but they're stored little-endian), but instead of modifying a copy, we modified the actual stored hash, and that broke code that used that hash later. (The fix was to make a copy before reversing the bytes.)
The text was updated successfully, but these errors were encountered: