You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: