Both of these errors should be fully fixed now.

If the transaction doesn't show on the site or http://bitcoincharts.com/bitcoin/txlist/ it will need to be resent.

Is the error still occurring now?

Probably yes. Passwords containing | are known to cause issues.

Does your password contain any symbols such as quotes or | ?

The fee calculation on the android app is different to the web interface. I think it still considers the base fee to be 0.005 BTC. The app has been due for an update for while but I haven't got round to packaging it yet.

Replied via PM. You can now request a new code be sent on the login page if the first one isn't received.

-----

Bitinstant cash deposits re-enabled.

Tags can no longer be submitted that link to blockchain.info, they must have context outside of blockchain.info itself.

Internal refactoring, transaction and address pages should be quicker to render.

Is it possible you could link to the transaction in question. A 0.005 BTC fee may have been included.

- sign and verify message added to JSON RPC api (credit to Mike Hearn)
- Improvements to the javascript verify message functionality.
- Bug fixes to JSON RPC when using ruby and python libraries.
- Improvements to polish translations.


Thank you for the bug report, Davout reported this issue previously. It will take a while to get a fix out so in the meantime users of the iphone app should be careful sending values less than 0.01 BTC.


Thank you for the feedback. Fees are calculated based on the priority of the transaction which should mirror how Bitcoin-Qt calculates it https://en.bitcoin.it/wiki/Transaction_fees. Is there a specific transaction that you think should have included a fee but didn't? If the fee policy is set to generous a 0.001 BTC fee is guaranteed to be included.


This is expected behaviour since once an address is deleted the client no longer has a record of it so thinks the address belongs to an external wallet. I could see how it could be confusing though. Perhaps the sub-header would be better changed to "Transactions involving your active addresses".

Looking for someone to implement Bitcoin-Qt's sign and verify message functionality in Java. Using either bouncycastle or the Java SE crypto libs.

15 BTC bounty.

I have doubled the width of the value field on the custom send form and added an extra 20px to the quick send form. (Changes will show the when the next update is deployed).


This makes sense. However It might be easier to add a checkbox to the custom send form to make the transaction anonymous rather than duplicating the form.


Can do.


I think this should be left to the user to decide rather than forcing a particular way. My second password would take a while to type using the onscreen keyboard I might be tempted just to disable it instead if it was an inconvenience.

Thanks for the suggestions.

Finally got round to implementing the changes to logging.

- All wallet ip addresses are now hashed.
- Still recording the hashed ip the wallet was created with and the hashed ip it was last updated with. This cannot be disabled.
- Access logs remain disabled.
- You can now choose to enable or disable more detailed logging in [Account Settings]. This is much better from a security standpoint and includes actions taken by admins. For example if you submit a two factor authentication request and it is approved you will see "admin (piuk) approved two factor reset request" in the logs. I am still the only admin at present. Logging is disabled by default.

Enabled:



Disabled:

Here is a photo of the rack https://i.imgur.com/wMFG1.jpg. We do not have a full rack to ourselves yet.

3 mac mins (top) - 4 servers in one chassis (middle) - firewall & intrusion detection (bottom).


They are not really ddos attacks which a company like that would be able to help with. It is more just a few dozen tor ip addresses causing problems. For example one ip opening 1000's of websocket connections, or generating huge numbers of forwarding addresses.


It is entirely in ram. The site averages about 200-300 queries / second which isn't anything particularly special but cpu usage of ndb averages about 20%, considering this is decent 4 server cluster I feel like the load should be lower. However I haven't benchmarked it against any other database so I don't know if it really is an ndb problem or poor schema/query design. On the plus side it's pretty stable, I think before the recent maintenance it ran for 100 consecutive days without problems. In future I imagine moving to something like HBase/Cassandra but not for a while yet.

This error should be fixed now.

All deposit methods are enabled again now (Refresh the page and re-login if the buttons are missing).

Ok back online, just catching up with the blockchain. Apologies for the downtime everyone.


dos attacks and high load in general coupled with the fact I have been away. The changes made today should help a lot with reliability.

Database partitioning finished. Just need to make a full backup, run one alter table query, catch up bitcoind and the site can be brought back online.

Still waiting for a job to finish, should not be much longer.

-----

The database needs rebalancing as when the site was moved from two servers to 4 servers the existing tables were not repartitioned. This means the load is much higher on two of the servers rather than being distributed equally. The task is taking much longer to complete than I was expecting but it is important that it is done.

Will do tomorrow.


Maintenance taking a bit longer than expected: https://bitcointalk.org/index.php?topic=134461.0

I have asked the guys at the datacenter to take a photo.

-----

Couple of problems upgrading the database, ETA another hour.