The public Go API

[o-jasper]

I wrote some stuff here that tries to mimick the go public library with the (cpp)json rpc.. Might be better off doing so on fork of eth-go, right? Idea being to make the api and interface with some arbitrary backend talking to a running ethereum instance.

With the current setup you start an entire ethereum node, or they can share the computation/state? Afaik not.

[o-jasper]

To be more clear: How do you make multiple programs talk to the same Ethereum instance?

Expecting the answer to be 'using json rpc', it would be useful to have an interface. How do i go about doing that? ..maybe this is something i should be figuring out myself, sorry if i am bothering you.

[o-jasper]

Now it also occurs to me that you might want to two ways to make a Tx:

1. The Ethereum instance manages the private key: Ask the Ethereum instance to make and the transaction.
   • edit: or maybe A can ask the ethereum instance to make the transaction, but the Ethereum instance asks B instead.
2. The application manages a private key: It creates a transaction and sends the signed transaction.

The bit that signs it basically has the problem 'does the user really want to send this message?' Imo contract/interface-to-contract writers might have to be able to write a little code so they have some control over what the user sees before signing a transaction.

[zelig]

I thought of the same pattern. There should be a JSON RPC Client that implements the public API. Whats more the ethereum browsers (GUI, CLI) could connect this way too. This could allow clients to easily connect to a full mining node (from gadgets, or mobile devices which do not run a full node). There could be admin interface and remote reactor either as capabilities or with their own json-rpc server.
When refactoring the keymanager, I already thought of a remote keystore with encrypted wallet. Although running your own full node in the cloud with private ports with ssl is pretty good privacy, the idea that your private key would never leave your local device while it is connected to a remote ethereum node is tempting and possible.

[o-jasper]

@zelig i think that is what lightweight clients are for? I would suspect that ethereum entities running on a cloud service to in effect be a single Ethereum instance, at best. It is a risk to decentralization.

Lightweight clients is a possible answer to the idea of the JSON RPC of course; "the proper way to do it is not the JSON RPC, but a lightweight client". But then i see no harm to JSON RPC if it only connects securely between things owned and controlled by the same person.

Hard wallets for instance sound interesting. If you have a lot at stake, private keys .. well i would have different levels of security and ability on different keys, and maybe use multiple computers to boot..

[obscuren]

The idea is that Ethereum will run a master node and any other node that starts will look if there's a master node present on the computer (or by telling it to connect to something). This will not be done through the public API or any other form of JSON overhead. Simple TCP will suffice.

If said master node is present it will register it self as a child node on the master node and any ethereum activity will be passed along to the child nodes.

[o-jasper]

Thanks. So if you just use the public API it automagically uses the existing node, and the json is just extra? I.e. no need for a json interface to the public API. Close if yes :)

[obscuren]

No need for a JSON interface (although it already has one). If you'd set up a node (e.g., using eth-go) it will automatically connect to an existing node if there's one and manage all the syncing between the two. There will be no need to set this up by the user, just happens in the background.