HIP-423: Long Term Scheduled Transactions

[statop]

Discussion thread to discuss HIP-423: Long Term Scheduled Transactions

[gregscullard]

@statop do we know what the list of transactions to be supported by scheduled transaction might look like ?

To limit the testing/attack surface, only add the types of transactions the Hedera Council needs and smart contracts require

[statop]

per the hip -

The scheduling.whitelist setting shall be updated to - ConsensusSubmitMessage,CryptoTransfer,TokenMint,TokenBurn,CryptoCreate,CryptoUpdate,FileUpdate,SystemDelete,SystemUndelete,Freeze,ContractCall,ContractCreate,ContractUpdate,ContractDelete

[rhysied]

Probably an unnecessary comment (I've been discussing it with Greg via Discord) but just wanted to add that the ability to schedule a CryptoUpdate would be really useful as it would allow you to roll complex keys (e.g. with multiple separate human signers) without having to have one singular user knowing the new signatures or having to get everyone to sign bytes within the 3 minute valid duration window

[statop]

fyi - this was updated to "Hedera should consider changing" before it was approved. On initial deployment the list of supported txn types will probably remain the same as it is now.

[WbMarker]

Just some thoughts on the throttling algorithm.

Should we increase the likelihood of a transaction completing if the transaction is hit by implementing a retry parameter? This would benefit use cases which require a higher guarantee, eg payments. It also reassures the transactor that the fee isn't wasted.

If transaction fails because of hitting transaction limit

increase retry attempt if retry limit is > 0
if retry attempts < retry limit
then; reattempt x times every y max minutes where the execution time is randomised within y minutes
else
fail transaction

maximum limits of
x = 3
y = 1440 (minutes a day)

[statop]

Scheduled txns won't ever fail due to throttling at execution time (after this hip is implemented). The ScheduleCreate or other schedule management txns would be the only schedule related txns that could fail due to throttling.

[iron4548]

A little late to the party, but I'm quite interested in long-term scheduled transaction for an use case I have in mind.

Let's say I want to set up an account to auto-distribute 1000 HBAR to five different wallets ten years from now (can be a specific date, and does not need to be accurate down to the minute). i.e. A gift to five different people.

However, according to current HIP, it looks like initially the max value will be 2 months in the future. Are there plans to eventually be able to schedule it years into the future? If not, what alternatives do I have? Smart contracts?

[statop]

Since this is not deployed yet we actually cannot commit to any value. 2 months was only a suggestion. When this goes live we will update the docs with the actual value. It will likely be around 2 months though.

The reason for 2 months is that we want to limit risk. It would be trivial to increase it since it is just a configuration. I suggest engaging with the community to work on increasing it in the future.

[dunnerz]

Hi James from Neuron here. This improvement proposal is a requirement for us to scale our use cases reliably. Why? Let me give you an example:

1. Customer wants to purchase a session of flight tracking data from a number of sensors (or any other service) on a monthly rolling basis
2. Neuron works by keeping peer to peer connection between the customer and service providers during the course of the session
3. Currently, the customer pays for 30 mins of data via a scheduled tx. There are 3 signatories (customer, service provider, service validator)
4. At the end of the session, the customer has to make another scheduled tx to continue the service, otherwise it shuts down
5. Any network or mirror node unavailability results in the loss of this renewal service, meaning that service level agreements can only be provided for 30 minutes at a time.
6. Customers like to pay monthly for data services. We therefore need a session time that fits with typical business payment cycles and SLA
7. Due to possible network unavailability during renewal, it is sensible to schedule the renewal a week or two in advance of the end of a session
8. This gives us multiple opportunities to renew the service before the current service ends

Based on the above, we would highly support and endorse a change to enable scheduled transactions of around 45 days, to allow for 30 day payment cycles, and 15 days of wiggle room to allow people to renew services up to 2 weeks in advance of the previous service end.

Happy to discuss this with anyone, but this feature is super critical for us to convince the large corporations, as they need SLAs and high availability. It will be very difficult to deliver on that without this HIP, unless we add an alternative system which would be centralised, or rely on a 2nd layer 1 network

[iron4548]

Just tagging @bguiz to make sure he's aware of this. Sounds like a blocker for Neuron.

[rocketmay]

Adding in some feedback from our team at HashPack, we think this is a very important HIP for many projects that are looking for multisig treasury management solutions.

We see that TokenMint and TokenBurn are supported transaction types. If we could also see TokenUpdate supported that is an important transaction for this use case to cover.

On the whole my team and I support this HIP and see it enabling some powerful features being built on the network that would serve existing and future projects.