I am working with blockchain apis with Exodus, and blockchain is providing feature to generate new wallet address (for e.g. -BTC) which is useful to hide original BTC address from users and it has limit of 20 unused addresses. If 20 generated address are not used by users then after 20 it won't allow to create new address. [This means at a same time only 20 users can work and generate address] to overcome this issue , https://www.blockchain.com/api/api_receive mentioned that ". If you encounter this error, you will either need to switch to a new xPub (within the same wallet is fine), or receive a payment to one of the previous 20 created addresses"
My questions are:
1) For e.g. BTC exodus original address is XXX
Is there any way/algorithm to "generate random" address [for e.g. XX1,XX2] by using XPUB key of exodus wallet and if I pay to XX1 or XX2 amount will basically go to "XXX" ? like blockchain.com is doing ?
2) Any way to overcome issue/limitation of 20 unused address of blockchain.com ?
for example create our own node and generating address ?, if Yes then if you have any solution API which work with PHP, nodejs? Please provide URL for same.
Thank you in advance
Let me know if you have any queries/questions regarding same.
Regards,
Brijal
You can generate as many addresses as you like with the blockchain.com API, by increasing the gap_limit parameter.
You can set it to 500 if you like.
However, you will need a way to scan and retrieve funds that are sent to those addresses. Exodus is not a good solution for this, since it only scans past 5 unused addresses.
It's not practical or useful to keep generating and scanning addresses forever. In normal circumstances, Exodus only generates new addresses once existing ones are used, so there is no downside to stopping after 5 empty addresses.
Using a more technical wallet would work better for generating and managing XPubs and addresses.
http://docs.electrum.org/en/latest/merchant.html
However, you would still need to more or less build a crypto payment solution from scratch.
There must be ready-made libraries for this, though be careful to pick one that is trusted.
Related
so I'm looking at this api docs on polkadot.js https://polkadot.js.org/docs/substrate/storage#staking
but I could not figure which one to use to actually query all the staking rewards given an account ID / publish address.
I was thinking I would have to loop for each era. but which one returns the staking rewards. so than I can calculate a total overtime? thank you very much !
In general, the node isn't used for querying historical state. Instead you very likely want to use an indexer service that generates data that is much easier to get queries on. There are a few options, but one of the most supported is substrate archive that I would suggest you use.
Alternatively you can look to substrate compatible block explorers to see what they do for this in their source code.
I'd like to generate ~10,000 Litecoin addresses and send 0.0001 LTC to each one (for a giveaway), what would be the best way to go about automating it so I don't have to do it by hand? I know how to generate them, but what would be the best way to loop through them and make a transaction for each individual address? Is there a library I can use? Any help would be highly appreciated.
To generate your wallets:
Go to this url:
https://walletgenerator.net/?currency=Litecoin
Move your mouse around to generate some randomness (or press the skip button on the right)
Go to the 'Bulk Wallet' tab
Enter 10,000 as the 'rows to generate'
This will generate your public/private keys. Be warned, I have never used this site, and do not trust it.
To populate your wallets
Look into the wallet: https://electrum-ltc.org/
Here is a stackoverflow post about it: https://bitcoin.stackexchange.com/a/49790
I wouldn't use https://walletgenerator.net/ to generate addresses if you know how to do it yourself. Just makes it a bit more secure. Also, if you are only going to put 0.0001 LTC in the account, it might not be useful as it will probably cost more to withdraw the LTC. Perhaps consider Ripple, as it has a very low transaction fee, so you could probably, for example, give away 1 Dollar worth of XRP and the client will be able to send it for 0.000012 XRP, meaning they'll still end up with most of their dollar.
As for bulk sending, you will need to compile the HEX instruction and then send that instruction to a live node. I don't have a live node, so I use blockdaemon. They have an api for submitting signed transactions. Here's the one for ETH:
https://ubiquity.api.blockdaemon.com/v2/ethereum/mainnet/tx/send
I would assume litecoin is probably simply:
https://ubiquity.api.blockdaemon.com/v2/litecoin/mainnet/tx/send
But I haven't tried it yet. I should be using the Litecoin endpoint soon. I am currently able to send XRP, ETH/ERC20 Tokens and BTC. I am now trying to finish off LTC and then the last one: BCH.
Check out XRP as it is much easier to work with. Receiving, sending, you name it. It should be the first coin anyone is introduced to, IMO, because it is so simple and fast.
I send this request https://maps.googleapis.com/maps/api/geocode/json?components=country:SE|locality:Huddinge|postal_code:14158&address=Sm%C3%A5brukets+Backe+30%2C+14158+Huddinge but I got zero result.
If I removed "postal_code:14158" it will work but It won't return the right postal code.
I got the same result for many valid addresses.
The Google Geocoding API is designed to help people create maps. Google doesn't do address verification or validation.
Geocoding is the process of converting addresses (like a street address) into geographic coordinates (like latitude and longitude), which you can use to place markers on a map, or position the map. (Google Geocoding API Getting Started)
In your case, it is best to simplify your search terms (drop the postal code, since that seems to work). You will still get fairly accurate results for placing markers on maps.
Also, you could report the information problem to Google Maps. They are responsive: they might update the service so the search returns something valid for your address search term.
If you need exact addresses or you need the postal code in all cases, try an address validation service, such as SmartyStreets. Here is a demo.
Full disclosure: I worked for SmartyStreets.
Good Afternoon,
I have exhausted my googling and best-guess ideas, so I hope someone here has an idea of whether this is possible or not.
I am using Exchange Server 2010 (vanilla) in a test environment and trying to create a Hub Transport Rule using the Exchange Management Console. The requirements of the rules filtering are similar to the following scenario:
1.) If a recipient's address matches (ends with) "#testdomain.com" AND (begins with) "john"
2.) If the sender's address matches (ends with) "#testdomain.com"
3.) Copy the message to the "SupervisorOfJohns#testdomain.com" mailbox
I have no problems doing items 2 and 3, but I cannot figure out how to get item 1 in the same condition. I have come across some threads that simply concluded that MS goofed on this, but I am hesitant to fault them for something which seems like it should be really straightforward. I must be missing something. Expressions I have tried so far...:
1.) (^john)(#testdomain.com$)
2.) ^(john)(#testdomain.com)$
3.) (^john)#testdomain.com
4.) ^john #testdomain.com$
5.) ^(john)#testdomain.com
If you use the interface and +Add them as two separate entries, it treats them as an OR clause (if a recipient address begins with "john", OR it ends with "#testdomain.com"). As you can see from my simplistic attempts, I have barely any clue what can/should work in this case. Any suggestions or ideas would be appreciated.
Respectfully,
B. Whitman
Here's what I ended up using:
john\w*#testdomain.com
The reasoning behind the question is that I'm trying to make a service to catch certain e-mails and do some processing with them. I also wanted to restrict the senders/recipients to certain domains (though some checking will also be done with the processing service). Thanks to hjpotter92 for his solutions!
Some programs like ProcessExplorer are able to read strings in memory (for example, my error message written in the code could be displayed easily, even though it is compiled already).
Imagine if I have a password string "123456" allocated sequentially in memory. What if hackers are able to get hold of the password typed by the user? Is there anyway to prevent strings from being seen so clearly?
Oh yes, also, if I hash the password and sent it from client to server to compare the stored database hash value, won't the hacker be able to store the same hash and replay it to gain access to the user account? Is there anyway to prevent replaying?
Thank You!
I believe you are confusing two things. The strings ProcessExplorer is finding are also able to be found by the "strings" command in Unix. It just dumps all the stored strings in an executable not the current memory.
Unless you compiled a User password into your program, the memory allocated to store the data shouldn't be read by ProcessExplorer.
There are numerous issues that can occur. Your best bet is to ensure that no other code can run within your process space. Since the days of virtual memory, each process gets its own virtual memory space, ideally preventing any other program from accessing and messing with the memory of other programs. There are ways to detect if your program is being debugged.
You also need to ensure that the memory you are using to store the password is never written to disk or paged out. This web site can point you in the right direction. https://www.securecoding.cert.org/confluence/display/seccode/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+disk
[edit]
I wanted to expand upon my previous post by talking about replay prevention.
If you are truly serious about a complete solution you will need to implement two-way authentication using a PKI system. Your client will have a certificate and so will your server. The client's private key will only be able to unlocked with a password the user will enter. This will allow the server to verify the the client is who he says he is. The client will then verify the server is who he says he is the same way as the client.
By using this system you prevent someone from possing as a server and attempting to get you to send it your password.
This is a topic I can't cover too well on this web site. You will need to research Certificate Authorities and PKI.
Your vulnerabilities are then:
1. Peaking into current memory to extract the password
2. Social engineering
Reference: http://en.wikipedia.org/wiki/Public_key_infrastructure
Andrew's answer gives you good hints for protection of in-memory strings. Regarding replaying - you're certainly right that if someone else intercepts the hashed password, they can replay it and compromise security. The way to defeat that is challenge-response authentication: http://en.wikipedia.org/wiki/Challenge-response_authentication
Do not store plain passwords in the memory (you can XOR them at least). And read Introduction Into Windows Anti-Debugging
I don't know how is it usually done, but if it's critical for you, you may extend whatever string class you use to store your string at least primitively encrypted and to overwrite it with zeroes or with random data upon destruction/reassignment.