A better name than getOffChainLocks / getOnChainLocks

[homura]

As an HD wallet extension, Nexus uses a key derivation strategy similar to BIP-44 for keys with full ownership. By monitoring whether a certain public key has a transaction record on the chain, the next set of gap (default 20) locks are derived and provided to dApps for assembling transactions.

Initially, we named these two APIs getUnusedLocks and getUsedLocks. However, we realized that this API was not entirely accurate. A dApp might obtain a lock through getUnusedLocks, but that lock might only be used to generate a lock hash for simulating P2SH, such as the 0xFC authentication used by Omnilock. In this case, we have used the lock semantically, but the lock would not appear on the chain. Therefore, it would still appear in the results of getUnusedLocks. As a result, we changed the names to getOnChainLocks and getOffChainLocks. While these RPC method names are more practical, they may not be easy to understand. dApp developers may need to have a good understanding of the background to know which RPC to use in this situation.

Therefore, I opened an issue to discuss whether there are more appropriate names for these two RPC methods. One suggestion we received was getRevealedLocks and getUnrevealedLocks, which is clearer than OnChain and OffChain, but still requires dApp developers to be familiar with the relevant background.

@janx @zhangyouxin @zhb666 @IronLu233

[zhangyouxin]

How about getActiveLocks/getInActiveLocks?

The word "Active" could be easily linked to "have some relevant transactions on the blockchain", I think it's comprehensive.

[homura]

Hmm, it sounds similar to revealed / unrevealed, which doesn't feel easy to understand for a dApp developer

[janx]

I think getUnusedLocks and getUsedLocks is good even for usecases like 0xFC authentication (delegate authentication to another lock script), because keys/locks used for this purpose is literally "used", it's just not observable on chain.

In other words, the name 'used' / 'unused' is ok. It's the previous definition of 'used' / 'unused' - whether it's observable on chain - inappropriate.

[homura]

A lock that is not observed will be treated as "unused" whether the lock has been delegated, does this mean the API is not "honest"?