Topic: Gettin' Paper - Redeemable Private Keys now in Mt. Gox Mobile 3.1 (Read 3077 times)

that worked!  Mt. Gox 3.14 is now working on my iPhone 3GS.  Thanks!

I meant a restore in iTunes and then jailbreak again with redsn0w.

Nerzahd I'm having the same problem with the app stuck on the splash screen.  What exactly do you mean by full restore?  Is this a device process, redsnow process, cydia process?

Nerzahd, great!  I'm really happy to hear this.

Best,
rasengan

I have made a full restore. Now it works! Great app thanks.

It looks like there are others who are also having this issue.  Somehow, on a fresh iOS iPod Touch 4th Generation with iOS 5.01 (8GB) it seems to work for me.  However, we will look into this.  In the meantime, assuming Apple doesn't have any sort of prejudice at this point, the application should be available on the App Store soon.

An update for the app has been released on Android (3.2) with a Barcode Scanner built in. Further, the titlebar/statusbar is now visible.  It seems that this issue alone was enough to 1-2 star an app. T_T  We changed this right away!

Enjoy ^______^

Version 3.14 on ios 5.01 still not work for me. stuck at the mt. Gox screen.

This is a good call, and I strongly agree.  It's in the pipeline/development queue and we will see this soon.


The app is ready, but we are doing testing which should put this release for sometime next week.  Sorry about the extended delay!

When will we be able to move past 2.9 on iPhone.  Wish I had an android, but iCrap was paid for by a client who needed a mobile app .

Have you considered emulating the YubiKey functionality in the MtGox app, at least as a blockade for withdrawals?  So that the app can be used to generate one time passwords one must type into a PC to do a withdrawal.  This isn't going to ever be as strong as a real YubiKey, but it would be free and available immediately and would be a meaningful impediment to theft via keyloggers.

Sorry about the inconvenience.  When entering ".4995" I was able to reproduce this issue.  However, "0.4995" worked for me.
Anyway we fixed this issue in version 3.13 which is now on the market.  Please let me know if this works better for you now.

Again, sorry about the inconvenience.

Cheers,
rasengan

Im trying to withdrawal 0.4995 btc but I'm getting a error.  I'm assuming its a fee error of some sort but how do I know how much to deduct? Why don't you just automatically deduct fee?

edit:  the error says "please enter a valid amount".  0.4995 is the total balance in there right now which is what i'm trying to withdraw.

Hmm, it's possible that 3.11 still didn't show on the Market when you updated.  It should be there soon enough.  Let me know if somehow it doesn't show up and I'll send you the APK.  Sorry for any inconvenience!

Cheers,
rasengan

I updated but login page still shows 3.1

The easiest way would be to update through the Android Market.  If it is not showing in the Android Market, try restarting the device since the Market appears to cache results.  It is updated here though:  https://market.android.com/details?id=com.mtgoxlive.trader

Cheers,
rasengan

whats the easiest way to get 3.11 on android?

These are some pretty interesting suggestions, and we will definitely look into this.  A two or more part private key would be very interesting.  (The first thing that actually came to mind was a scene in "Gundam Seed Destiny" where Kira and Lacus have two separate keys which are both required to unlock Freedom. -- Pretty cool idea)

Also, just a note, a small update (version 3.11) was pushed which includes a fix for some users who have indicated issues while on unstable wireless networks.

Edit: forgot a comma in the first sentence
Edit #2: added gundam remark

I couldn't find a PM or e-mail, sorry.

Mini private keys are always 22, 26, or 30 characters long and always start with 'S'.  Simply limiting SHA256 hashing to those lengths will solve the Base58 checksum problem.

Mini private keys are validated by hashing SHA256(entry + "?") and confirming the result starts with eight zero bits.

The computation for merging a multi part private key (regardless of the number of parts) is to get the private key of each part (a 32-byte unsigned bignumber, just like a standalone private key), adding them all together, dividing the total by the secp256k1 constant N, and using the remainder as the combined private key.

The constant N is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

You are probably aware that Base58Check-encoding a private key implies the version byte 0x80, and that mini private keys start with 'S'.  I propose using a different version byte to specify that a private key is incomplete and requires other keys.

A version byte of 0xA2 will ensure that a Base58 private key starts with '6' instead of '5'.  A mini private key could start with 'P' to specify it is partial.  Either of these would simply be a clue to MtGox (or any other redeemer) that the private key needs to be combined with something else to be complete, and to show a second prompt asking for the other half of the private key, rather than proceeding to redeem the single private key.

1. We already do the Base58 checksum. The only issue - I guess - is the fact we fall back to SHA256 if the checksum does not verify. For your "mini private key format" checksum I'll have to check the doc and see how it works.

2. That shouldn't be an issue, could you show me a couple of those (you got my email) with the required computation and we'll implement it.

Couple quick requests/suggestions.

1 - Are you able or willing to implement the Base58 checksum code, as well as the mini checksum for Casascius coins so typos can be automatically rejected?  (Both are simple SHA256-based checks documented on the wiki under "Base58Check encoding" and "Mini private key format" respectively).  Last I checked on MtGox, website accepts checksum failures (typos) and reports there is no balance, rather than rejecting the input.

2 - Two-part private keys have been recently discussed on the forums.  They would provide very strong security, because it would enable physical bitcoins where the manufacturer can guarantee nobody has the private key, by creating half and allowing a 2nd party to add the other half.  The two part scheme is based on elliptic curve addition, so the full bitcoin address can be computed with neither party knowing the full private key.  Would you be willing to implement a redeemer for a two-part private key?  (Two part private keys are convertable to a single private key with elementary math - a bignumber add and a divide - no complex EC stuff required.  Each of the private keys would likely contain a bit flag that indicates it is only "half" of a key, so your system would know to ask for the other half).