Defining a recommended pattern (standard) for handling offline signing

[ed-marquez]

With this entry, I'm looking for input and consensus on whether we should define a recommended way to handle offline signing.

Sample use cases:

• Alice (User 1) wants to be able to create a transaction on Bob's (User 2) behalf and have Bob sign it
• Or Alice wants an air-gapped computer to sign her transactions

The SDKs have support for this and we have limited examples, but there is no explanation to go with them, or consistent patterns such as packaging an unsigned transaction into a JSON payload and receiving a signed transaction back.

As an alternative, we can also consider/look into sending a transaction to someone and instead of receiving the signed transaction back, we receive only their signature (may not be as straight forward technically). Any other alternatives to consider for offline signing?

[0xJepsen]

This is the goal of this Hip but has been on my backburner lately. I was working with Sergey on it. It does need to be redone in JSON rather than proto. The primary concern here is supporting non-custody of keys to support self-sovereignty.

Additionally, Daniel from launch badge recently introduced this which may allow us to integrate support with applications like metamask.

So this may depend on how the SC service and the CAIP identifiers come into play.

[topshef]

I'm also hitting this issue and may kick off with something like this..

PCH Pre-Consensus Hash
PTH Persistent Transaction Hash
being a hash of a json containing persistent data, minimally this might be

• txid (operator @ startseconds.nanos)
• memo
• tx type eg transfer transaction (determines remaining structure)
• transfers (3 arrays, hbar ft nft)

PCH can then be used to verify and link up tx between eg hashpool etc and mirror data post confirmation

Any ideas feedback or pointers welcome cheers