-
Notifications
You must be signed in to change notification settings - Fork 163
Creating an asset in CW gives an error (both numeric and alphabetic) [$70] #730
Comments
I just got this error in mainnet trying to issue more assets for a registered asset name that was not locked at creation. Adding 15 to the bounty. |
I think I know what the problem is. The error code -26 comes from the Bitcoin backend, and it signifies RPC_VERIFY_REJECTED, which is used for RPC_TRANSACTION_REJECTED. The message is also telling us why Bitcoin is rejecting this transaction, because this rejection code (64 or 0x40) means: “the transaction will not be mined or relayed because the rejecting node considers it non-standard—a transaction type or version unknown by the server.” In the attached message, you see which part is invalid. It's the public key script. This bug is not specific to asset creation, other users got the exact same error message when trying to cancel their orders (#734). In Counterwebdeps's file util.bitcore.js, in method CWBitcore.signRawTransaction, the scriptpubkey is loaded from the raw hex data. Counterparty API is probably putting an invalid script in the transaction, which is then broadcast via FailoverAPI, and as each federated node passes the transaction to the Bitcoin backend, it gets rejected as invalid every time, and that's where the error message comes from. Maybe there are some exceptions to this behavior, like a specific version of Bitcoin considering the script valid, this could be an explanation why it sometimes works and sometimes doesn't. If there is a node with Bitcoin version that won't reject the TX, then the FailoverAPI will succeed once, even if all other nodes reject it, and the error message won't appear. There are two possible ways to fix this. A quick patch would be to change this line in CWBitcore.signRawTransaction, where the scriptpubkey is being loaded from the raw transaction:
and instead generate the script in CWBitcore.signRawTransaction from the public key, therefore replacing the invalid script that is being provided by the federated nodes. Is it OK to use this solution? An alternative solution would be to try to fix it at the level of the federated nodes, so that they put a valid script into the unsigned transaction they are returning when multiAPIConsensus calls them, but this would not work until they update to a new version, and testing would be far more difficult. |
I hope this helps debug: https://github.com/CounterpartyXCP/counterparty-lib/pull/777 |
should be fixed with CounterpartyXCP/counterparty-lib@8e3590e |
I was not able to reproduce this on testnet, but on mainnet trying to create any kind of asset (alphabetic,numeric) gives an error:
Seems this is not constant, as a user reported he got an error, then later was able to create the asset, then got the error again when trying to create a second asset.
I wasn't able to create anything on several attempts.
--- Did you help close this issue? Go claim the **[$70 bounty](https://www.bountysource.com/issues/11768270-creating-an-asset-in-cw-gives-an-error-both-numeric-and-alphabetic?utm_campaign=plugin&utm_content=tracker%2F542579&utm_medium=issues&utm_source=github)** on [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F542579&utm_medium=issues&utm_source=github).The text was updated successfully, but these errors were encountered: