tronprotocol/java-tron

Expiration set in future returns "TRANSACTION_EXPIRATION_ERROR"

Closed this issue · 3 comments

khelle commented

1. What did you do?

I have working and fully synced TRON fullnode v3.6.6. I am trying to broadcast signed transaction with expiration time without succes. I am sending following frame to /wallet/broadcasttransaction:

{
    "signature": [
        "SIGNATURE"
    ],
    "txID": "ca9b39f0e2b2b5cd2eadf9b10d2eece67e3a545dbd3de536decdb1e314a4bea7",
    "raw_data": {
        "contract": [
            {
                "parameter": {
                    "value": {
                        "amount": 1,
                        "owner_address": "414489535b0f81d50be992978e151c94c91e19e62d",
                        "to_address": "41987312591121370163986fef8a4a4bd38de4fe96"
                    },
                    "type_url": "type.googleapis.com/protocol.TransferContract"
                },
                "type": "TransferContract"
            }
        ],
        "ref_block_bytes": "77c9",
        "ref_block_hash": "73da99e3744c1f92",
        "expiration": 1580406376000,
        "timestamp": 1579106317930
    }
}

The expiration is set to 30th Jan 2020 which is few days from now. I changed the signature to "SIGNATURE" in the copy here.

2. What did you expect to see?

I expected to get in return tuple indicating success

3. What did you see instead?

Instead I received:

{"code": "TRANSACTION_EXPIRATION_ERROR","message": "7472616e73616374696f6e2065787069726564"}

Message means: "transaction expired"

4. Additional Info

Transaction which I posted here has been constructed in following way:

  1. I called /wallet/createtransaction with:
{
    "to_address": "41987312591121370163986fef8a4a4bd38de4fe96",
    "owner_address": "414489535b0f81d50be992978e151c94c91e19e62d",
    "amount": 1
}

  1. Then I got txID and raw_data from returned tuple and switched raw_data.expiration to the expiration I am interested in - ex: "1580406376000". After this change I recreated transaction (with new TxID) with a call to /wallet/getsignweight and following body:

  2. From the returned tuple I got the new txID and raw_data from transaction.transaction. Then I used that newly generated raw data and signed it with /wallet/gettransactionsign:

{
   "transaction": {
    "txID": "ca9b39f0e2b2b5cd2eadf9b10d2eece67e3a545dbd3de536decdb1e314a4bea7",
    "raw_data": {
        "contract": [
            {
                "parameter": {
                    "value": {
                        "amount": 1,
                        "owner_address": "414489535b0f81d50be992978e151c94c91e19e62d",
                        "to_address": "41987312591121370163986fef8a4a4bd38de4fe96"
                    },
                    "type_url": "type.googleapis.com/protocol.TransferContract"
                },
                "type": "TransferContract"
            }
        ],
        "ref_block_bytes": "77c9",
        "ref_block_hash": "73da99e3744c1f92",
        "expiration": 1580406376000,
        "timestamp": 1579106317930
    }
   },
   "privateKey": "ownerAddressPrivateKey"
}

After signing I sent requrest to /wallet/broadcasttransaction and encountered expiration error.

I tried looking for some clues both on GH in the issues and on google but did not see any similar problem.

andelf commented

The expired word may be misleading. The expiration must within a day.

FYI:

  public static final long MAXIMUM_TIME_UNTIL_EXPIRATION = 24 * 60 * 60 * 1_000L; //one day


if (transactionExpiration <= headBlockTime
        || transactionExpiration > headBlockTime + Constant.MAXIMUM_TIME_UNTIL_EXPIRATION) {
      throw new TransactionExpirationException
}
khelle commented

Thank you for providing the information necessary for solving the issue. I changed expiration to be less than day away from current timestamp and now it works correctly!

I believe it would be helpful to add information about such constraints to the documentation for future reference.

Closing this for now.

jtomtan commented

Thank you for providing the information necessary for solving the issue. I changed expiration to be less than day away from current timestamp and now it works correctly!

I believe it would be helpful to add information about such constraints to the documentation for future reference.

Closing this for now.

Then how to change the "expiration" value?

  • 👍3