scribe
|
|
August 23, 2012, 11:02:34 AM |
|
I feel almost petty saying this after all that, but is the "Local Currency" option broken on the web wallet? I was expecting it to change the USD amount (e.g. to GBP) in the top-right, and the converted amount reported when sending money, but they seem stuck as USD whatever "Local Currency" is set to.
If you click the BTC amount in the top right it should alternate between your local currency and btc. Ah sorry - I meant that the local currency used doesn't switch to GBP, it stays as USD for me, whatever I choose under "Local Currency". (In Chrome, not tested in Firefox/IE)
|
|
|
|
BkkCoins
|
|
August 23, 2012, 04:59:55 PM |
|
I've been experimenting with using your API calls to monitor addresses for payment arrival, in particular using the block-height JSON call.
It seems that block data is often 300-500k each but contains mostly non-useful data. For monitoring address receipts we only really need (address,amount) data and probably a reference transaction hash. So I was thinking that data transfer load could be reduced to 10% or less if you offered such a "minimal-block-height" or "block-output" API call (or a query option like format=json&outputsonly=1).
It could even be pre-compressed data to reduce size+load further, eg. many servers let you store a gzip file that feeds static requests without compressing on the fly. Or maybe you already do that to reduce server load for static data.
|
|
|
|
DublinBrian
|
|
August 23, 2012, 07:06:08 PM |
|
The map on Blockchain.info shows all my Blockchain.info Wallet transactions as taking place off the coast of africa. I thought at first that their server may have been located on the british island territory of St Helena. But then I noticed the location shown is precisely at a latitude of 0 degrees, and a longitude of 0 degrees.
Needless to say I am not at that location in the ocean. Blockchain do have my correct IP when I log into their wallet to send bitcoins. So I dont know why they dont display my correct location. Or is this a privacy feature?
|
|
|
|
Stephen Gornick
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
August 23, 2012, 07:19:21 PM Last edit: August 23, 2012, 07:46:10 PM by Stephen Gornick |
|
Needless to say I am not at that location in the ocean.
The Bitcoin network does not record any IP addresses. The only way that Blockchain.info shows an IP address with a transaction is if your Bitcoin.org client node is connected to one of Blockchain.info's nodes or Blockchain.info has a connection directly to your node. The very first node that they see broadcast or relay a transaction is the one they list for the "Relayed by ip" field. If you sent a transaction, this "first to relay" value may be from your node or it might be one that you were connected to. For those wishing to not have this informated revealed, Bitcoin can be used with the Tor network or they can specifically have their client connect to a specific node for relaying. Blockchain do have my correct IP when I log into their wallet to send bitcoins. Wow, if Blockchain.info is using the web client's IP address and publishing it, that would be disturbing. I'm going to right now go make transaction to verify myself that this is not happening. [Update: I just sent a transaction and an IP different from mine displayed for the "Relayed by ip" field, which is good. If you were seeing your own IP address be shown by Blockchain.info for a transaction you sent, then it must have just been coincidence -- something which technically could happen if you also happened to be running a node and blockchain sees your node as the first relay (presuming Blockchain.info excludes its own host for this when broadcasting transactions). That would be unlikely to happen twice though as there are several hundred nodes that Blockchain.info connects to.]
|
|
|
|
minimalB
Donator
Hero Member
Offline
Activity: 674
Merit: 523
|
|
August 23, 2012, 10:38:27 PM |
|
Ah sorry - I meant that the local currency used doesn't switch to GBP, it stays as USD for me, whatever I choose under "Local Currency". (In Chrome, not tested in Firefox/IE)
Same problem here. Local currency jumps back to USD constantly. This glitch was reported several times by several users, but unfortunately it was never fixed.
|
|
|
|
teslacoil404
Member
Offline
Activity: 78
Merit: 10
|
|
August 24, 2012, 09:39:22 AM |
|
|
|
|
|
thirdlight
|
|
August 24, 2012, 12:26:51 PM |
|
Ah sorry - I meant that the local currency used doesn't switch to GBP, it stays as USD for me, whatever I choose under "Local Currency". (In Chrome, not tested in Firefox/IE)
Same problem here. Local currency jumps back to USD constantly. This glitch was reported several times by several users, but unfortunately it was never fixed. Local currency now stays remembered for me, but "Label address" has stopped working on FF (works on Chrome, though).
|
|
|
|
MemoryDealers
VIP
Legendary
Offline
Activity: 1052
Merit: 1155
|
|
August 25, 2012, 01:24:49 AM |
|
I've noticed that when sending BTC via SMS, if the BTC are not claimed within a certain amount of time, they disappear. Here is an example from my own account. As a test, I sent 1 BTC to my own cell phone number and intentionally never claimed the BTC. Now when I check my wallet history or click the link from the SMS, it says that the funds are gone. This is the first time I confirmed it %100 for sure, but I am 99.9% sure this has happened with lots of other Bitcoins I have sent to people who didn't know how to claim them. Can you let us know what is happening to these Bitcoins? How's the new server?
|
|
|
|
giszmo
Legendary
Offline
Activity: 1862
Merit: 1114
WalletScrutiny.com
|
|
August 25, 2012, 04:25:17 AM |
|
I've noticed that when sending BTC via SMS, if the BTC are not claimed within a certain amount of time, they disappear. Here is an example from my own account. As a test, I sent 1 BTC to my own cell phone number and intentionally never claimed the BTC. Now when I check my wallet history or click the link from the SMS, it says that the funds are gone. This is the first time I confirmed it %100 for sure, but I am 99.9% sure this has happened with lots of other Bitcoins I have sent to people who didn't know how to claim them. Can you let us know what is happening to these Bitcoins? How's the new server? HANG HIM HIGH!!! Ok, wait for what he has to say first I sent 1BTC at a time to many many people via instawallet but I bookmark all these urls and tell them that to claim the bitcoin they have to move it out of my control as else I will take it back after a month assuming they are not interested. Actually I took back almost all of them and would be very pissed to see instawallet doing that instead of me. Luckily this does not mean that almost all of them did not get interested. Many had a lot of questions and stayed in touch over 10 mails but they never took the coin that I offered them to try it out. Instawallets statement about keeping the coins available is also very interesting. They told me here on the forum that there is no timeout and all wallets will be kept available indefinitely and if they ever end operations, they will send all the bitcoins into brain wallets based on the respective url. Clever clever
|
ɃɃWalletScrutiny.com | Is your wallet secure?(Methodology) WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value. | ɃɃ |
|
|
|
piuk (OP)
|
|
August 25, 2012, 12:22:24 PM |
|
Ah sorry - I meant that the local currency used doesn't switch to GBP, it stays as USD for me, whatever I choose under "Local Currency". (In Chrome, not tested in Firefox/IE)
This should have been improved recently. If you change the local currency in the web interface then it will remember the preference permanently. However changing the currency in the app will not save permanently. I've been experimenting with using your API calls to monitor addresses for payment arrival, in particular using the block-height JSON call.
It seems that block data is often 300-500k each but contains mostly non-useful data. For monitoring address receipts we only really need (address,amount) data and probably a reference transaction hash. So I was thinking that data transfer load could be reduced to 10% or less if you offered such a "minimal-block-height" or "block-output" API call (or a query option like format=json&outputsonly=1).
It could even be pre-compressed data to reduce size+load further, eg. many servers let you store a gzip file that feeds static requests without compressing on the fly. Or maybe you already do that to reduce server load for static data.
How many addresses are you monitoring? You might be better of using /multiaddr or the new receive payments api. Documentation will be up when migration to the new servers is finished (Monday probably). but "Label address" has stopped working on FF (works on Chrome, though).
Your browsers cache probably needs clearing. This is the first time I confirmed it %100 for sure, but I am 99.9% sure this has happened with lots of other Bitcoins I have sent to people who didn't know how to claim them. Can you let us know what is happening to these Bitcoins?
10 BTC was sent to http://blockchain.info/address/1HeQQdDrro19eNVnFdE8M45xkde9xeanyb which was then sent to http://blockchain.info/address/1EYUqoG5nKC6ev22XRCjm4Vzn3jKjF3vjd. Do you recognise the address 1EYUqoG5nKC6ev22XRCjm4Vzn3jKjF3vjd or this transaction http://blockchain.info/tx-index/14391595/ec981a189b69e00053c11b07042b1f3ba9f846f7f3e05fcacf1512188084271b?Payments are never reclaimed by us, I suspect you may have accidentally swept the funds yourself (unless the SMS provider is intercepting the message). New server is in but not not migrated yet. I was up until 5 last night trying to get it finished but setting up bitcoind in virtualbox is taking longer than i thought.
|
|
|
|
|
MemoryDealers
VIP
Legendary
Offline
Activity: 1052
Merit: 1155
|
|
August 25, 2012, 02:11:17 PM |
|
I recently changed the password to my wallet. Now when trying to pair my iphone with my existing wallet by scanning the QR code, I receive the following error: When I enter the password that I am %100 sure is the correct password (I can login to the wallet in Safari using this password.) I still receive the same error. I have already run the "integrity check" on the wallet as well.
|
|
|
|
crazy_rabbit
Legendary
Offline
Activity: 1204
Merit: 1002
RUM AND CARROTS: A PIRATE LIFE FOR ME
|
|
August 25, 2012, 03:17:49 PM |
|
I was wondering when the documentation for the Receive payments API will be put up. I've been writing a PHP class to interact with the simple merchant API when I noticed the API's changed. I've updated everything except the ability to generate new addresses which are supposed to be possible through the receive payments api. However, when I click the link, nothing is there.
Any idea when this will get sorted?
thanks! den (crazy_rabbit)
|
more or less retired.
|
|
|
ErebusBat
|
|
August 25, 2012, 06:19:29 PM |
|
I recently changed the password to my wallet. Now when trying to pair my iphone with my existing wallet by scanning the QR code, I receive the following error:
...
When I enter the password that I am %100 sure is the correct password (I can login to the wallet in Safari using this password.) I still receive the same error. I have already run the "integrity check" on the wallet as well.
I get this error too Roger... I think it has to do with 2-factor auth. What I ended up soing was setting up a mobile wallet that does not have 2FA and that paird successfully.
|
|
|
|
MemoryDealers
VIP
Legendary
Offline
Activity: 1052
Merit: 1155
|
|
August 26, 2012, 01:13:13 AM Last edit: August 26, 2012, 01:27:24 AM by MemoryDealers |
|
This problem may have to do with the wallet password length. I created a brand new wallet with a 102 Character password. When I tried to pair my phone with the brand new wallet, I received the same error. I then shortened the password to 30 characters and the phone was successfully able to pair with the wallet.
I then shortened the password for my original blockchain wallet to 30 characters, but the phone will still not sync.
(My passwords contain upper and lower case letters, numbers, special characters and white spaces)
I would prefer not to need to start a new wallet so I can keep my address book and account history.
-------------------------------------------------------- I've discovered another bug. When updating the main wallet password in google chrome, it says that the password change succeeded and logs me out of the wallet. When I try to login with the new password, it fails. I can still login with the original password one time. If I log out, and try to login with the original password again, it fails, but I can now login with the new password.
-------------------------UPDATE----------------------------
I updated my password to a shorter one with upper and lower case letters and numbers, now the iphone wallet successfully pairs with the wallet, so the issue seems to clearly be related to the wallet password.
|
|
|
|
piuk (OP)
|
|
August 27, 2012, 11:13:34 PM |
|
In approximately 1 hour the Site will be going down for the final migration to the new servers.
The database needs to be copied over which will take a few hours (~120 GB over 100Mbps Ethernet = 3 hours)
|
|
|
|
unclemantis
Member
Offline
Activity: 98
Merit: 10
(:firstbits => "1mantis")
|
|
August 28, 2012, 01:18:03 AM |
|
In approximately 1 hour the Site will be going down for the final migration to the new servers.
The database needs to be copied over which will take a few hours (~120 GB over 100Mbps Ethernet = 3 hours)
Your timing just can't be any perfect. I was planning on working on my prototype and I am using blockchain.info as the wallet Oh well. I am looking forward to the improved servers! Keep up the good work!
|
|
|
|
mokahless
|
|
August 28, 2012, 03:31:27 AM |
|
Still down? No updates? Problems upgrading?
|
|
|
|
piuk (OP)
|
|
August 28, 2012, 03:50:38 AM |
|
Your timing just can't be any perfect.
There is no good time for it to be done. But in the name of progress is has to be done at some time Still down? No updates? Problems upgrading?
Everything is going fine, a little slower than expected. The ndb tables have copied, just the larger Innodb tables left. Still going to be an hour or two left i'm afraid.
|
|
|
|
mokahless
|
|
August 28, 2012, 03:52:56 AM |
|
Thanks for the update
|
|
|
|
|