Author

Topic: libBase58 C++ implementation (Read 1503 times)

sr. member
Activity: 504
Merit: 250
September 01, 2014, 08:54:38 AM
#7
Can someone provide a really short sample code  Grin
sr. member
Activity: 504
Merit: 250
August 31, 2014, 01:51:52 AM
#6
I don't get it. That's it.

Help me understand  Grin


"Encoding Base58
---------------

Allocate a string to store the base58 content, create a size_t variable with the
size of that allocation, and call:
   bool b58enc(char *b58, size_t *b58sz, const void *data, size_t binsz)
Note that you must pass a pointer to the string size variable, not the size
itself. When b58enc returns, the variable will be modified to contain the actual
number of bytes used (including the null terminator). If encoding fails for any
reason, or if the string buffer is not large enough for the result, b58enc will
return false. Otherwise, it returns true to indicate success."



It's good old fashioned C 'optimized' API. If you have a buffer already allocated of size_t, you can try to use it.
However, it's too short --> you get false. And you need to try with a bigger buffer.
If it's ok, it returns the effective size that was used. The string is null terminated but by giving you the size back, you avoid a strlen which scans the string.
Believe me or not, but these kinds of cubblesome API used to be the norm when memory was precious.


Amazing...
sr. member
Activity: 467
Merit: 266
August 30, 2014, 09:37:08 AM
#5
I don't get it. That's it.

Help me understand  Grin


"Encoding Base58
---------------

Allocate a string to store the base58 content, create a size_t variable with the
size of that allocation, and call:
   bool b58enc(char *b58, size_t *b58sz, const void *data, size_t binsz)
Note that you must pass a pointer to the string size variable, not the size
itself. When b58enc returns, the variable will be modified to contain the actual
number of bytes used (including the null terminator). If encoding fails for any
reason, or if the string buffer is not large enough for the result, b58enc will
return false. Otherwise, it returns true to indicate success."



It's good old fashioned C 'optimized' API. If you have a buffer already allocated of size_t, you can try to use it.
However, it's too short --> you get false. And you need to try with a bigger buffer.
If it's ok, it returns the effective size that was used. The string is null terminated but by giving you the size back, you avoid a strlen which scans the string.
Believe me or not, but these kinds of cubblesome API used to be the norm when memory was precious.
sr. member
Activity: 504
Merit: 250
August 30, 2014, 08:06:31 AM
#4
I managed to get to Step 6 of Private key to WIF.
see here: https://en.bitcoin.it/wiki/Wallet_import_format

Here's the code that did it. It's pretty messy, but it works and it's fast. (the cout function is there to confirm if it's really working):
Post some suggestions if you have some time  Cheesy

Code:
#include 
#include
#include
#include "sha256.h"    //from http://www.zedwood.com/article/cpp-sha256-function
#include
//extern "C"
//{
//#include "b58\CBBase58.h"    //failed attempt
//}


using namespace std;
   int a = 0;
   int b = 1;
   int h = 0;
   string j = "80";

int main()
{
   do
   {
        h++;
        stringstream streamm;

        streamm << j << setfill('0') << setw(64) << std::hex << h;
        string ggg = streamm.str();
        string g = sha256(streamm.str());
        string gg = sha256(g);

        string str = gg;
        stringstream xx;
        stringstream yy;
        xx << str[0] << str[1] << str[2] << str[3] << str[4];
        string xxx = xx.str();
        yy << ggg << xxx;
        string yyy = yy.str();
        stringstream XD;
        XD << yyy << endl;

        string lol123;
        XD >> lol123;
        cout << lol123 << endl;


   }
   while ( a < b );
   return 0;
}
sr. member
Activity: 504
Merit: 250
August 30, 2014, 07:51:34 AM
#3
I don't get it either. I would have expected it to take only the last two arguments and return a pointer to a newly created string (or a null pointer in the event of failure). Requiring a string to already be allocated makes no damn sense, since there's no way to know how large the string needs to be before the function is called (an upper bound can be computed, but that's inelegant and slightly wasteful). I also don't see why it needs to modify b58sz, since the resulting string is null terminated, so its length can be trivially determined anyway. The whole thing makes no sense.
Yup. It doesn't make sense.

Anyone know a simple base58 library/header for c/c++?
legendary
Activity: 4326
Merit: 3041
Vile Vixen and Miss Bitcointalk 2021-2023
August 30, 2014, 07:48:49 AM
#2
I don't get it either. I would have expected it to take only the last two arguments and return a pointer to a newly created string (or a null pointer in the event of failure). Requiring a string to already be allocated makes no damn sense, since there's no way to know how large the string needs to be before the function is called (an upper bound can be computed, but that's inelegant and slightly wasteful). I also don't see why it needs to modify b58sz, since the resulting string is null terminated, so its length can be trivially determined anyway. The whole thing makes no sense.
sr. member
Activity: 504
Merit: 250
August 30, 2014, 07:22:00 AM
#1
I don't get it. That's it.

Help me understand  Grin


"Encoding Base58
---------------

Allocate a string to store the base58 content, create a size_t variable with the
size of that allocation, and call:
   bool b58enc(char *b58, size_t *b58sz, const void *data, size_t binsz)
Note that you must pass a pointer to the string size variable, not the size
itself. When b58enc returns, the variable will be modified to contain the actual
number of bytes used (including the null terminator). If encoding fails for any
reason, or if the string buffer is not large enough for the result, b58enc will
return false. Otherwise, it returns true to indicate success."

Jump to: