I think the situation at Gox is *obviously not good* but also I think that they are now *cornered* in what they can and can't say wrt what effect that will have upon their business (and the Bitcoin market itself).

As much as everyone loves to *hate Gox* I think that they really don't have many options to proceed without causing a panic sell (which some argue might already be happening).

They might have made a "balls up" with the US but I don't see how this is going to be magically fixed by them posting anything at all (it will only really be fixed when people are reporting their transactions from BTC to USD are working in a reasonable time frame again).

There are other exchanges so as an end-user you have choices.

So it's strange then isn't it that still the majority of banking and insurance back-end software is written in COBOL not Java.

(something to do with *security holes* like we are seeing with Java implementations perhaps?)

Am not really into language wars, however, recent *thefts* that have occurred have been due to Android and Java (not heard of anything similar in that horrible language C++ which Satoshi himself stupidly decided to use).

You only sleep 4 hours per day?

I might have some work on CIYAM Open for you down the track but I would hope that you first get some decent rest.

Looks like an interesting project and CIYAM Open https://ciyam.org/open would be happy to list this project "fee free for life" (as one of the first 10 projects to be listed) if you are interested in using a task workflow control system (please view the slideshow at http://ciyam.org to see how this works).

The project Moneychanger is listed and has attracted a few developers who will have much of the skills that this project requires (and am sure would be interested in working on tasks for BTC when they have completed their current work).

Welcome to PM me for further details.

Hmm... haven't heard of that occurring before - but I was just rolling out changes so it could possibly be due to that. Please try it again now.


Actually if you are referring to the "Home Page Implementation" task unfortunately I have already agreed to let another contributor work on that (their bid hasn't been created yet as I only just opened up the task).

There will be other upcoming tasks for those with HTML/CSS skills so please check for such tasks in the near future (very likely to be in either September or October depending on how long it takes for the "Home Page Implementation" to be completed).

What's the time?

Unfortunately what seems like a very simple question can become rather tricky when you start to consider "daylight savings" adjustments that are made twice a year in many countries.

CIYAM Open can tell your current UTC offset through .js (and does) but doing this is not always what a user might want. For a start there is the problem of specifying future date and times (as they may occur after a transition in or out of daylight savings) and then there is also the fact that you may actually be using a computer that is not your own or your computer might have temporarily changed timezone due to being on a trip.

To help make this less of a problem you can now select a Timezone (from your user settings which you find by clicking on your username towards to the top right when you are logged in) and whether or not you want to use daylight savings.

The time (which now appears towards the top left of the screen when you are logged in) will then change according to the selected timezone and will be followed by the commonly used abbreviation (such as EST for Eastern Standard Time or EDT for Eastern Daylight Time).

After that you don't need to think about what date and time it will be in the future - it will be simply what you select (any adjustment required for DST will happen under the covers).

Your PGP/GPG public key *contains* an email address (although it may not be a real one) - so an email should have been sent to whatever email address is in your PGP/GPG public key (in this case it was a tormail.org address - could the recent problems with tormail be the issue?)


The original username and password would be displayed only if the original PGP/GPG public was used. If you could contact me via PM then I will sort this out for you.

Also please note the user names are case sensitive in CIYAM Open (so if you signed up as Sothh you cannot login using sothh as your user id).

BTW - I just tested creating a new anonymous account with no difficulty at all so I am not sure what has happened in this case.

A lot of work is going on "underneath the covers" - support for international time zones will be rolled out shortly (making it easy for a project manager to correctly set their due date and times even with "daylight savings").

Further work on the UI is also underway - a new look and feel can be expected before the end of the year.

You can't other than make sure that you provide a new address for every incoming tx.

Yes - assuming the minimal fee is paid then this is probably the only reasonable solution.

The problem is fundamental to the way Bitcoin tx's work - it needs to use UTXOs (unspent transaction outputs - which are Bitcoin tx's that were sent to you) in order for you to send funds to someone else.

Typically the client will make random choices of UTXOs you have to build up enough (or often *more than enough*) BTC for the tx you are sending and will then send the *change* back to yourself.

From an anonymity point of view it is probably best that it actually chooses the UTXOs randomly (although an *exact* match might be a better selection if one exists).

In short though there isn't much you can do about this as fundamentally this is how Bitcoin works (you could of course send *yourself* smaller amounts if you want to create smaller UTXOs to be used in future txs although there is not likely to be any guarantee about which ones it will choose to use).
 

If a lower UTXO does not exist there is no choice but to use the one it chose so is the problem that there was a lower UTXO that could have been chosen for this tx (sorry your "changeback" terminology is a little confusing)?

From some other recent topics it appears that there might be a problem with blockchain.info wallets (similar to the problem with Android ones).

If you have any other BTC in a blockchain.info wallet you might be best to move it *offline* (i.e. to an address created using bitcoin-qt or perhaps vanitygen - not something created by an online wallet).

Great to see progress and if anyone needs help in regards to using CIYAM Open feel free to PM me.

No need to encrypt the public key (it is *public* after all) so all that is needed is to create a new random password and then GPG email it (unless the user has had their GPG private key stolen in which case you are no better off than any other automatic reset).

As I also stated I encrypt sensitive information in the DB (including the password hashes) - and the key used (along with a UUID salt) is composed of parts that are all separate from the DB (and can include a compiled in UUID, a UUID in a separate file as well as a RAM only portion - meaning that only an uber-hacker who has root access, can decompile and has a memory dump of the running system would have any real chance of working out how to decrypt anything).

The problem is that users often re-use passwords so if someone managed to crack your encryption then they may well be able to do much more damage than just find what is in your DB.

In regards to your question about automatic password resets I have not yet made a decision (for now only manual resets will be possible). I think for GPG users though this would be safer than for others.

I currently do not have any automatic email reset at all (have a look for yourself please - my system is open source after all https://github.com/ciyam/ciyam).

I do allow a manual reset (that has to be done myself) which then involves a GPG encrypted email being sent (assuming the user signed up with GPG) or at worst an email with a link to create a new password (the last would only be sent if I am satisfied the reset is genuine which can be done with questions *other* than what they think their password is).

Although using C++ does give some big advantages with regards to security it is still *never* a good idea to store encrypted passwords. You can have things like "password recovery question and answers" (regardless of whether you do resets manually or automatically) that do not need to involve needing to know an end-user's password.

CIYAM Open uses this browser-side approach for its sign-in accounts (it also supports OpenID) - the password is hashed multiple rounds along with a server specific id (so hashes will not be the same for others that implement a CIYAM system) and finally concatenated with a UUID and hashed again (so a replay attack is not possible).

On the server side (for storage) the password hash is encrypted with a UUID for salt so that even in the event of the DB being stolen rainbow tables will be of no use.


The password is passed in the clear (through SSL of course) to the server side where it is hashed iteratively and compared against the hash in the DB (thus the password cannot be retrieved - only hashes compared).

Actually on CIYAM Open I wouldn't even try to crack your password (as I wouldn't have enough computing power to do so unless you used a very poor password - all I could do is change your password).

I also think that email password resets are a problem (although not so much if you use a GPG sign-up which CIYAM Open offers).

Asking someone to disclose even part of their password insecurely (i.e. via plain email or IM) is of no extra benefit and in fact is just even less secure than asking them to disclose something you sent in an initial email.

Why not also offer 2FA via Google Authenticator (I can give you the necessary code in C++ if you like as CIYAM Open offers this)?