-
Notifications
You must be signed in to change notification settings - Fork 300
Description
<---
BitGo Tron SDK has support for freeze, unfreeze transactions. Freeze transactions need to specify the type of resource that the user should get back in return -- this currently works when the resource type is set as ENERGY, but if the resource type is set as BANDWIDTH, it results in signature verification error at the full node
-->
Expected Behavior
Irrespective of whether the resource type is ENERGY/BANDWIDTH, freeze transactions should be signed and broadcasted successfuly
Current Behavior
we initiated a freeze txn with BANDWIDTH in staging, transaction hash: e3152cab62ecb0eaa67d27dc972acfabd6e4e63733faeaa5f58fc6ae33291a6
transaction was stuck in signed for 15 mins and we saw the following error in the full node:
07:02:27.423 WARN [qtp1529856704-125] [o.t.c.Wallet](Wallet.java:570) Broadcast transaction 5db533fa9846e99c6d1b84a69d1d5270448357ce8e27ca35da8af1f9d79563f3 failed, a7f52fa69e4aea54feaac66d33dc878d03716ec166c634bcb453344fe309a496f3f0bb0ed4bd50dcff46a93821583177cead7879d086adcaea239163bfe760d600 is signed by TWUdix7WKTUovisj8SwZSwc1MmoqSQxgDa but it is not contained of permission..
strangely, the transaction that is shown by the full node is not the same one as the we're broadcasting although the error does match. This potentially points to an issue with generating the signed hex/regenerating the transaction hash before broadcast
Possible Solution
<>
Steps to Reproduce
- Use the BitGo SDK to create a freeze transaction with resource type specified as BANDWIDTH. Once signed, the transaction when broadcasted will be stuck in signed and will not confirm on chain as the node will be rejecting it with the error shared above