UpdateAccountPermission: default active permission grants disabled ContractType 51

[Federico2014]

Description

In the interactive updateaccountpermission flow, when an account has no existing active permission, wallet-cli applies a hardcoded default active-permission operations bitmap. That bitmap grants ContractType 51 (ShieldedTransferContract). Since shielded transfer is disabled by default on mainnet and most networks, the node rejects the whole transaction during validation with:

CONTRACT_VALIDATE_ERROR, Contract validate error : 51 isn't a validate ContractType
UpdateAccountPermission  failed !!!

Steps to Reproduce

1. Run interactive updateaccountpermission on an account that has no active permission.
2. Edit only the owner_permission (e.g. add an authorized key); leave active untouched.
3. Preview, confirm, sign, and broadcast.
4. The node returns 51 isn't a validate ContractType and the transaction fails.

Root Cause

The hardcoded default operations bitmap in src/main/java/org/tron/core/manager/UpdateAccountPermissionInteractive.java:108:

active.setOperations("7fff1fc0033efb0f000000000000000000000000000000000000000000000000");

Decoding this bitmap, the granted operations include bit 51:

[0,1,2,3,4,5,6,8,9,10,11,12,13,14,15,16,17,18,19,20,30,31,32,33,
 41,42,43,44,45,48,49, 51, 52,53,54,55,56,57,58,59]
                       ^^ ContractType 51 = ShieldedTransferContract

Byte index 6 is 0xfb (binary 1111 1011), whose bit 3 maps to operation 51. Shielded transfer is disabled by default, so when the node iterates the operations bitmap and hits the unavailable ContractType 51, it rejects the transaction.

Why the bit is invisible in the UI

operationsMap (the human-readable label table at lines 50–88 of the same file) jumps from 49 straight to 52 — there is no label for 51. Both the preview and the add/delete menus filter entries with operationsMap.get(...) != null. As a result:

• Bit 51 is actually present in the bitmap sent to the node,
• but it is silently hidden from the preview and the edit menu,
• so the user can neither see it nor remove it through the interactive UI.

This is the most subtle part of the bug and makes it very hard to self-diagnose.

Suggested Fix

1. Correct the default bitmap to clear bit 51: byte index 6 0xfb -> 0xf3, i.e.
   7fff1fc0033efb0f... -> 7fff1fc0033ef30f...
   (keeps 48, 49, 52, 53, 54, 55; only removes 51).
2. (Optional but recommended) Validate/sanitize every set bit in the default bitmap so this class of "present in the bitmap but missing from operationsMap, hence invisible and undeletable in the UI" hidden bit cannot recur; or explicitly surface such unknown operations in the UI instead of silently filtering them out.

Environment

• Affected command: interactive updateaccountpermission
• Affected file: src/main/java/org/tron/core/manager/UpdateAccountPermissionInteractive.java:108

[gummy789j]

Hi @Federico2014, thanks for the detailed report and contribution.

We have confirmed that this issue is reproducible: the interactive updateaccountpermission flow can create a default active permission whose operations bitmap includes disabled ContractType 51 (ShieldedTransferContract), and that bit is not visible/removable in the current interactive output.

Could you please update PR #935 to merge into release_v4.9.7 instead of release_v4.9.6?

We will continue on top of your PR and add the remaining pieces there, including clearer wording for unlisted/unknown operations and regression coverage for the default bitmap. After that, the fix will be included with the v4.9.7 release.

Thanks again for helping track this down.

[Federico2014]

Hi @gummy789j, thanks for the quick confirmation!

I've updated PR #935 to target release_v4.9.7 as requested. It's now rebased onto release_v4.9.7 and is back to a single clean commit touching only UpdateAccountPermissionInteractive.java:

• clears bit 51 (ShieldedTransferContract) from the default active-permission bitmap (0xfb → 0xf3), and
• renders operations that are absent from operationsMap with a visible placeholder so unlisted/unknown ops are no longer silently hidden or undeletable in the interactive UI.