Closed ebma closed 4 months ago
yarn.lock
changesStatus | Count |
---|---|
289 | |
64 | |
1 | |
6 |
Name | Link |
---|---|
Latest commit | 6538ed688aefa17749708715790ae459d23e94d1 |
Latest deploy log | https://app.netlify.com/sites/pendulum-pay/deploys/66339f9111763c0008b21b00 |
Deploy Preview | https://deploy-preview-22--pendulum-pay.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Follow-up to #18. Only merge once #18 is merged.
Closes #20. Addresses comments from previous PR.
Server signature process
The service exposes two endpoints,
/v1/stellar/create
and/v1/stellar/payment
. The first will provide the signature for the creation and trust opening operation of the specified ephemeral account's address. The second will provide two signatures: One for a payment transaction of a specified amount and destination, and another one for a trust closing and merge operation.Sequence passing
For the first signing operation, the sequence number of the funding account will be provided from the service to the UI, which will load the account with this sequence number and public key to create the corresponding mirror transaction.
For the second call, the UI provides the sequence number to the service, which it will use to create the transactions and send the signatures.
Potential bugs
Several processes querying the same signing service could produce a situation in which the sequence number specified by the signing service is not valid if more than two signatures are created in parallel, at least for one of them.
This can be partially avoided by keeping a global sequence state on the service, but still the problem exists that the corresponding transactions must be executed by the UI in the order by which the service signed them, which is not certain since the UI may execute at different speeds due to network issues.