Depends on D631
- Group Reviewers
- rSTAGINGa9e694c25063: Support for encoding addresses using cashaddr.
rABCa9e694c25063: Support for encoding addresses using cashaddr.
Does this basically operate as a closure then?
What's the point of constructing this in such a way if we have a single-use function that takes params?
This was added in another patch already?
I assume this needs chainparams to add the appropriate prefix and whatnot?
Maybe we should generate a bunch of these?
A few nits, but I think the double padding problem can be an issue. This needs to be accounted for and tested. Except that, it's good.
We need to make sure we don't double pad when encoding/decoding.
This needs more logic and a test for it.
Please use uint8_t
I think it'd be preferable to use std::copy but not a big deal.
- Convert entire data-part with ConvertBits. Used to convert the hash only.
- Ignore extra padding
- Added test to encode/decode bunch of random addresses.
- Explicitly check that we get the expected size when converting bits 8 <-> 5 and back.
- Use std::copy instead of memcpy
This is how boost suggests working with boost::variants http://www.boost.org/doc/libs/1_64_0/doc/html/variant.html#variant.motivation
Yes, it needs the address prefix.