Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[/tabs/api] implement "api" for networked signing #86

Open
fuxingloh opened this issue Jul 10, 2023 · 0 comments
Open

[/tabs/api] implement "api" for networked signing #86

fuxingloh opened this issue Jul 10, 2023 · 0 comments
Labels
kind/feature New feature request

Comments

@fuxingloh
Copy link
Contributor

What would you like to be added:

While #74 implement signing via scanning, this issue implements signing via an API for networked devices. Using a platter of technologies, we can implement a signing API that can be used to send an unsigned transaction over the network to a signing device and then return the signed transaction back to the requesting device.

Other considerations:

Push notifications: To notify the signing device that a signing request is pending and ready to be signed. This eliminates the need for polling. However, this requires a centralized service to push notifications to the requesting device requiring all signing devices to be registered with the centralized service if they want to receive push notifications.

Multi-key polling: While each key can sign multi digests and each keychain has multiple keys, this makes it impossibly difficult to scale the polling mechanism. If a device has 100 keys, then it would need to poll 100 times to see if any of the keys have a signing request. This is not scalable. We could implement a mechanism where the extended public key (BIP32 standard) is used to derive the public keys, and then the public keys are polled on the server instead. However, this would require the server to have access to the extended public key, which is not ideal from a privacy perspective. This won't solve the problem of scalability since we're just moving the problem to the server.

Prioritization: Should this implementation be supported first, or have scanning be supported first?

@fuxingloh fuxingloh added the kind/feature New feature request label Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature request
Projects
None yet
Development

No branches or pull requests

1 participant