You can do this (look at the options for indexing all tx's that were introduced after the levelDB introduction).

To be able to query any tx you'll need to "re-index" (this is another option).

Anyway if there are no Android devs interested in working on this then I'll probably just end up using Google 2FA after all (thanks for the link and your comments).

Okay - thank you very much for clarifying that (I had made a rather silly assumption and will not use an integer).

Now that I am aware of that I see the "key space" problem you were initially getting at I will change the algo although to my thinking something like:


which should be just as secure (assuming "secret" is say 64 bytes from /dev/random).

Of course an even longer secret (or perhaps hash iterations) should also help to harden it against the brute force attack that you mentioned.

Okay - maybe we are talking in tangents - as I've never actually *used* Google 2FA perhaps I am just missing something obvious here.

So using Google 2FA on an Android phone requires you to enter a 16 byte key/PIN per app (I honestly don't know and had assumed maybe incorrectly that it was a much shorter PIN in which case my approach would be equally as secure)?

If you have a hold of a users OTP and you the knew the time that it was used then for either algorithm then you can easily brute force the "pin" by just calling the "relevant totp" function across the key space of the PIN.

How is that key space going to be any different with the two approaches if the user is using say a 6 digit PIN?

I grok the key space point but I don't see how that makes it easier to "brute force" - surely the length of the "pin" being used is all that matters for brute forcing (as by definition brute forcing means that you are trying every possible value of that to "crack it").

Assuming a 6 digit pin and a 30 second interval then the brute forcing of either algo would take on average half a year or so (assuming you already know the user's password of course).


I do take your point about "rolling my own" (although I'm not convinced it's flawed yet but I am willing to be convinced) and yes I guess simply swapping hmac_sha1 for hmac_sha256 could be another useful approach.

Sorry Daily Anarchist - I didn't pay attention to which board this post was made in and just assumed we were talking about the Satoshi client (my bad).

Perhaps someone else who uses Bitcoin Wallet for Android would care to comment.

Actually that is still just a problem of clear communication (human to machine rather than human to human).

Huh?

It only shows you which address it was sent to and if you created a new address and gave it a label then you'd be able to see exactly what it was for.

Can you please explain why the algorithm linked to is significantly weaker?


Technically nothing - the problem is that its more commonly known "name" has Google in it (as explained in the OP).

So the algo I have posted is similar but not exactly the same (so it won't be known as Google Authenticator). If you think the algo could be improved without turning it into Google Authenticator then I am all ears.

I've read a number of posts about getting 2FA and not trusting Google authenticator.

Although there is no reason not to trust their algo I am willing to offer 5 BTC for the creation of an Android app that basically works on a very similar algo (https://github.com/ciyam/ciyam/blob/master/src/crypt_stream.cpp#L144) in the hope that it will create an alternative that people can choose to use if they are wary of anything originating from Google.

The scope of the app would be to create multiple account entries that each contain a "shared secret" so that the 2FA could be used for multiple websites (it will be used by CIYAM Open as a first).

The Android app would have to be open source of course and preferably written in C++ - if you have any interest (and the skills) to develop such an app then please respond (if enough interest then I will set up a task on CIYAM Open for this).

I wonder if this would really attract highly intelligent people at all - if your IQ is high enough then making money is actually not a problem (so not something you would need to enter a contest to do) - instead typically very IQ people are more interested in solving difficult problems or inventing things (such as Bitcoin).

There is no need to *reward* that as the people who are intelligent enough are already driven by their own desire to improve things (getting financial rewards for winning competitions is typically a far more low IQ thing).

The problem is one of clear communication - if a date is written as DD/MM or MM/DD then unless the day is > 12 it is ambiguous - if written in the form YYYY-MM-DD it is not.

I prefer the less ambiguous and DB query friendly format even though I grew up in country that uses a different format (same as I learned to write XX AUD rather than $XX).

It does seem a little silly - but wars have been fought over less.

The YYYY-MM-DD is the ISO format and also the most common format used in (mainland) China - with all the confusion with US MM-DD or English DD-MM it only took me a short while to actually *prefer* the ISO format (it's also the best way to store dates in a DB as you can search efficiently on a year or a month within a year as well as a specific date).

If other formats are really wanted then they should be in their own sub-forums (i.e. US News, British News, etc.).


Not for Hong Kong though (down there they still use DD-MM-YYYY) and I'm not sure about Taiwan.

And BTC came through a few hours back - all in all pretty smooth apart from the trading software in Ripple itself (they need to do a *lot* of work on that).

Thanks for your the helpful instructions!

You clearly don't get the point - if I can't build the software *from* the source code *myself* then how could I be sure any executable that you provide is actually using the same source code (so *seeing* the source code is not enough).

There is a reason why open source is the preferred approach to security - it does not require trust.

Indeed - it had changed to 7899.99999999 and now a reasonable portion of the order has been filled (seems my second "cancel" didn't actually occur so the order was still there today but that could be due to a poor internet connection so am not claiming any bug in regards to that).

Next step will be to get the BTC out from Bitstamp!

You made it impossible for him to do so - if you (and him) could let your egos go for a second you'd realise that this helps Bitcoin not at all.

I don't really care for the silly argument but would hope you guys both remember that Bitcoin is more important than any of us.

If you can prove he has bad security (on any other website than the one he admitted to) then why not just do so?