My "Local Currency" keeps resetting from Euro to U.S. Dollar no matter what i do. Every other day or so, when i login on web or use mobile app... it will be reset to U.S. Dollar... Grrrrr : )
Also... i guess there should only be "can swap" or "can change" and "you" should be "your" and "by clicking" in this sentence:
You can change swap between BTC and you local currency at any time by click the green button below a transaction.
Topic: Blockchain.info - Bitcoin Block explorer & Currency Statistics - page 138. (Read 482400 times)
I found 2 problems with the actual Android client:
- It shows a warning: it says that it is going to occupy some space. This is a warning of the usual "Bitcoin Wallet", but your version doesn't download the blockchain.
- I had a wallet with only 0.01 btc. I tried to sent them to another address. I said that it's better to add the 0.0005 fee, and "it ask me if I want to add the fee", but the answers are only "ok / cancel". I think that it should be better to have three answer, yes/no/cancel.
- It shows a warning: it says that it is going to occupy some space. This is a warning of the usual "Bitcoin Wallet", but your version doesn't download the blockchain.
- I had a wallet with only 0.01 btc. I tried to sent them to another address. I said that it's better to add the 0.0005 fee, and "it ask me if I want to add the fee", but the answers are only "ok / cancel". I think that it should be better to have three answer, yes/no/cancel.
Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different.
hmmm... i tried
confirmation=
confirmations=
conf=
minconf=
and none worked for me.
...and i've run out of guesses
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount?
It is 0 confirmations. Btw if total_received is the only thing you need your better off calling /q/getreceivedbyaddress with multiple addresses e.g.
http://blockchain.info/q/getreceivedbyaddress/14Dj368DZyFPDbSbERf53wcGLWefsZUamn|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U
Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different.
thanks... but that url adds them all together into one amount.
i need a list of total_received per address.
did you modify/customize your bitcoind to be able to provide this info? if the standard one could do this i might not need to use a 3rd party api.
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount?
It is 0 confirmations. Btw if total_received is the only thing you need your better off calling /q/getreceivedbyaddress with multiple addresses e.g.
http://blockchain.info/q/getreceivedbyaddress/14Dj368DZyFPDbSbERf53wcGLWefsZUamn|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U
Default is also 0 confirmations, but you can pass a confirmations parameter if you want something different.
sorry one more question if you don't mind... how many confirmations does the 'total_received' amount relate to? is it 1+ and is there a way to get the 0 conf amount?
Code:
"addresses":[
{
"address":"1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a",
"n_tx":3,
"total_received":385000000,
"total_sent":125000000,
"final_balance":260000000
},
so, am i to assume that the limit on the number of addresses queried is related to the GET specification?
400 is the limit for active addresses, i'd split it into multiple calls if you need more.
okay, just curious... don't need anywhere near that many
so, am i to assume that the limit on the number of addresses queried is related to the GET specification?
400 is the limit for active addresses, i'd split it into multiple calls if you need more.
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
the documentation under /api is a bit (a lot) vague.
thanks.
The usage has changed a bit recently. There is now few parameters:
Mandatory:
- "active" - addresses which you want included in the final balance.
Optional:
- "archived" - addresses which you want included the results calculations but don't want included in the final balance.
- "offset" - skip the first n results
- "filter" - show only transactions of a specific type: sent = 1, received = 2, moved = 3, escrow = 4;
Separate multiple addresses with | e.g.
http://blockchain.info/multiaddr?active=1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U&archived=14Dj368DZyFPDbSbERf53wcGLWefsZUamn
thanks!
so, am i to assume that the limit on the number of addresses queried is related to the GET specification?
or can one POST a larger list?
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
the documentation under /api is a bit (a lot) vague.
thanks.
The usage has changed a bit recently. There is now few parameters:
Mandatory:
- "active" - addresses which you want included in the final balance.
Optional:
- "archived" - addresses which you want included the results calculations but don't want included in the final balance.
- "offset" - skip the first n results
- "filter" - show only transactions of a specific type: sent = 1, received = 2, moved = 3, escrow = 4;
Separate multiple addresses with | e.g.
http://blockchain.info/multiaddr?active=1Cp3FEaXFkSutXGYHKuNkkeYog6bsHpk7a|1HLFLgrwQRuFVu1dhjjPLWqY314DsMjRco|19Wv538dbmoMTtoGPxwqD8N6ZYzFyMBL2U&archived=14Dj368DZyFPDbSbERf53wcGLWefsZUamn
apologies for the ignorance, but could someone give an example of how to call multiaddr?
the documentation under /api is a bit (a lot) vague.
thanks.
the documentation under /api is a bit (a lot) vague.
thanks.
* Full iPhone app now available in the app store
* Multibit can now import blockchain.info wallet files (using the latest git).
Select your encrypted wallet.aes.json or unencrypted wallet.json
Enter your password and second password then press the import private keys button.
This is now the recommended way to restore wallet backups in case anything happens to blockchain.info (and the web interface isn't in your browsers cache). Thank you to Jim618 for merging the changes.
Also thank you to the recent donators.
* Multibit can now import blockchain.info wallet files (using the latest git).
Select your encrypted wallet.aes.json or unencrypted wallet.json
Enter your password and second password then press the import private keys button.
This is now the recommended way to restore wallet backups in case anything happens to blockchain.info (and the web interface isn't in your browsers cache). Thank you to Jim618 for merging the changes.
Also thank you to the recent donators.
What a great idea 
Yep, good ideas. I've added them to the todo list. Thanks.
Here two new graphs for now:
Estimated Blockchain size (Not including database indexes)
My Wallet Transaction Volume
Hi Ben,
While this isn't a crucial feature, it is one of the very neat aspects of your site (blockchain.info).
We would love to see more cool statistics like this.
Examples I came up with:
Robert
While this isn't a crucial feature, it is one of the very neat aspects of your site (blockchain.info).
We would love to see more cool statistics like this.
Examples I came up with:
- fastest block mined (in last 100,000 blocks)
- slowest block mined (in last 100,000 blocks)
- link to first block ever mined (genesis block)
- Day of highest total network hash rate since January 1 2012 (basically highest hash rate of year).
Robert
What a great idea
There are some options, I will be good if you add all of them ( the sender should be able to make a choice )
1) Nothing ( as it is now, it will be good if the email will have also a warning like this, example: "Be sure that you have your computer secured, because unclaimed bitcoins can be taken by viruses and bad people" )
2) Hidden email address ( your actual proposal )
3) The sender can write a "question" ( he know that only the receiver know the answer ) and the email will contain the private key encrypted with the hash of the "answer".
Another good thing is the possibility to add a personal message, example: "here is a present for you!"
( the sender should be able to make a choice )1) Nothing ( as it is now, it will be good if the email will have also a warning like this, example: "Be sure that you have your computer secured, because unclaimed bitcoins can be taken by viruses and bad people" )
2) Hidden email address ( your actual proposal )
3) The sender can write a "question" ( he know that only the receiver know the answer ) and the email will contain the private key encrypted with the hash of the "answer".
Another good thing is the possibility to add a personal message, example: "here is a present for you!"
Nope. This attack is done while the email is in transit. By the time the victim receives the email and activates the legitimate sweep; the attacker has already stolen the coins.
If a malicious admin is reading your emails you've probably got more pressing security issues than loosing a few bitcent.
The key could be encrypted with a shared password or pin but then you loose all convenience of a simple email. When talking about small amounts the benefits out way the risks in my opinion.
What do you think of this:
The email only contains the partial email address of the sender:
you have been sent bitcoins from w_ll_t@_l___h__n.info
When claimed it asks what is the full email address of the sender and the user has to fill in the missing letters. e.g. in this case
[email protected]
What if you offered the choice of an optional security question?
If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
Another good idea If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
What if you offered the choice of an optional security question?
If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
If you're sending coins to anyone other than a complete stranger, there should be at least one private detail you could prompt for.
I think that this step will be enough for making it secure
- When "claimed" the key is swept into a new bitcoin address.
- When "claimed" the key is swept into a new bitcoin address.
Nope. This attack is done while the email is in transit. By the time the victim receives the email and activates the legitimate sweep; the attacker has already stolen the coins.
You have to find a breakpoint somewhere. What about all the banks that send password resets by email? While I agree that email is patently insecure and needs major help, I think this functionality is necessary for new users to help introduce them. Who knows, maybe some new users' coins WILL be stolen because of an email related insecurity - perhaps that would wake them up to the fact that there is more they could do to keep themselves secure.
While I understand that some websites send passwords and identity confirmations by email; in flagrant lack of appreciation of the danger; I seriously doubt any reputable bank is doing so. Rather banks are moving more and more to these two-factor systems where they send you a key-generating device.
The problem is considerably worse with bitcoins though; the process of scraping anything that looks like an address and stealing any funds on it could be completely automated very easily. Scraping every single format of password-resetting email and knowing every single bank account web site's log on method is considerably harder and you leave traces all over the bank's weblogs. Stealing bitcoins can be done close to anonymously if you've got that magic private key.
You're quite right that there has to be some level of practicality considered. I'm simply arguing that distributing private bitcoins keys by email to newbies is setting the bar considerably lower than it should be if we're talking about money.
Jump to: