Error code 26. Only 1 node.

Question

I am using Multichain with 1 node and wallet inserting data currently. I get the following error:

error code: -26

error message:

Error: this transaction was rejected. This may be because you are sharing private keys between nodes, and another node has spent the funds used by this transaction.

How can fix this error? I have a lot of data stored so ideally I do not have start a new chain and reinsert data again.

Thanks!

Comments

There are many other reasons why a transaction can be rejected. Please share the process by which you build the transaction.

---

An publish command looks like:
      publish stream_1 '["166725459", "A", "G"]' '{"json":["12947"]}''

This returns:
      {"method":"publish","params":["stream_1",["166725459","A","G",{"json":["12947"]}],"id":"98775126-1684934655","chain_name":"test_chain"}

The error:
      error code: -26
      error message:
      Error: this transaction was rejected. This may be because you are sharing             private keys between nodes, and another node has spent the funds used by this transaction.

I have one address in the chain which inserts everything:
    {
        "address" : "1Uv1L4S8TtcEZfEZNpD8KBPuANSzsmaNRUN8Yj",
        "ismine" : true
    }

This issue only happened after 100,000's of transactions. I dont want to lose the data already stored on the chain. Is there anything I can do?

Answer 1

Usually this happens only if you have "double spending", i.e. two nodes share the same address (this what the error message suggests). There are other reasons, but they are irrelevant for most of the users.

But normally, this failed attempt generates messages in debug.log. If you don't see anything there, you may want to restart multichaind with debug flags:

-debug=mchn -debug=mcapi -debug=wallet

If you are using 2.3.3 you don't even have to restart multichaind, you can set these flags with setruntimeparam API.

Comments

Yes I get errors in the debug.log which look like:

2023-05-24 15:47:15 CommitTransaction() : Error: Transaction not valid:
2023-05-24 15:47:17 CommitTransaction: a19f6e790f7ac633823037a4301f00326c83878e2b446110d5f78254be050084, vin: 1, vout: 2
2023-05-24 15:47:18 CommitTransaction: 89b58f614adfd7408671a65b899b4e79ca7e453820844275c83ba29aa0932573, vin: 1, vout: 2
2023-05-24 15:47:18 CommitTransaction() : Error: Transaction not valid:
2023-05-24 15:47:18 MultiChainMiner: Block Found - 00824aff2dcbeb7ac1fc4e5bed5edf4c931cabcb9792cce3344f3b39800f3860, prev: 00094dba6aa1343b65ef60ce25e3423194f68f2a01efb1e98517ee1a2ca7396a, height: 189997, txs: 2
2023-05-24 15:47:19 UpdateTip:            new best=00824aff2dcbeb7ac1fc4e5bed5edf4c931cabcb9792cce3344f3b39800f3860  height=189997  log2_work=25.535625  tx=17807072  date=2023-05-24 15:47:18 progress=1.000000  cache=0
2023-05-24 15:47:19 ReacceptWalletTransactions: 30 txs in unconfirmed pool
2023-05-24 15:47:19 Tx 0b10ec27fd9f4652657cfc9e749edc391bd1133cf33ae696a19770545d1c5809 was not accepted to mempool, setting INVALID flag
2023-05-24 15:47:19 Tx 40d4807d4a9bfedca3e4a0ef9346e69bfbff6f8e42a854ac3eefd3d5efd1bc64 was not accepted to mempool, setting INVALID flag

Does this help? I am happy to share the full file if needed.

Thanks!

---

Yes, it is expected. Some transactions are not accepted. Full debug.log will not help much unless you find there the row with "Wallet error".

But normally these things happen when one node goes down and recovered from backup. Does something like that happened recently?

Did you make any upgrades? What version of MultiChain you are running?

---

I am using multichain-2.2.0. I can not find a row that says 'wallet error' in the debug file.

I have not restarted any nodes. I have 1 node running and insert all data via 1 wallet. the only thing of note is that i am using multiprocessing to leverage multiple cores during insertion. This may have led to a transaction being submitted at the same time.

Is there a way to restart the node with a new wallet and continue insertion? In fact, anything that lets me restart insertion is ok.

---

* This may have led to a transaction being submitted at the same time.

This should not be a problem if you use only publish API.

1. You can try to restart the node with
-debug=mchn -debug=mcapi -debug=wallet

This will not help, but maybe it will give us more information about the issue.

2. The issue may be the result of some bug we already fixed. You may think about upgrading to the latest version 2.3.3. I don't think it will help in case of the bug, since damage is already done.

3. Starting multichaind 2.3.3 with -reindex should resolve the issue, but it may take some time - you have quite a big chain - 200K blocks, 18M txs. BTW, 2.3.3 should handle large chains better than 2.2.

If you decide to start with -reindex - stop multichaind, back up entire directory and start multichaind with -reindex

BTW, are you using MultiChain Explorer?

---

1. Running the debug gives:
2023-05-24 18:21:54 mcapi: API request failure: {"method":"publish","id":"42806237-1684952514"}, code: -26
2023-05-24 18:21:56 mcapi: API request from 127.0.0.1
2023-05-24 18:21:56 mcapi: API request: {"method":"publish","params":["stream_1",["167463736","T","C"],{"json":["74040","55859","16289"]}],"id":"27313992-1684952516"}
2023-05-24 18:21:56 mchn: Asset Grouping. Assets: 0. Group Size: 1. Group Count: 0. Single-Asset Groups: 0.
2023-05-24 18:21:56 CommitTransaction: b8b7df79ed446451c20a0610ca277f4cb32c87b37478433332d9faefad73a2df, vin: 1, vout: 2
2023-05-24 18:21:56 CommitTransaction:
CTransaction(hash=b8b7df79ed, ver=1, vin.size=1, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(e66bb06345, 1), scriptSig=3044022000923add98e45d6f)
    CTxOut(nValue=0.00000000, scriptPubKey=73706b65952d1d7f33c83195f7cc64)
    CTxOut(nValue=0.00000000, scriptPubKey=OP_DUP OP_HASH160 ce8865f68323)
2023-05-24 18:21:56 Missing tx (e66bb06345e53bffd57a3cae6d0ab9b432dee6fc345944cc8dd82f181950b0bc)
2023-05-24 18:21:56 CommitTransaction() : Error: Transaction not valid:
2023-05-24 18:21:56 mchn: Tx not committed (): 0100000001bcb05019182fd88dcc445934fce6de32b4b90a6dae3c7ad5ff3be54563b06be6010000006a473044022000923add98e45d6fc7da6ecadca36814ce2f0e313c0659280c26a0a6618b5048022011f19a7f43e70e5fe45e7b938e7009c3af4d3f6463c959bf6e76858c1e877a7301210223135dce5a8679a636f35694bfd4e4dea9af3e10a743d1c54f43df607c042b5effffffff0200000000000000007a1473706b65952d1d7f33c83195f7cc648aaa3c5f69750d73706b6b313637343633373336750573706b6b54750573706b6b43750773706b6b317c30750573706b6b33750873706b6b31323030750773706b6b302e30750573706b6602756a1b5b245323690369053734303430690535353835396905313632383900000000000000001976a914ce8865f683237b47fb3716984d70be46cb67d7cd88ac00000000

Its always caused by this missing tx:
Missing tx (e66bb06345e53bffd57a3cae6d0ab9b432dee6fc345944cc8dd82f181950b0bc)

I am using multichain-2.2.0. I can update to 2.3.3 for future uses. I assume for now -reindex would be too slow unless I can specify reindexing the final block (where this issue is happening).

No I am not using multichain explorer. What is it and how can I use it?

Many thanks Michael!

---

This is MultiChain explorer:

https://github.com/MultiChain/multichain-explorer-2

* Missing tx (e66bb06345e53bffd57a3cae6d0ab9b432dee6fc345944cc8dd82f181950b0bc)

Yes, this is a problem. When you send tx in MultiChain (with publish command) you spend one of the unspent outputs the address has. For some reason (we may never know, maybe because of some bug or something else) one of the outputs is erroneously marked as unspent while it is, in fact, spent by another tx.

To stop using this tx please look at the output of the API

listunspent 0

You will see there all outputs owned by your address 1Uv1L4S8TtcEZfEZNpD8KBPuANSzsmaNRUN8Yj

One (or several) of them probably will belong to the problematic tx e66bb06345e53bffd57a3cae6d0ab9b432dee6fc345944cc8dd82f181950b0bc.

You can disable it using lockunspent API, like this:

lockunspent false '[{"txid":"e66bb06345e53bffd57a3cae6d0ab9b432dee6fc345944cc8dd82f181950b0bc","vout":0}]'

(not sure about "vout":0, should check with listunspent)

After that, this output will not be used by "publish" API, some other output will be taken.

But this solution is not perfect, after restarting multichaind this may happen again. Also, maybe there are some other broken outputs.

The only way to resolve the issue permanently is -reindex.

---

Thanks a lot Michael - this indeed worked!

I will update to 2.3.3 for future use. Is there a way to automate locking unspent txids when an error such as this arises?

---

No, as I said, it is not the way to fix the problem, it is workaround.

Locking mechanism is designed to for other purposes. It locks unspent output for low-level APIs like createrawtransaction and thus disables it for high-level APIs like publish.

The problem is already in the node's database, the only way to fix it is to restart with -reindex.

---

I see. well thanks a lot for your help!