Transaction-Signing-Protocol.md

[0xJepsen]

Open to community feedback

[0xJepsen]

Was discussing this with @bugbytesinc and I think he has a good point here.

'thinking the protocol for Send and SignAndSend should return the TransctionGetReceiptResponse --- because if really high thruput is required, all the "originating system" is going to ask for is a signature, then they'd manage the rest on their side -- so forget that SendForPrecheckOnly idea.'
'When I say return TransactionGetReceiptResponse I'm really meaning the protobuf encoded bytes of it. But still parsing out the Response Code might be nice.
It is also possible the transaction would not pass precheck, in which case the bytes would be empty. Because the wallet would have not gotten to the point where it could ask for a receipt because none would be created. '

[rocketmay]

Agree, the receipt should be sent back as the response for calls which result in the receiving entity submitting anything to HAPI. I don't think we need to specifically parse out the Response Code as part of the protocol.

[bugbytesinc]

Agree, the receipt should be sent back as the response for calls which result in the receiving entity submitting anything to HAPI. I don't think we need to specifically parse out the Response Code as part of the protocol.

Perhaps "Response Code" is not a good name, its more of a response for this protocol (not the HAPI response code)...like "I refuse to sign" or "You exceeded my limits" or "LGTM".

[janaakhterov]

What is the difference between this and scheduled transactions. Rather, why are scheduled transactions not able to be used to solve this issue?

[sergmetelin]

What is the difference between this and scheduled transactions. Rather, why are scheduled transactions not able to be used to solve this issue?

As far as I understand this HIP, it's more so for local communication between an application and a wallet, rather than a network-level communication. Using scheduled transactions would make the flow unnecessarily more complex (each transaction would require a co-signature from the app key) and more expensive.

[0xJepsen]

@danielakhterov What Sergey said is correct. If you were to use scheduled transactions for this, the decentralized application would always have to pay for the scheduled transaction without guaranteeing that its users would fulfill it. When a user uses a decentralized protocol, they are supposed to be responsible for that transaction's transaction fees. The new smart contract service may change this. Also, I should rewrite it in JSON.

[cacampbell]

You can already use an asynchronous transaction signer for local devices (with the SDK)

[gregscullard]

Note this other PR which proposes something similar based on existing standards
#179

[gregscullard]

I'm not sure it's up to the application to suggest to the browser wallet what limits should be. This could open the door to malicious behaviour where an application acquires privileges from an unwary user who may not read the message properly and approve by mistake.

I would propose a separate HIP for wallets to implement "convenience features" independently, e.g. allow a user to specify that they approve an app to spend up to x amount over a period of time, or approve the next 5 requests (up to an amount) by an app automatically.
These approvals would not be known to the app which would not be able to exploit them, they would merely be enabled by the user who doesn't want to be nagged every time they click on a link triggering a micropayment while reading article for example.

To be clear, this would not be an API, just recommendations for wallets to implement these convenience features.

[sergmetelin]

@0xJepsen do you think we should merge this one with #179? Do you mind adding relevant feedback there and potentially closing this one?

[0xJepsen]

@sergmetelin absolutely, that makes the most sense to me.