The full math you have to do is: D = P - Hs(8aR || i)G, where i is a varint representing the index of the output. You then check whether D matches your main public spend key or any of your subaddress public spend keys. if it does, the output is destined for you. The output public key P is in the json as vout.target.key. The transaction public key R is not ...


It greatly speeds up scanning of newer blocks that use bulletproofs. It does not speed up the scanning of the existing blocks if you're refreshing your wallet from scratch.


First, I'd suggest thinking harder about your design choice of holding users private keys. If you're going to have full custody of users wallets, it begs the question why have per-user wallets in the first place. It's your wallet if you hold the keys, so you could just just assign accounts/subaddress to customers for example. Second, if you're going to ...


Last I was aware, Poloniex issues users with a Monero integrated address, which embeds a payment ID in the address. You can easily verify this by the address length - integrated addresses are 106 hex digits long. As the Monero community has already signalled that payment IDs are being deprecated, subaddresses should be used instead moving forwards.


Both Cake and Monerujo wallets use the normal c++ simplewallet implementation. That means that all your keys for scanning and spending never leave your device. Thats also true for the view key which is needed to identify transactions that where send to your wallet. Because of that the scanning is done on your wallet. Your device gets all blockheaders and a ...

Only top voted, non community-wiki answers of a minimum length are eligible