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
Context / Description
I am currently using the Jade wallet (Blockstream Jade), which integrates the “Personal Blind Oracle” (its virtual secure element). However, I’ve noticed that the endpoints handling cryptographic operations for the Personal Blind Oracle depend on external Blockstream servers. My goal is to configure (or point) these endpoints to my own server—either on a local network or via Tor (.onion)—to have full autonomy and privacy over the data flow of the virtual secure element.
Both Sparrow wallet (Sparrow World) and radio-Jade wallet could benefit from this configuration, making it possible for the Jade to function independently without relying on external or centralized services.
Problem
Dependence on external servers: There is currently no clear option to set the Personal Blind Oracle (virtual secure element) endpoint to a local or onion address.
Privacy and Security: Many users want or need fully isolated setups (e.g., local networks or Tor) to avoid exposing their data to third parties.
Flexibility: Tools like Sparrow wallet or radio-Jade wallet, when integrated with the Jade, could take advantage of advanced configurations for air-gapped or fully offline environments.
Proposed Solution
Endpoint Configuration Option
Add a field within the Jade firmware or management software where the user can manually specify the Personal Blind Oracle address. Examples: http://192.168.0.10:8080 (local network) http://myserver.onion:8080 (Tor)
This way, the Jade would use that endpoint for cryptographic operations involving the virtual secure element, instead of the default Blockstream server.
Integration with Sparrow / Radio-Jade
Ensure Sparrow wallet (Sparrow World) and radio-Jade wallet recognize and use the custom endpoint. That way, any data flow related to the Personal Blind Oracle is handled locally or via onion.
Validation and Fallback
Implement a connectivity check to ensure the custom endpoint is functional and secure.
If the local or onion server is unavailable, provide a fallback option to the default server—though it should ideally be optional.
Documentation and Setup Guide
Provide official instructions on how to run a local (or onion) server for the Personal Blind Oracle software.
Explain how to configure the Jade and any other wallets to ensure all processes occur in a secure environment.
Expected Benefits
Full Autonomy: Users can control the virtual secure element (Personal Blind Oracle) data flow without relying on external services.
Enhanced Privacy: Local or onion connections reduce metadata exposure and bolster security for sensitive setups.
Offline / Air-Gapped Environments: Implementing local endpoints enables completely isolated setups with no internet access.
Ecosystem Expansion: Offers the possibility of building customized solutions, encouraging community innovation (third-party servers, custom data repositories, etc.).
Technical Considerations / Notes
Availability of the Personal Blind Oracle Software
The software or documentation for running the “Personal Blind Oracle” (virtual secure element) locally should be provided or made open for users.
Tor Connectivity
Users must have the Tor daemon running and configured, and the Jade firmware (and associated wallets) must be capable of routing requests through Tor.
Network Security
HTTPS/TLS for local connections or onion-based end-to-end encryption is recommended.
Optional Fallback
Advanced users may wish to completely disable fallback to the default server, ensuring only the custom endpoint is used.
Summary
I request a feature that enables users to manually set the “Personal Blind Oracle” (the Jade’s virtual secure element) endpoint, allowing Jade wallet to operate independently—whether on a local network or via an onion address—without relying on external Blockstream servers.
This change would provide greater privacy, security, and flexibility, benefiting both privacy-conscious enthusiasts and corporate environments that require customized configurations.
The text was updated successfully, but these errors were encountered:
Context / Description
I am currently using the Jade wallet (Blockstream Jade), which integrates the “Personal Blind Oracle” (its virtual secure element). However, I’ve noticed that the endpoints handling cryptographic operations for the Personal Blind Oracle depend on external Blockstream servers. My goal is to configure (or point) these endpoints to my own server—either on a local network or via Tor (.onion)—to have full autonomy and privacy over the data flow of the virtual secure element.
Both Sparrow wallet (Sparrow World) and radio-Jade wallet could benefit from this configuration, making it possible for the Jade to function independently without relying on external or centralized services.
Problem
Dependence on external servers: There is currently no clear option to set the Personal Blind Oracle (virtual secure element) endpoint to a local or onion address.
Privacy and Security: Many users want or need fully isolated setups (e.g., local networks or Tor) to avoid exposing their data to third parties.
Flexibility: Tools like Sparrow wallet or radio-Jade wallet, when integrated with the Jade, could take advantage of advanced configurations for air-gapped or fully offline environments.
Proposed Solution
Endpoint Configuration Option
Add a field within the Jade firmware or management software where the user can manually specify the Personal Blind Oracle address. Examples:
http://192.168.0.10:8080 (local network)
http://myserver.onion:8080 (Tor)
This way, the Jade would use that endpoint for cryptographic operations involving the virtual secure element, instead of the default Blockstream server.
Integration with Sparrow / Radio-Jade
Ensure Sparrow wallet (Sparrow World) and radio-Jade wallet recognize and use the custom endpoint. That way, any data flow related to the Personal Blind Oracle is handled locally or via onion.
Validation and Fallback
Implement a connectivity check to ensure the custom endpoint is functional and secure.
If the local or onion server is unavailable, provide a fallback option to the default server—though it should ideally be optional.
Documentation and Setup Guide
Provide official instructions on how to run a local (or onion) server for the Personal Blind Oracle software.
Explain how to configure the Jade and any other wallets to ensure all processes occur in a secure environment.
Expected Benefits
Full Autonomy: Users can control the virtual secure element (Personal Blind Oracle) data flow without relying on external services.
Enhanced Privacy: Local or onion connections reduce metadata exposure and bolster security for sensitive setups.
Offline / Air-Gapped Environments: Implementing local endpoints enables completely isolated setups with no internet access.
Ecosystem Expansion: Offers the possibility of building customized solutions, encouraging community innovation (third-party servers, custom data repositories, etc.).
Technical Considerations / Notes
Availability of the Personal Blind Oracle Software
The software or documentation for running the “Personal Blind Oracle” (virtual secure element) locally should be provided or made open for users.
Tor Connectivity
Users must have the Tor daemon running and configured, and the Jade firmware (and associated wallets) must be capable of routing requests through Tor.
Network Security
HTTPS/TLS for local connections or onion-based end-to-end encryption is recommended.
Optional Fallback
Advanced users may wish to completely disable fallback to the default server, ensuring only the custom endpoint is used.
Summary
I request a feature that enables users to manually set the “Personal Blind Oracle” (the Jade’s virtual secure element) endpoint, allowing Jade wallet to operate independently—whether on a local network or via an onion address—without relying on external Blockstream servers.
This change would provide greater privacy, security, and flexibility, benefiting both privacy-conscious enthusiasts and corporate environments that require customized configurations.
The text was updated successfully, but these errors were encountered: