[proposal] de-militarized-[RPC]-zone #15319

issue HashUnlimited opened this issue on February 1, 2019
  1. HashUnlimited commented at 6:11 PM on February 1, 2019: contributor

    Short abstract: Certain (and newly introduced) functions are only accessible via the RPC interface. While being very useful, due to the complexity, some of them (e.g. multisig, partially signed tx) might never make it onto a user level.

    Proposal: Introduction of an advanced user level. At advanced level, a limited RPC interface is enabled which serves all regular functions except those where private keys are involved.

    This would allow 3rd parties to create guiding software, which takes over the complex steps of those functions, while remaining trustless.

    My 2 cents so far, probably enough to trigger a discussion.

  2. jonasschnelli added the label Brainstorming on Feb 1, 2019
  3. jonasschnelli added the label RPC/REST/ZMQ on Feb 1, 2019
  4. jonasschnelli commented at 12:03 AM on February 2, 2019: contributor

    There once was the RPC safe mode (which was different though) #13090.

    The current safest mode is probably to run without private keys (createwallet <name> true) or to run with disabled wallet or wallet not compiled in.

    Another approach I once looked into would be creating another RPC server binary that would act as a bridge between an http server (that could use TLS and auth) and the bitcoind RPC server. That bridge software could be configured for multiuser with quotas about how much wallets they can create, etc. A safe mode would also be possible.

  5. promag commented at 4:05 PM on February 4, 2019: member

    Not sure if I understand, you want distinct RPC interfaces or you want different user privileges?

  6. HashUnlimited commented at 4:46 PM on February 4, 2019: contributor

    I think there are multiple ways to achieve what is desired. An extended REST API with read-only wallet access could do the job as well.

    Example: I am renting out servers. One machine is too much for Alice but together with Bob the offer would fit. Now I am looking for a way to handle the payment in a mainly automated way by checking their wallets for the possible inputs and suggesting the PSBT for each of them. That way they could check and copy-paste sign the inputs. I can handle the rest of the process but would need read-only access to their wallets.

  7. promag commented at 7:48 PM on February 11, 2019: member

    I don't think we should promote access to other's server HTTP interface. P2P should be the only public interface.

    Even the REST interface should not be exposed, otherwise it's easy to mess your node.

  8. HashUnlimited commented at 12:58 PM on February 12, 2019: contributor

    The REST could be expanded to a wallet branch... Are there other ideas how to port useful features into commonly useable and safe interfaces?

  9. benthecarman commented at 4:42 PM on June 10, 2019: contributor

    I made a project that is similar to this idea, you can check it out here: https://github.com/benthecarman/Lightning-Rod

  10. MarcoFalke commented at 3:32 PM on April 26, 2020: member

    Duplicate of #12248 ?

  11. MarcoFalke closed this on Apr 26, 2020

  12. MarcoFalke locked this on Feb 15, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-13 15:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me