I have this particular wallet which was originally showing my crypto balance, but after wallet upgrade and reinstallation via seed phrase, the coins are showing zero balance both on the primary (and decentralized 3rd party wallet). I then followed up the address for one of the transactions I did few months ago, and I still found the coins/tokens intact on the bsc scan.
What could be the possible solution after several installation and reinstallation and reimporting of wallet seed phrase?
This issue has been resolved using the extra layer of passphrase security which I didn't know I put in place.
Related
Newbie here. Can someone teach me like im 6 years old?
How can I do my own hlr lookup without paying a companies?
I see some people send some company links who offer hlr lookup.Thats not what I'm looking for...
I made some research and couldn't find much about how can I build a hot lookup.
Any help would be great.
Hi sdaassadasdasd asdasdsad,
TL;DR you can't perform your own free HLR lookup against telephone numbers on the public telephone service (formally called the PSTN), which is why you can find online providers who provide it as a paid service. There is always a charge, even to the HLR lookup providers.
It also depends what do you want to achieve. A HLR Lookup will let you know if a mobile phone number is assigned to a subscriber of a mobile network operator (MNO), and which MNO it is assigned to.
HLR lookups don't provide location (aside from some rudimentary country-wide location based on the Mobile Switching Centre that the telephone handset is being controlled from). They also don't usually provide an IMSI if that's what you are looking for, because these days most MNOs will implement home-routing which gives a temporary IMSI matched on their router so that they can conceal the real IMSI (to avoid fraud).
So, if you do want to perform a HLR lookup to check if a mobile phone number is "real" and assigned to a subscriber on a public network then I'm presuming you want to send a HLR request to query an external MNO - i.e. a public telephone number, not a local one running on your own equipment.
To query an external MNO then you will need to send a request, usually over the SS7 network, to the mobile network operator who was originally assigned the telephone number you want to know about. Eventually, if you have done everything correctly and the MNO wants to respond, you receive a response back which gives you the details you need to then ascertain if the telephone number is assigned to a subscriber, and if the subscriber is active on the network or not.
To send the HLR request, without going through an online provider, you will need at least:
equipment that talks the SS7 protocol (specifically to include MAP requests because a HLR is a type of MAP request)
somewhere to host your equipment
an SS7 interconnection from an SS7 backbone provider
point codes allocated from the SS7 backbone provider
someone to setup program the equipment
your own telephone prefix range for the far-end MNO to be able to respond back to your original request. You may be able to lease someone else's telephone number range if you don't have your own.
Once everything is setup then there's an additional per MSU (message signalling unit) cost. You can think of an MSU a bit like an IP packet, you send "one" and you get a response. You are charged by the SS7 backbone provider for every MSU you send that transits their network, regardless of if you get a response back from the MNO you want the message forwarded to.
I'm happy to answer any other questions on it, but I can't think of a way you can perform your own HLR lookup without incurring charges somewhere along the line.
I am implementing a license key system on Google AppEngine. Keys are generated ahead of time and emailed to users. Then they log into the system and enter the key to activate a product.
I could have potentially several hundred people submitting their keys for validation at the same time. I need the transactions to be strongly consistent so that the same license key cannot be used more than once.
Option 1: Use the datastore
To use the datastore, I need it to be strongly consistent, so I will use an EntityGroup for the license keys. However, there is a limit of 1 write / second to an entity group. Appengine requests must complete within 60 seconds, so this would mean either notifying users offline when their key was activated, or having them poll in a loop until their key was accepted.
Option 2: Use Google Cloud SQL
Even the smallest tier of Google Cloud SQL can handle 250 concurrent connections. I don't expect these queries to take very long. This seems like it would be a lot faster and would handle hundreds or thousands of simultaneous license key requests without any issues.
The downside to Google Cloud SQL is that it is limited in size to 500GB per instance. If I run out of space, I'll have to create a new database instance and then query both for the submitted license key. I think it will be a long time before I use up that 500GB and it looks like you can even increase the size by contacting Google.
Seems like Option2 is the way to go - but I'm wondering what others think. Do you find Entity Group performance for transactions acceptable?
Option 2 seems more feasible, neat and clean in your case but you have to take care of db connections by yourself and its a hassle with increasing load if connection pooling is not properly used.
Datastore can also be used in license key system by defining multiple EntityGroups with dummy ancestors based on few leading or trailing digits of key to deal with 1 write / second to an entity group. In this way you can also easily determine EntityGroup of a generated or provided license key.
For example 4321 G42T 531P 8922 is license key so 4321 can be used as EntityGroup and all keys starting with 4321 will be part of this EntityGroup. This is sort of sharding like mechanism to avoid the potential of simultaneous writes to single entity group.
If you need to perform queries on some columns other than license key then a separate mapping table can be maintained without an EntityGroup.
You can mixed them , Google Cloud SQL is only have Keys and Email , with 500G i belived you can store key for all of people in the planet .
In other hand you can request google to increase data size limit .
I will go with Option 1 datastore, it's much faster and scalable.
And I don't know why you need to create EntityGroup, you could make the "license key" itself as the Key, so each Entity is in it's own EntityGroup... only this will make things scalable.
Would it be possible to build a Ticketmaster style ticket reservation system by storing all information in a Cassandra cluster?
The system needs to be able to
1. Display the correct number of tickets available at one time
2. Temporarily reserve a ticket while the customer is making the purchase
3. No two users can ever buy the same ticket.
For consistency all reads and writes should be made at quorum. I'm not sure how to implement steps 2 or 3?
Yes, you can.
However, there will be some transactions where you want strict consistency. For example, consistency does not matter when the user is browsing the site and adding tickets to their shopping cart, but when they checkout and select a specific seat number on a specific day consistency matters a great deal (double bookings being a bad thing, especially for high interest events).
So, you could implement 99% of the functionality in an eventually consistent database and implement the checkout process in a consistent database. This is also nice because you can scale 99% of your system that likely gets >70% of the load horizontally and across multiple data centers. Just keep in mind that you will have to deal with the scenario of your site being up but your checkout process being down (ex., an error dialog at checkout asking them to wait/retry and giving them a promo code for their troubles).
The last detail is that you will need to update your eventually consistent database's "number of available tickets" after someone checks out. The good news is that this can be done lazily - queue up that job and do it whenever your system has some spare cycles. It certainly never has to happen in the critical path of the user's checkout process.
Are there any mobile-friendly Credit Card billing solutions for mobile sites similar to Bango?
The advantages of Bango I have seen compared to regular Credit Card solutions that make it considerably "mobile-friendly" are:
1) It does not require the user to enter their full name and billing
address to make a payment. The user is only required to enter their
Credit Card number, expiration date, and CVC code (if they are in
the U.S., they will also have to enter their Zip Code). That is significantly less input than is normally required for Credit Card payments, which is a big plus on small mobile key pads.
After a user makes an initial Credit Card payment, their details
are stored by Bango, and the next time the user needs to make a
payment with the same Credit Card, they just have to click a single
link and it processes the payment on their stored Credit Card.
Needless to say, this is very convenient for mobile users as it is
analogous to Direct Carrier Billing as far as the user is concerned since they won't need to input any details.
The downside with Bango is that their fees are higher than others, all payments must be processed via their site and branding, there is a high minimum ($1.99) and a low maximum ($30) on how much you can charge users, and you need to pay a monthly fee on top of the high transaction costs.
It is due to the downsides mentioned above that I am looking for an alternative solution that also does the advantages 1) and 2) above. Is there anything like that? I looked at JunglePay and they do neither 1) nor 2).
We, Balanced, have simliar functionality to what you're looking for. Card number, and expiration are the only required information. However the more information you gather the better that fraud detection can happen, only asking for the minimum could open you up to chargebacks and the cost associated with them.
The second requirement you mention is a feature called card tokenization and most card processors should support this functionality.
Balanced is not inherently mobile focussed. It's a REST API so whatever you serve to the customer is up to you. You, as the developer, would create a webpage that takes in the card information, tokenizes it securely, and then submits the token to your server where logic in your application makes the charge whenever you're ready.
I have developed a mobile application which is using extensively web services. It connects to my shared hosting server to get real-time information. Therefore, making sure the server is up is extremely important. Otherwise I am going to lose customers.
Some background. I changed no less than 3 hosting providers because they were not very reliable in terms of uptime. My currrent hosting is way better than those previous three, have I used it now for over a year, they have 99.9% uptime guarantee and all, but today I had about 3 hours of downtime. Which is why I am creating this post.
Not all of us small developers can afford expensive dedicated hosting, or have our own servers at home (which is not a guarantee it never will be down). In my case, having shared hosting for a very reasonable $10-15/month is OK. Except for those few hours it might be down.
One idea I have to deal with this is the following: have a second (different) shared hosting with another provider, and make the app to default to using this second hosting when my primary host is down. It's very unlikely that both will be down at the same time. I am going to pay only a few dollars extra per month for this, not 10 times more per month as I would for a dedicated hosting.
I am sure I am not the first person in this situation. Have anyone found a good way to deal with this problem, not requiring deep pockets? We are after all talking only about short periods of downtime on the primary server.
Thanks in advance for your suggestions.
If you are relying on a third party host and don't want to pay for greater reliability then a second server is the way to go. Depending on your application and budget you will also need to consider:
Database access and synchronization
Hosts in different physical locations
Multiple domain names and/or load balancing
If you opt to use multiple hosts and switch to a different (backup) host if one (the first) fails then you should aim to always have both (all) always in use. This way you won't get caught out trying/having to switch over to a "backup" server. By always using both (all) you can be sure that they are both (all) always up to date and working.
If your service is so critical that a couple of hours down time would be unacceptable to your users, then it should be easy to get the users to pay for that kind of reliability. This could fund hosting with a provider who can provide a greater level of up time or a second site. This will also help fund the time and effort to set all this up. ;)