MultiChain Developer Q&A - Recent questions tagged addresses

Single cold node, in-wallet address performance

Mon, 21 Jun 2021 15:55:53 +0000

Hello,

for a University project, we're currently evaluating the possibility of using Multichain as a financial transaction journal engine, with the basic principle of representing each user account as an address in the wallet and using direct RPC calls to read and write information. With this central database approach in mind, we're thinking of running one node only as there's nothing we'd gain from the decentralisation, simply inside our cluster away from the public.

As part of a performance estimation, we tried setting up a chain to the best of our understanding, aiming to optimise as much for performance as possible:

chain-protocol = multichain
chain-description = MultiChain test-10k
root-stream-name = root
root-stream-open = true
chain-is-testnet = false
target-block-time = 2
maximum-block-size = 8388608
maximum-chunk-size = 1048576
maximum-chunk-count = 1024

anyone-can-connect = false
anyone-can-send = true
anyone-can-receive = true
anyone-can-receive-empty = true
anyone-can-create = false
anyone-can-issue = true
anyone-can-mine = false
anyone-can-activate = false
anyone-can-admin = false
support-miner-precheck = true
allow-arbitrary-outputs = false
allow-p2sh-outputs = false
allow-multisig-outputs = false

setup-first-blocks = 3
mining-diversity = 0.0
admin-consensus-upgrade = 0.0
admin-consensus-txfilter = 0.0
admin-consensus-admin = 0.0
admin-consensus-activate = 0.0
admin-consensus-mine = 0.0
admin-consensus-create = 0.0
admin-consensus-issue = 0.0

lock-admin-mine-rounds = 0
mining-requires-peers = true
mine-empty-rounds = 0
mining-turnover = 0.0

initial-block-reward = 0
first-block-reward = -1
reward-halving-interval = 52560000
reward-spendable-delay = 1
minimum-per-output = 0
maximum-per-output = 100000000000000
minimum-offchain-fee = 0
minimum-relay-fee = 0
native-currency-multiple = 100000000

skip-pow-check = true
pow-minimum-bits = 1
target-adjust-freq = -1
allow-min-difficulty-blocks = true

only-accept-std-txs = true
max-std-tx-size = 4194304
max-std-op-returns-count = 32
max-std-op-return-size = 2097152
max-std-op-drops-count = 5
max-std-element-size = 40000

default-network-port = 4771
default-rpc-port = 4770
chain-name = test-10k-fixed
protocol-version = 20012
network-message-start = f9f9cff0
address-pubkeyhash-version = 00330835
address-scripthash-version = 051c4624
private-key-version = 8013627a
address-checksum-value = 906c59f5

genesis-pubkey = 036b0f05c206bb7ac8e6bfd2869f473cf4b4acb0b94195944fe0371a2bfb3157f7
genesis-version = 1
genesis-timestamp = 1618841128
genesis-nbits = 536936447
genesis-nonce = 271
genesis-pubkey-hash = f0b759e6726332558339c7b7a8f6f8721e7927c5
genesis-hash = 00e08d153bf75996cfd758c6d09fd1fca23e7bb836fb47ea59ba15e473f381c5
chain-params-hash = b846252b96d6e3bc24b74eaaaa94163e3fe65584f1d1325992849054dfe07045

We then proceeded to create a total of one million addresses on the chain, using a custom golang script with 10 goroutine workers. This process took about 7 hours. Not stellar, but seeing as it would not be part of a burst phase and only needed for new user signups, it's acceptable.

We then proceeded to issue some different assets for each of the generated addresses using IssueMore (to simulate a user entering the ecosystem and having "paid in" to his account), also using a golang script. This process unfortunately is very slow. Each calls takes about 2 seconds. Since the IssueMore would only be used as a "user is paying in new currency" action, it also should not be that burstable, but 2 seconds on a completely empty chain sounds bad. It also prevents us from creating an equal distribution of currency among the addresses, as it would 2 million seconds per asset.

We have not yet proceeded to test the performance of sending assets between addresses. We were thinking of using SendAssetFrom to send currencies between different addresses - and sending to the burn address in order to simulate a user "cashing out" (with the currency leaving the ecosystem again)

Concrete questions

With the problem and data laid out above, I'd appreciate any feedback, especially regarding:

Is Multichain a sensible choice for a centralised financial transaction database with high throughput?
Are there any steps we can look at to further improve the current performance?
Is there any data available on general scalability of Multichain?

We're happy to supply more information as required and thankful for any further insights.

Kind regards,

Peter

Multichain in-node wallet adresses performance

Fri, 16 Nov 2018 15:00:29 +0000

Hello,

We are currently developing an application in Python (Django) using Multichain to control all the transaction and currency related user information.

The transactions we make are pretty simple: getnewaddress, grant, issuemore, getaddressbalances and sendassetfrom. Everything is working fine, however, we have experienced a serious slow down in the response time when increasing the number of adresses in the chain.

To give some numbers we have developed a set of unit tests with the basic functionality of the application:

Tests completion time without multichain implementation: 80s-100s
Tests completion time with multichain implemented and 1000 adresses in the wallet: 120s-150s
Tests completion time with multichain implemented and 60k adresses in the wallet: 800s-1000s

Note that these are the same tests just varying the amount of adresses in the wallet.

Right now we just have one node with all the addresses. What's the maximum addresses a node can hold without degrading its performance? Is it the same as if the adresses were watch only (no private keys in the node)? What's the right architecture to support massive numbers of addresses?

Thank you very much for your time.

No of addresses in one node

Thu, 23 Mar 2017 13:00:54 +0000

Hi Team,

How many addresses can we create on the same node before the performance will start degrading?

Thanks.

Max number of addresses per node

Mon, 26 Sep 2016 11:14:40 +0000

Hi Multichain Team,

What is the max number of addresses which I can create per node? Can I create lets say 1 million addresses on one node?

Actually I was thinking of a B2C(business to consumer) usecase and thinking if it can be implemented using multichain.

Maximum number of addresses per wallet

Fri, 26 Aug 2016 04:10:57 +0000

Hi,

What is the current maximum number of addresses per wallet?

What can we find the configuration?
Is there a way to modify this value?

Thank you!

Using multiple addresses as wallets

Mon, 13 Jun 2016 13:52:34 +0000

Good day, I'm thinking of a loyalty program run on MultiChain tech and I need to check that I am understanding this correctly. I am running two nodes currently. I have the master node and an additional node. Right now I'm creating assets on the master and creating addresses on the additional. Each address is a wallet right, and there are an unlimited amount of wallets that one could create?

I also need to look at setting up a simple API for wallet transactions (so I don't allow access to the node API) and will connect an ios/android app with its own security key and link an address to this and then this pulls the relevant detail from my simple API and also pushes transactions through.

Right track?

Using new address for every operation

Tue, 29 Sep 2015 17:13:49 +0000

Bitcoin advises to use a new address for every operation. I tried this but I ran into a problem: the newly created address doesn’t inherit permissions from the node (meaning if I granted issue, connect, send, receive permissions to the default address of the node, the newly created address won’t get these permissions automatically) and if the node has no admin right, it cannot grant the required permissions to the newly created address. Do you have any solution for this?