HIP-179 - External Transaction Signing for SDK and other clients

[shemnon]

Discuss [HIP-179](External Transaction Signing for SDK and other clients) - a protocol for external transaction signing for the SDK and other clients.

[hashaxis]

1. Consider exposing a signing request "validity window" or time-out variable:
   Different use cases may want to allow for more or less time for the signing request to remain valid and sit as pending.

(This may also require an additional error code such as "User did not transact in time" or "Signing request timed out")

[johnda98]

yes.. needed for 100% pure DeFI .. get it in there. specifically also.. does the HH ledger nano API permit signing ? anyone here know if the HH ledger wallet can sign a displayed transaction ? ANY HH transaction, e.g. ie Contract ExecuteTransaction.. with or without parameters ?

[gregscullard]

@johnda98 does Metamask allow signing of "opaque" transactions, e.g. a contract call without being able to display the call parameters to end users ?

• Is this not considered insecure (the app generating the payload could ask for just about anything to be signed)
  I understand it may not do that too many times before getting a bad rep from the community, but...

• Would it make sense for the wallet to be able to import an ABI so that it can decode and display the inputs to the function before asking the end user to sign ?

• Should signing an opaque message be consider a hard no, a soft no (with caveats displayed in wallet), a free for all ?

[johnda98]

Metamask signs transactions for a few years now.. so yep contract call transactions with a DApp accepting parms then sending the tran and the wallet extension popping up .. sign in.. key sign. I think HASHPACK.. HH custodial wallet is planning such a feature.. MMask anything from etherscan verifications to yes Opensea signin.. signup.. thats all you need a keypair signature.. no min KYC etc.

I would say DeFi that does not have custodial (custodial.. the DApp keeps the keypair), is critical.. so the custodial wallet of a Users choice/comfort, makes the deposits/ and yes listens for calls to prompt User to sign the tran... like a crypto send or yes sign of a contract call tran and gas input prompt. ... like a Remix prompt MMask for a contract call on ETH mainnet.. the usual web3 injected account/ - custodial wallet.

ABI import.. yep that would be a wallet's feature .. no diff from remix, right. A DeFi Dapp would normally prompt for all that and when ready to send.. prep and send the Tran to the wallet for signing.

Well, you know me.. I'm a no-nanny UK Gov kinda chap... buyer beware.. nano ledger.. you own the keys, dont mess it up kinda guy.... sooooo.... maybe it should be permitted than any Contract execute call be permitted for API signing... moreover.. how would the protocol determine what Contract calls are valid 'opaque' or not ? and its a wallets decision to offer such a UI to the transaction and/or present such or any Warning.. .. then the Users responsibility to sign or not.. wether they can understand the raw transaction content or not.

[Cooper-Kunz]

Pretty sure that Hashpack is noncustodial.

[johnda98]

Cooper, havnt had a chance to look at their intent.. curious .. your definition semantically-technically of 'noncustodial' ? probably akin to a Erik Voorhees of Shapeshift definition.. cool.

[Cooper-Kunz]

What do you mean? The definition of custodial versus non-custodial is black & white with respect to who has access to private keys.

[johnda98]

ok good, thnks - just wanted to clarify if you saw it as a DApp with key access requesting a tran signature from a wallet or meaning your definition in a wallet only context.

[johnda98]

for pure Defi where the DApp is non-custodial.. ie it demands third party wallet signing of all its transactions.. ie sushi/uniswap etc shapeshift. the option right now is 99% DeFi, I have to keep custodial trading accounts.. w keys encrypted to hash of the password in a Hedera fileid owned by the user themselves. ie password hash and encrypted pkey held to ABFT.. very cool... but not as pure as having a users wallet sign contract calls.

Of course.. now we have a working payable fallback function right ?? in the latest EVM derivative.. thus any wallet can send HBAR to a contractID and msg.value reflects the balance and msg.send the senders wallet account sent from. cool, but yes contractcall signing is also needed for useful DeFi DApps.. no point in sending in HBAR if no other state changes can be conducted without a custodial account in the DApp itself.

[gregscullard]

It may be worth adding a simple "authenticate" message specification. Client sends arbitrary message to the signer which signs the message and returns to the client.
The client can then verify the signature using the public key of an account id as known by Hedera.

This would support the simple process of authenticating that a user pretending to be account id 0.0.1234 actually is, this for example would support checking that an end user owns a particular nft that could unlock features within an app/client.

[johnda98]

valid point, nice. .. semi related example of Account to keypair verification .. UI related.. yes I had a Customer who had a consultant plug in another accountid into their iOS original hedera wallet so they could check the balance of that account.. and wallet allow that account to be entered.. so yes it showed the balance... but of course Customer forgot to change it back in the text box so 4 months later he opened the wallet and presumed that Account was that wallet.. and he tried to a crypto send.. Invalid Key of course.