There is a significant issue in the SDK related to single-use addresses: it only allows generating 20 addresses, and after that it starts returning an error.
To get a new batch of single-use addresses, you have to send any transaction to any address, after which the SDK unlocks the next block of 20 addresses.
Yes, but in the case where true single-use addresses are required, the SDK needs to allow generating an unlimitednumber of them.
Reusing an address is effectively equivalent to deanonymization, especially when that address is later used as a refund address in the application.
The whole point of single-use addresses is to avoid linkage, so the gap limit becomes a real limitation in privacy-sensitive use cases.
There’s a privacy vs safety tradeoff to consider here. If you allow someone to receive money at address 21, but they never receive funds at addresses 0-20, future wallets will not be able to recover ANY of their coins. They gain privacy, but lose safety.
Developers can always use the lower level address derivation libraries to build their own wallet derivation+scanning logic, but I think its wise for the SDK to only promote the standard BIP-44 behavior.