BitShares Forum
Other => Graveyard => Marketplace => Topic started by: bytemaster on February 10, 2014, 06:36:19 pm
-
I am looking for someone to implement an import tool for MultiBit wallets:
namespace bts {
std::vector<fc::ecc::private_key> import_multibit_wallet( const fc::path& wallet_dat, const std::string& passphrase );
}
This method should be implemented as a pull request as a single .hpp and .cpp file.
-
for who use multibit wallet sending BTC for obtaining AGS?
-
for who use multibit wallet sending BTC for obtaining AGS?
Yes, to make it easier for these users.
-
how should i import without such a tool now？
-
how should i import without such a tool now？
Now there is nothing to import because there is no BitshareX wallet out yet. When it will happen you'll use the import tool.
-
how should i import without such a tool now？
Export private keys manually and then import them manually.
-
how should i import without such a tool now？
Export private keys manually and then import them manually.
I use Armory and Electrum sending bitcoins. Can I export the private keys from those 2 client and import the private keys to Bitcoin- QT and import QT's wallet into Bitshares to my ags? Or I just need to import the private keys directly into Bitshares?
-
how should i import without such a tool now？
Export private keys manually and then import them manually.
I use Armory and Electrum sending bitcoins. Can I export the private keys from those 2 client and import the private keys to Bitcoin- QT and import QT's wallet into Bitshares to my ags? Or I just need to import the private keys directly into Bitshares?
I will create bounties for importing from any wallet.
-
I am looking at importing the Multi-Bit wallet. In fact I just need to get the scrypt-nastiness in order.
-
same here, i'm basicaly done but the decryption produces errors...
-
Well here it is, I tried it localy and it loads the right keys from encrypted and unencrypted wallets.
https://github.com/InvictusInnovations/BitShares/pull/35
-
Any program using this method will need protobuf as dependency.
-
oh and btw, the reason decryption did not work for me: Java Strings are UTF-16 (big endian)
So if you want to supply password you need to consider that!
-
The API calls for. UTF8. You should convert to utf 16 inside the call.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
That would make it impossible to use for everyone who uses 16bit chars in Multibit. Ascii password users only...
-
That would make it impossible to use for everyone who uses 16bit chars in Multibit. Ascii password users only...
No it wouldn't. All 16 bit UTF can be converted to and from 8 bit UTF. When I produce a GUI that accepts characters in UTF8, it will convert to the proper UTF16 prior to being hashed for the password.
-
This sure isn't my area of expertise. But let's say my password in multibit is four 16bit characters and it comes down to 0x1122334455667788. If the api call converts every input from UTF8 to UTF16 although it wasn't UTF8 in the first place, i would end up with 0x00110022003300440055006600770088 and could not decrypt my wallet. Where is my mistake?
-
This sure isn't my area of expertise. But let's say my password in multibit is four 16bit characters and it comes down to 0x1122334455667788. If the api call converts every input from UTF8 to UTF16 although it wasn't UTF8 in the first place, i would end up with 0x00110022003300440055006600770088 and could not decrypt my wallet. Where is my mistake?
Your mistake was in your application of conversions.
If the string is already in UTF16 then you convert it to UTF8, pass it in, convert it back to UTF16 and you are good to go.
But when I grab a string from the command line it will be in UTF8, so I convert it to UTF16 and we are good to go.
When I grab a string from Qt I will grab it in UTF8, convert to to UTF16 and be good to go.
When the user enters their string into a QLineEdit then they will enter same characters they did in multibit and Qt will handle the representation internally (in what ever form they use).
-
Wow, i should go to sleep... just noticed i had mistaken UTF8 for 8bit chars... :-[
-
Ok, guess I was a bit late this time. :)
Anyway, here are my pull requests:
https://github.com/InvictusInnovations/fc/pull/6
https://github.com/InvictusInnovations/BitShares/pull/36
-
Admit it you were glad about the tip with the 16-bit strings, that really messed with my head for quite some time...
-
I spent a couple of hours wondering why my scrypt code wasn't working... Turned out to be me swapping the parameters. Doh.
Then it was the UTF issue, fortunately I decided to take a break and while taking a bit of fresh air I figured out that it probably was an encoding issue. But yes I shouldve read the forum to save me that bit. Instead I had to deal with the conversion. *shudder*
-
Here is the request with the converted password: https://github.com/InvictusInnovations/BitShares/pull/37
-
Are any of these working, secure, and ready to use or are we still working on it?
-
Are any of these working, secure, and ready to use or are we still working on it?
I need to evaluate the pull request and integrate it with bts_wallet and will be doing that this week.
-
I just made a pull request which fixes the OS X compile. Do you need anything else?
-
I just made a pull request which fixes the OS X compile. Do you need anything else?
It didn't work... I posted the error on github