Open LanfordCai opened 3 years ago
Thanks for posting about this, @LanfordCai!
customer might input an invalid address by mistake, in which case, we should remind him/her to do re-check. For example, 1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM8 is a valid address but 1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM9 is not.
We perform this sort of logic check prior to invoking Rosetta but I see the appeal in having it integrated directly into the implementation. I think the responsibility to do this sort of rejection should fall on the implementation. Maybe the best way to enforce this would be to add some testing to rosetta-cli
to purposely create txs with invalid addresses?
customer might input an address in the format which we don't support yet or are not ready to open to customers. For example, for Bitcoin, we support the withdrawal to P2PKH and P2SH address , but we don't support the withdrawal to P2WPKH and P2WSH address.
We've been thinking about this problem a lot lately (multiple address formats). Right now, Rosetta doesn't really have a notion of different address types and it is creating some confusion for folks trying to integrate with rosetta-bitcoin
using non Segwit-Bech32 address formats (i.e. how do you specify which address type to create in /construction/derive
). A somewhat related question folks have is how to get all available SubAccountIdentifiers
for a particular `AccountIdentifier.
I am wondering if Rosetta can add one more API, like /account/info:
Do you envision this being offline
or online
? I could see an appeal in also returning "nonce-like" info in this sort of response.
Hi, thank you for your response, @patrick-ogrady !
We perform this sort of logic check prior to invoking Rosetta but I see the appeal in having it integrated directly into the implementation. I think the responsibility to do this sort of rejection should fall on the implementation. Maybe the best way to enforce this would be to add some testing to rosetta-cli to purposely create txs with invalid addresses?
In our exchange, basically three steps are involved in the withdrawal process:
It would be better if step 1 can also be done by calling a specific Rosetta API. I think with Rosetta, we don't need to know lots of technical details about the blockchain, including how to validate an address(which requires knowledge about the address generation process). It is indeed acceptable to return ‘error’ when creating a transaction with invalid address, but it would be better if we can reject the invalidate address before creating the transaction.
We've been thinking about this problem a lot lately (multiple address formats). Right now, Rosetta doesn't really have a notion of different address types and it is creating some confusion for folks trying to integrate with rosetta-bitcoin using non Segwit-Bech32 address formats (i.e. how do you specify which address type to create in /construction/derive). A somewhat related question folks have is how to get all available SubAccountIdentifiers for a particular `AccountIdentifier.
It would be great if we can specify address types when deriving an address and getting the type information in AccountIdentifier
of an address.
Do you envision this being offline or online? I could see an appeal in also returning "nonce-like" info in this sort of response.
For format validation, offline
is enough. We can add type
field or format
field to AccountIdentifier
. Unlike nonce, the format of an address is unchangeable, so it's improper to put it into metadata
I think.
But if we take a further step, some information about an address is only available in online
mode. Ethereum addresses are checksumed hex, but it might be an EOA or smart contract, similarly, addresses of EOS like blockchains might be an registered account without/with code deployed. Those info can only be accessed by querying the blockchain and all of these information can be put into metadata
field, depending on the implementation. The AccountIdentifier
may look like these:
EOS Premium Account:
{
"account_identifier": {
"address": "b1",
"type": "Premium"
"metadata": {
"registered": true
}
}
}
EOS Normal Account:
{
"account_identifier": {
"address": "huobideposit",
"type": "Normal"
"metadata": {
"registered": true
}
}
}
BCH Address:
{
"account_identifier": {
"address": "1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM8",
"type": "P2PKH",
"metadata" {
"cash_addr": "bitcoincash:qzlexs6dcr4qpc7u5pn36pz8luavhx2qjqy4pny7gp"
}
}
}
Thanks for providing this additional context, @LanfordCai. I'd recommend you chime in on a thread about a different use for /account/info
. I think we could probably merge these workstreams:
I'm working for an exchange and have integrated a blockchain by using Rosetta. This project is really amazing and is well compatible with our current blockchain integration process. But there is a feature I want to request.
Is your feature request related to a problem? Please describe.
We will check the address that the customer input in the withdrawal process:
1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM8
is a valid address but1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM9
is not.For the blockchain we have integrated via Rosetta, I used
/account/balance
to check if the address is valid or not; For invalid address, it would returninvalid account name
. But I think it's just a workaround, and is not working for the case 2 above.Describe the solution you'd like
I am wondering if Rosetta can add one more API, like
/account/info
:The
type
field is not in themetadata
for it's not optional.