Implement error correction codes for base32 strings, using the CRC-5-USB polynomial. The encoder transforms 26-digit rfc-3548 strings into 31-digit z-base-32 strings, which are capable of recovering from any single-digit mutation, are visually distinctive, and protected against a wide variety of human-factor errors in the coding alphabet. Format is described in the following draft BIP:
https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki
I'm trying to diagnose why this isn't working on the pull tester - it compiles & runs just fine on Ubuntu 12.04 and Mac OS X 10.9. The function in question is a POSIX standard API.
uint256.h:19:39: error: boost/heap/detail/ilog2.hpp: No such file or directory
Seems like pulltester uses an older version of boost and so doesnt know the heap directory.
Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/865264f3d785fb954261e5453707cf706f3de5e8 for binaries and test log.
This could happen for one of several reasons:
If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
@TheBlueMatt I'm not sure why this failed. It looks like the unit tests compiled and ran just fine...
Looks like it failed on a timeout. Probably a fluke in the pull tester environment.
NACK from me-- 1,600 new lines of code for a "don't care" feature. Users should not be typing in or copying and pasting base32 strings anytime, anywhere-- if they are, then we have failed to design a usable system.
When do people deal with long data strings in bitcoin already? Addresses, private keys/wallet backups, transaction identifiers.
EDIT: In some cases we can legitimately get rid of the need to manually input information. E.g. the payment protocol should reduce the need to input addresses most of the time. But it can't be turtles all the way down - at some point you have to save/restore a few hundred bits of binary data.
I agree with gavin here. Much as I prefer base32 over base58, and appreciate actual error correction code over hacky truncated double-SHA256, I believe we shouldn't encourage or develop features to make these cryptographic strings more human-usable, and we should focus on protocols that don't require humans even seeing these.
If I'd design Bitcoin today, and there was a need for some encoding for cryptographic material, I'd certainly vote for something like this, though.
have you tried to import a priv key into the various services ? ( I am not fighting with anyone here ) especially not SIPA.
It is random .. honestly some of them are base 58 with spaces some are hex and others are WHO KNOWS ..
I am not going to point out the variations and who do does what but it annoying.
I use blockchain, coinbase and armory .. and none of them seem to have a standard for privkey import export. ( paper wallets aside - I believe that is HEX encodes and compressed - but I havent looked at the code to see why they work always and others dont.
@int03h There is a standard wallet import/output format, implemented in master as importwallet and dumpwallet. Not sure where it's documented, but it's too late to switch the private key representations now. In my experience all software supports at least the base58-based bitcoind importprivkey/dumpprivkey format for individual keys.
Agreed that if bitcoin was designed today I'd vote for anything but Base58. However that ship has sailed.
venting more than anything ;) .. It's gotten my heart racing more than once. OMG OMG I lost my coins .. OMG ! :) There are always paper wallets so its not tragic.
Closing this, I think the implementation is solid but this functionality should only be added if there is an immediate application.