Pr/1021Update HIP-1021 #1 (#1094)

Signed-off-by: Michael Kantor <[email protected]>
Signed-off-by: Michael Garber <[email protected]>
Signed-off-by: Ty <[email protected]>
Co-authored-by: Michael Kantor <[email protected]>
Co-authored-by: Michael Garber <[email protected]>

HIP/hip-1021.md

@@ -11,15 +11,14 @@ created: 2024-08-01
 requested-by: TierBot
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/1021
 needs-council-approval: Yes
-updated: 2024-12-04
+updated: 2024-01-08
 ---
 
 ## Abstract
 
 This HIP proposes a modification to the Hedera Consensus Service (HCS) to:
- - Enable setting the `autoRenewAccountId` to the account creating a `TopicCreateTransaction` when an Admin Key is not present during Topic Creation.
- - It ensures that for all existing topics with only a Submit Key and no `autoRenewAccountId`, the original `payer_account_id` of the topic is retroactively set as the `autoRenewAccountId`.
- - Automatically set the `autoRenewAccountId` to the `payer_account_id` of the Topic Id to prevent unintended user error.
+ - Enable setting the `autoRenewAccountId` when creating a `TopicCreateTransaction` even if an Admin Key is not present during Topic Creation.
+
 
 ## Motivation
 
@@ -28,41 +27,39 @@ Currently, when a Topic ID is created, the `autoRenewAccountId` is not automatic
 - It is only possible to set this field when an Admin Key is generated with the Topic. For topics that are created with the intention of being more "immutable," this is a risk.
 - Up until HIP-874 (https://github.com/hashgraph/hedera-improvement-proposal/pull/883/files), it was not easy to verify if a Topic was successfully created with an Autorenew Account Id, leading to more unexpected errors for users.
 
-This proposal seeks to simplify the process for users by making the auto-renewal mechanism seamless, eliminating the need for manual setting of the `autoRenewAccountId`. This change will reduce the potential for errors and ensure that topics are automatically renewed by the account responsible for their creation. Moreover, this proposal aims to provide backward compatibility by setting the `autoRenewAccountId` for previously created topics to the `payer_account_id` of those topics.
+This proposal seeks to simplify the process for users by making the auto-renewal mechanism seamless, eliminating the need for Admin Keys to be present when setting the `autoRenewAccountId`. 
 
 ## Rationale
 
-The proposed change simplifies user interactions with HCS and ensures consistency in managing topic renewals. Automatically associating the `autoRenewAccountId` with the topic `payer_account_id` account reduces complexity and the risk of unexpected topic expirations due to missing auto-renewal settings. For existing topics, retroactively setting the `autoRenewAccountId` to the `payer_account_id` ensures a uniform approach to topic management, especially when rent is enabled. At present, due to the inability to set an `autoRenewAccountId` on Topics without a Submit Key.
+The proposed change enables expected user interactions with HCS and ensures consistency in managing topic renewals. 
 
 ## Specification
 
-### Automatic Setting of autoRenewAccountId
+### Automatic Setting of autoRenewAccountId in SDKs
 
-When a new Topic ID is created, the `autoRenewAccountId` shall be automatically set to the account ID that creates the transaction, providing additional flexibility for when an Admin Key is not set.
+When a new Topic ID is created, the `autoRenewAccountId` shall be automatically set in the SDKs to the account ID that creates the transaction, providing additional flexibility for when an Admin Key is not set.
 
 ### Backwards Compatibility
 
-For all topics created before this proposal is implemented, the `autoRenewAccountId` shall be set to the original `payer_account_id` of the topic. This change shall be applied if and when rent is enabled for these topics.
-This retroactive setting shall not require any action from the original topic creators and shall be handled by the Hedera network.
+This feature has no issues with backwards compatibility.
 
 ### Transaction Changes
 
-The current implementation allows for the `autoRenewAccountId` to be specified during topic creation only when an Admin Key is present. This proposal does not remove this capability but adds an automatic default to the transaction creator's account if not explicitly set, and the capability to set an `autoRenewAccountId` when only the Submit Key is present during creation.
+The current implementation allows for the `autoRenewAccountId` to be specified during topic creation only when an Admin Key is present. This proposal does not remove this capability, but in the SDKs, adds an automatic default to the transaction creator's account if not explicitly set, and the capability to set an `autoRenewAccountId` even when Admin Key is not present during creation.
 
 ## Backwards Compatibility
 
-This proposal ensures backwards compatibility by defaulting the `autoRenewAccountId` to the original `payer_account_id` for all existing topics. This approach preserves the integrity of previously created topics and aligns future topic renewals with their original creators.
+This feature has no issues with backwards compatibility.
 
 ## Implementation
 
-The Hedera node software will be updated to support automatic assignment of the `autoRenewAccountId` during the topic creation process.
-A migration process will be implemented to update the `autoRenewAccountId` for all existing topics to their the `payer_account_id`.
+The Hedera node software will be updated to support assignment of the `autoRenewAccountId` during the topic creation process even if an Admin Key is not present.
 
 ## Drawbacks
 
-The primary drawback is the automatic nature of this feature, which may limit flexibility for users who wish to set a different `autoRenewAccountId`. However, this drawback is mitigated by allowing users to change the `autoRenewAccountId` post-creation if necessary.
+There should be no drawbacks to this approach. Only furture topic ids will be allowed to set `autoRenewAccountId` without needing to also set the Admin Key. 
 
 ## Alternatives
 
 - **Future Rent Logic Adjustments:** If rent is enabled for TopicId Entities and a Topic Id was created before this HIP, rent would be charged to the `payer_account_id` of the Topic Id when an Autorenew Account Id was not present.
-- **No Retroactive Changes:** Implement the automatic setting of `autoRenewAccountId` only for new topics without making retroactive changes. This alternative would lead to inconsistent handling of auto-renewal across topics.
+