query the status of a erc20 withdrawal address registration through the explorer

[robvanmieghem]

The mobile wallet should be able to query the status of a withdrawal address registration:

• unregistered
• unconfirmed ( in tx pool)
• confirming ( less than 6 blocks deep)
• confirmed

[GlenDC]

I think going for such a specific status report is too app-specific and high level. However, it is easy enough to define such a status on an App level with the current /explorer/hashes/:hash endpoint. Where you would give the ERC20 address as the ":hash". You'll get returned the ExplorerHashGET structure (an extended version of the Rivine version you're used too):

// ExplorerHashGET wraps around the default rivine ExplorerHashGET type,
// as to add the optional ERC20 address to it, for UnlockHash requests,
// which have an ERC20 address attached to it.
type ExplorerHashGET struct {
    rapi.ExplorerHashGET
    ERC20Info *ExplorerHashERC20Info `json:"erc20info,omitempty"`
}

// ExplorerHashERC20Info contains all ERC20 related info as part of an UnlockHash-typed ExplorerHashGET request.
type ExplorerHashERC20Info struct {
    TFTAddress   rtypes.UnlockHash  `json:"tftaddress,omitempty"`
    ERC20Address types.ERC20Address `json:"erc20address,omitempty"`
}

If your request succeeds with a 200 OK you know it is either in confirming or confirmed. ~Differentiating between these 2 statuses can be done by looking for the transaction with the AddressRegistration Version and using the height of that one to compare it to the current height.~ (nvm, seems like the Address Registration is only returned if that linked TFT address is used in one of the coin inputs or refund coin output, which seems unlikely if you use a separate address for TFT address, I suppose if the App uses the first address also to link that one to the TFT20 address, than it will appear in there. This linking of unlock hashes to transactions is Rivine-logic, and it only checks so currently for coin/block inputs/outputs. If you want I could add functionality to allow transaction types to also define if it is linked to a certain unlock hash though ⁽¹⁾, up to you).

Currently you wouldn't know if the is unregistered or unconfirmed as these 2 are really the same. Unconfirmed==Unregistered as there is no registration as long as it is not in a block. Only the App for that user will be able to register as it should be the only one with the seed, so it would be weird if it didn't remember it did a call in the last few minutes. Even so, it can try to do the same "TransactionPool POST" call again, and if it is not "unregistered" it will return the github.com/threefoldtech/rivine/modules.ErrDuplicateTransactionSet error.

The unconfirmed status I could support, as it does align with the other unconfirmed functionality we already provide ⁽²⁾. However, the confirming status I vote against, as it is too app-specific, given that the 6 blocks deep is an arbitrary choice, and some might want a higher or lower depth as a limit. And it is easy enough to call it. On top of that, if it wants this confirming/confirmed status differentiation, it is not that it has to check every minute to know if it happened. It already knows that it only needs to start checking around 6*2=12 minutes after it did the successful registration call.

This call will also return the transactions related to the linked TFT address.

[GlenDC]

Let me know @robvanmieghem if you want me to task and do ⁽¹⁾ and/or ⁽²⁾ of the comment above. If there is something else let me know as well. Or if you think if it is fine as it is today, feel free to close the issue in that case.

[robvanmieghem]

Even so, it can try to do the same "TransactionPool POST" call again, and if it is not "unregistered" it will return the github.com/threefoldtech/rivine/modules.ErrDuplicateTransactionSet error

Only if the same inputs are used I guess

[GlenDC]

Only if the same inputs are used I guess

Yes, that is true. Otherwise it might succeed if not yet in a block but only in a transaction pool (due to the fact that we don't handle inner-block relationships for non standard transactions well yet). If it is in a block it will fail with an error.

[GlenDC]

Knowing all this, how do you want to handle this issue @robvanmieghem?

[GlenDC]

Added follow up issues:

• [x] ⁽¹⁾ ensure explorer links transactions related to extension-referenced addresses (#254)
  • once this is finished, I can also add confirmation counter
• [x] ⁽²⁾ ensure explorer can pick up unconfirmed ERC20 Address Registration by relying on the txpool (#255)
  • we can identify an unconfirmed transaction using a confirmation counter of 0

[GlenDC]

Closing this issue, as resolved by follow-up issues.

Apps can now compute such a status very easily by looking up the ERC20 address using the regular /explorer/hashes/:hash endpoint:

• If an error is and/or no reply is returned, than the ERC20 can be seen as unregistered;
• If a reply is returned than the confirmations child property from the erc20info root property has to be checked:
  • if it is 0, than the status can be seen as unconfirmed (still in Tx pool)
  • Otherwise the value is >=1:
    • 1 being just created, and thus the highest block is the block in which the address is created
    • Should the App want, it can thus define a more refined status by checking this confirmations value against an arbitrary value (e.g. 6) to differentiate for example between confirming and confirmed;