Accounts management feature

[rantan]

Is this feature is in scope of this gem?

To integrate Tapyrus contracts into Ruby on Rails applications, it is useful that the gem should support the accounts management feature.

Kind of target applications

It has a feature that the applications manage user's coins in custody.

Features

• Account management according to BIP-44.
• Manage caches for the balance of each coin.
• Update the caches on 0-confirmation.
• Recover the cache if transactions would be rejected by block creation.

[azuchi]

• Account management according to BIP-44.

Tapyrus::Wallet::MasterKey can be used to derive a BIP44 compliant key, but is it different from that?

• Manage caches for the balance of each coin.
• Update the caches on 0-confirmation.

I think there are two ways to achieve this.

• If you use the Tapyrus Core wallet feature, you can delegate its management to Tapyrus Core like existing Timestamp.
• If you want to create your own wallet(node).

It is useful to be able to switch which one to use. But implementing the process of monitoring the blockchain and updating the data as needed in Ruby may have a lot of overhead.

• Recover the cache if transactions would be rejected by block creation.

What is this rejection behavior?

[rantan]

• Account management according to BIP-44.

Tapyrus::Wallet::MasterKey can be used to derive a BIP44 compliant key, but is it different from that?

This account management means that how to link BIP-44 and the balance caches. So, I think that this feature will use Tapyrus::Wallet::MasterKey.

[azuchi]

There are also protocols that introduce account management called easypaysy, like Ethereum, although the meaning is a bit different.

https://www.easypaysy.org/assets/easypaysy_white_paper.pdf

[rantan]

• Manage caches for the balance of each coin.
• Update the caches on 0-confirmation.

I think there are two ways to achieve this.

• If you use the Tapyrus Core wallet feature, you can delegate its management to Tapyrus Core like existing Timestamp.

This way can accept 0-confmation?

[azuchi]

This way can accept 0-confmation?

sure. If you call listunspent 0, it returns list of utxo including 0 confirmation.

[rantan]

• Recover the cache if transactions would be rejected by block creation.

What is this rejection behavior?

I don't have a concrete case. We don't need to consider rejection behavior?

[azuchi]

I don't have a concrete case. We don't need to consider rejection behavior?

Specific behaviors need to be defined in order to be considered. If not included in the block to spare block space, then maybe Signer is censoring your tx or the fees are too low. If it's the latter, you can bump the fees with CPFP.

[rantan]

I don't have a concrete case. We don't need to consider rejection behavior?

Specific behaviors need to be defined in order to be considered. If not included in the block to spare block space, then maybe Signer is censoring your tx or the fees are too low. If it's the latter, you can bump the fees with CPFP.

I agree with this. We need to consider what kind of rejection behavior exists and how to treat each case if we support this feature.

[rantan]

It is useful to be able to switch which one to use. But implementing the process of monitoring the blockchain and updating the data as needed in Ruby may have a lot of overhead.

Yes, balance caching leads overhead for the updating. But I guessed that the cache is effective for getting balances.

However, Using Tapyrus core wallet feature as a backend of Rails application might be ok if it has enough throughput. I want to know something benchmark results. Also, scale-out strategy should be considered.

[azuchi]

However, Using Tapyrus core wallet feature as a backend of Rails application might be ok if it has enough throughput. I want to know something benchmark results.

Tapyrus Core doesn't have a address index, so I think it's faster to use electrs-tapyrus.

[rantan]

Does electrs-tapyrus support 0-confimation tx?

[azuchi]

Does electrs-tapyrus support 0-confimation tx?

I don't know it, please check it.

[rantan]

electrs-tapryus can return unconfirmed balance in blockchain.scripthash.get_balance RPC.

The document is here

[rantan]

I want an RPC method that can be got multiple addresses and returns the sum of each address balance. Existence RPC method blockchain.scripthash.get_balance can take only one address.

I found an issue about this in original electrs repository here https://github.com/romanz/electrs/issues/73

I created a issue in electrs-tapyrus repo https://github.com/chaintope/electrs-tapyrus/issues/14

[rantan]

@azuchi @Yamaguchi I created an IF and class design proposal as issue #7. I would appreciate if you read it and leave some comments.

[rantan]

7 is closed and the Account concept that is proposed in this issue is going to be taken in #14 as Glueby::Wallet.