If you use the "Check Callback Response Log" tool on https://blockchain.info/api/api_receive is your server giving the correct responses?

Basically it is prevent automatic spidering of wallets using lists of usernames from other bitcoin sites or common english words.

If you have an email associated with your wallet if an unknown person tries to access it we can send you an email asking for your approval. Without an email we have no way to contact you, previously the default action was to allow login anyway now this has been changed to deny login.

You can still use blockchain.info with no contact information but must login using the identifier rather than an alias.


There is some confusion from the support staff here. If you are receiving this error simply send us your alias and we can send you the identifier without providing other information (If there is contact information associated with the wallet it must matches your own details).


This is the HTML 5 offline storage http://www.html5rocks.com/en/tutorials/appcache/beginner/. It means you can still open your wallet even if blockchain.info is offline and is a good way you can recover your identifier without our help.

I've updated some of the coinbase keywords now. For some reason ghash.io removed theirs.

Could you PM me or post one of the addresses.

/merchant/new_address doesn't accept a callback parameter, the callback set in account settings is global for all addresses and cannot be changed for individual addresses. Instead you could do either of the following:

1) When you create an address store in your database the user that it was created for. When a callback is received use the address to query the user that made the payment.

2) Use the receive payments API which can have a custom callback set for each address.

instead of using /merchant/new_address, use:

https://blockchain.info/api/receive?method=create&address=$your_address&callback=http://www.XXX.com/callback.php?who=2833

The problem is 90% of users will not read warnings and will simply choose the easiest option. It's like when you give users the option to not pay transaction fees, the majority of them will, only to complain about transaction being slow to confirm soon after.


This should be easier now. Links in approval emails will now whitelist the browser that made the request even if the approval email is opened on a different device.

For example: If you want to open your wallet on a friend's PC you can use your alias and open the approval email on your phone.

---

In a related change, aliases will no longer work on wallets with no email associated. Anyone receiving the following error "Insecure Alias. Please login using your wallet identifier link." needs to use their identifier to login and once logged in add an email to the account. Contact Support (Not me) if you have forgotten your identifier.

----

Support for an increased number of pbkdf2 iterations

An custom number of pbkdf2 rounds can now be choosen in [Account Settings] -> [Debugging]



Enabling this feature alters the wallet format slightly making it none compatible with old clients. The following clients support the new format

Chrome Extension v3.0.1
Firefox Extension v1.9.1
Mac OSX App v0.3 (Not available in app store yet)
Android App v3.61

The iPhone app and third party Windows 8 apps do not support the new format and will cease to function if the pbkdf2 rounds are altered. Once the remaining clients are updated the new default will be 10,000 iterations and all existing wallets will be upgraded.

Depending on the speed of your device and the number of rounds a progress bar may now be displayed on login.



----


Account Settings


Should be fixed now.

You could fetch the users receiving address e.g. https://blockchain.info/address/17FcpJFGAT8NkcKtMsnvpcjnzrMnezGzT1?format=json
 and extract the transaction hashes and amounts from there.


Seems like it was forwarded correctly to me: https://blockchain.info/tx/ac22686c4cf8bd6ce04aa0aa05aa81064c473015fe44a98687b018957de2141d

https://blockchain.info/address/1Fq7RxSgZ6sRNFNZumYGSrHDr2jVmNrohu

Your server is correctly responding with the *ok* message.

Tim,

The above two transactions were combined and forwarded in one transaction - https://blockchain.info/tx/eea53810936c07020522b279f263495a62349a5f9977c418c2a682ddef6d3d1b. Inputs can be combined to save on transaction fees, but the total amount received at your end should be the same. You will receive one notification for the total amount rather than separate notifications for each input.

I assume 1GC6ucWxo5stow6U8A1gUaptK77n7E6FhQ your receiving address? 

It means someone opened your wallet login page from an unknown browser. It doesn't mean someone has the right or wrong password, they were denied from trying any password.

Your alias is the same as your bitcointalk username which means anyone can visit http://blockchain.info/wallet/ReCat and you will receive "authorisation required" email. Changing your alias to something more obscure should prevent you receiving any more of these emails.

I would recommend you change your wallet alias. If anyone visits http://blockchain.info/wallet/YourUsername you will receive an "Authorization Required." email, this isn't really a problem but using an alias which isn't the same as your username on bitcointalk or other bitcoin sites will prevent anyone from easily accessing your wallet login page and you will stop receiving the malicious login attempt emails.

Ideally note down your wallet identifier and don't use an alias at all.

That is the public key of the address, not the random number (public keys always being with 04). These addresses are not affected by the random number issue.

8.3 BTC has been returned to the sending address.

Shared Addresses are valid for one transaction only, don't re-use them as after the first transaction reaches 6 confirmations they stop being monitored.

No transactions from these addresses appear to have been made from blockchain.info and they are not affected by the recent rng problem.

Unfortunately it looks like the person who generated the paper wallet may have retain a copy of the private keys and waited for you to fund the addresses.

Important!

I can confirm there is a problem with the RNG used by blockchain.info javascript clients being poorly seeded when initialised in a background webworker task. In some browsers this could lead to duplicate R values being used when signing transactions (Firefox is likely to be particularly vulnerable). This issue effects the transaction signing code only, not the generation of private keys.

Patches have now been deployed, Please ensure you upgrade to the latest version of your Blockchain.info client.

Chrome extension - v2.85
Fixefox extension - v1.97
Mac client - v0.11

Users of the web interface should clear their browsers cache before next login.

Only a handful of addresses are known to be affected thus far. Likely if you have been affected by this problem your coins will have been taken already. All affected users will be refunded in full, please PM me or email help@blockchain.info.

-----


BIP38 supported has been added.

Jesse James has informed me of a problem with the rng used by blockchain.info javascript clients being poorly seeded when initialised in a background webworker task. In some browsers this could lead to duplicate R values being used when signing transactions (Firefox is likely to be particularly vulnerable). This issue effects the transaction signing code only, not the generation of private keys.

Patches have now been deployed, Please ensure you upgrade to the latest version of your Blockchain.info client.

Chrome extension - v2.85
Fixefox extension - v1.97
Mac client - v0.11

Users of the web interface should clear their browsers cache before next login.

Only a handful of addresses are known to be affected thus far. Likely if you have been affected by this problem your coins will have been taken already. All affected users will be refunded in full, please PM me or email help@blockchain.info.

Yeah this would probably be an improvement. Though the spreads between the other exchanges are normally pretty tight and the market price on blockchain is only a guide, it doesn't need the same accuracy as if it was being used for high frequency trading etc.


bitcoinaverage looks good, however for our usage direct links to the exchanges are needed.


Yep your right, it must due to another reason. I'll take a look.


No response yet. For anyone who is interested in testing an Alpha can be downloaded here https://blockchain.info/wallet/desktop-client - I've also put up a bit of a comparison between the available Blockchain clients here https://blockchain.info/wallet/ways-to-access

As of today only 51% of users of the Blockchain.info app have upgraded to a patched release, if the pattern is similar with other apps a fair number of wallets might still be vulnerable. But you are right it definitely could have been worse.

GMT.


Unfortunately yes http://tech.slashdot.org/story/13/05/20/2315216/google-drops-xmpp-support. Skype is still functioning. Edit: XMPP might not have been fully dropped actually

Which part are you having trouble with? Receiving the callback notification? If you enter your callback URL into the "Check Callback Response Log" tool https://blockchain.info/api/api_receive are there any errors?

The problem is you created a wallet on the android app then paired it will a different wallet through the web interface which overwrites the previous wallet details. From the identifier you have posted I believe I have located the previous wallet and have PM'd you the details. Simply login to that wallet online and the coins should be restored.