Open EAWF opened 4 years ago
Fortunately we have all the tools capable to do this already with the toolbox functions. There could be a version of getBTCAddress that auto-increments to a most-recent unused address.
You mean maintain 2 versions of getBTCAddress? Is it maybe better to incorporate it now? There remains the matter of figuring out how to deal with the 20 address range of the wallets. Maybe an additional field to be regularly updated that indicates the last funded address? Still running it around in my mind. Don't want to include too much program bloat that continuously delays rollout.
You mean maintain 2 versions of getBTCAddress? Is it maybe better to incorporate it now?
No, I mean have a default parameter value set to null and in the function we can check if the value is null then use the Blockstream Esplora API to check, incrementally, the addresses starting from 0, or whatever predefined index, to find an address never used in a transaction before. Usage: getBTCAddress($account);
as compared to choosing an index manually: getBTCAddress($account, $index);
There remains the matter of figuring out how to deal with the 20 address range of the wallets. Maybe an additional field to be regularly updated that indicates the last funded address? Still running it around in my mind. Don't want to include too much program bloat that continuously delays rollout.
Why do we need to deal with the 20 address range of wallets? Not every wallet follows this scheme (ex: Wasabi) and the getBTCBalance function only looks up the balance for an address, not for an extended pubkey.
Additionally, there is no easy way to check a larger gap limit other than increasing it.
use the Blockstream Esplora API to check, incrementally, the addresses starting from 0,
Can't do that...will risk hitting API limits and getting blocked from the server without notice. Only solution for that would be to require a running node on the same server. If that, then we'd change direction and use the node's API to do all the work, Good idea for a fork though.
Why do we need to deal with the 20 address range of wallets?
OK, I understand not dealing with the address range...that's true, we don't care, and short of making this project a plugNplay paywall, I guess the onus is on the user to manage the indexes/addresses used, which then makes this issue moot. Another good idea for a fork
In case we do decide to do the index autoincrementing, this was posted December 2019 on Esplora:
we don't currently limit but we reserve the liberty to in the future, especially if the service is abused
But yeah, probably best to implement that only if you have a node yourself to run a private Esplora server on.
Esplora's statement only addresses current, but I'm willing to bet a buck that it won't take long.
Hold for a future version: