Failed to handle tx 1bce7ec651f10f9284b67b6fc3b17d15041b96faa6014fc6adf2fffe5519fb8e

[bun919tw]

Hi there, I had some issues when dealing with a specific Omni transaction.

My Omni node version: v0.8.0 Tx ID: 1bce7ec651f10f9284b67b6fc3b17d15041b96faa6014fc6adf2fffe5519fb8e

I checked the transaction is valid on Bitcoin explorer. FYI, https://blockstream.info/tx/1bce7ec651f10f9284b67b6fc3b17d15041b96faa6014fc6adf2fffe5519fb8e?expand However, when I use Omni RPC omni_gettransaction, I got the error:

error code: -32603
error message:
Generic transaction population failure

I traced the source code, and this error seems like an internal error from Omni core. Therefore, I don't want to just ignore this error whenever I got one.

Also, to my understanding, this Omni transaction is an "invalid" class A Omni transaction since I got these logs from my Omni core.

2020-03-14T04:20:01Z parseTransaction(block=621560, 2020-03-14T03:13:51Z idx= 0); txid: 1bce7ec651f10f9284b67b6fc3b17d15041b96faa6014fc6adf2fffe5519fb8e
2020-03-14T04:20:01Z The Sender: 14zDs2GTQLo1nWcSYTL7uC28UdpPmrMksM : fee= 0.00004000
2020-03-14T04:20:01Z saving address_data #1: 17gQDn51qnMK9w9TWfx3cDV5md365YusvG:OP_DUP OP_HASH160 49445c4c34633d4d9c3cae831361ebcd23ecd50c OP_EQUALVERIFY OP_CHECKSIG
2020-03-14T04:20:01Z saving address_data #2: 14zDs2GTQLo1nWcSYTL7uC28UdpPmrMksM:OP_DUP OP_HASH160 2bbad2fee80d4746f0288a12d95436206ae8ae60 OP_EQUALVERIFY OP_CHECKSIG
2020-03-14T04:20:01Z  address_data.size=2
 script_data.size=2
 value_data.size=2
2020-03-14T04:20:01Z !! sender: 14zDs2GTQLo1nWcSYTL7uC28UdpPmrMksM , receiver: 
2020-03-14T04:20:01Z !! this may be the BTC payment for an offer !!
2020-03-14T04:20:01Z single_pkt: 
2020-03-14T04:20:01Z TXLISTDB Error: Transaction 1bce7ec651f10f9284b67b6fc3b17d15041b96faa6014fc6adf2fffe5519fb8e parsed as a DEx payment but could not locate purchases in txlistdb.

My question is that if this transaction is an invalid Omni transaction but a valid Bitcoin transaction, shouldn't Omni core return MP_TX_IS_NOT_OMNI_PROTOCOL error?

Thanks in advance.

[dexX7]

Hi @bun919tw,

thanks for your report! There is no need to worry:

• This transaction has a marker for Class A transactions (1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P)
• It doesn't have valid Class A payload
• As result, it is checked, whether the transaction may be a payment for an accepted order on the distributed BTC/OMNI exchange
• In this case no corresponding order was found, thus the processing ended here

I do agree though, the logging should be nicer.

[bun919tw]

Hi @dexX7 , Thanks for your response. I noticed that if there is an invalid Class C transaction (the one with data output), Omni core will still return an Omni transaction with "valid" field to be false. Shouldn't it be the same for this case?

[dexX7]

Ha, that's a bit tricky, but ultimately I agree.

Right now the behavior is that a transaction with valid marker and valid payload structure passes the parsing part and is then interpreted and it's effect executed. If the effect can't be executed, e. g. because the sender doesn't have enough balance for a send, then the transaction is structurally valid (and shows up, when using omni_gettransaction), but won't be valid in terms of the protocol rules, which results in the "valid" field to be false.

[bun919tw]

Hi @dexX7 , Thanks for the reply. I understand the behavior now. In this case, I still think Omni node should return either MP_TX_IS_NOT_OMNI_PROTOCOL or a transaction structure with invalid field to be false. In a nutshell, this transaction should be either a non-Omni transaction or an invalid Omni transaction. Internal error will confuse the upper layer. However, I understand the behavior will need to take a lot of effects to change and these cases are relatively rare, so be it.

[bun919tw]

Or Omni node should return a new error which means the transaction is structurally invalid.