Ideal API for Blockchain software

So while developing Bitcoin related software I’ve come up with a nice pattern.

Check out the npm module raw-op-return, a module for creating and parsing raw OP_RETURN data from blockchains:

The important thing is that the module doesn’t require having access to any private keys. It only requires a function for “signTransaction”.

This pattern is further expanded on in other services and protocols like bitstore, blockcast and openpublish:

These interfaces are also great for testing and allow for full integration tests like this:

I’m a little confused. Can you explain the high-level setup/architecture a bit more? Where are the private keys? With the clients I assume?

Also, you need to sign the transaction using a private key, so what exactly do you mean by doesn’t require any private keys? In the npm raw-op-return module example you gave:

var signTransaction = signFromPrivateKeyWIF(privateKeyWIF);

Thanks for starting the discussion thread!

Imagine a wallet in an iframe, or running in a system like:

Instead of exposing the privateKey to the rest of the application, I can only expose a “signTransaction” function. This is not only safer but allows for developers to write software while not having to take on the responsibilities of running wallet software and managing private keys.

Bitcoin services and protocols do not need to take on the responsibility of managing keys.

Individual wallets should expose common interfaces for signing transactions and messages.

The wallets can then prompt the user for “would you like to sign this transaction?” or have settings to automatically trust and sign from certain hosts and transaction types.

If you look at the types of interfaces that we’re exposing with services like bitstore, blockcast, and openpublish, you’ll see just how composable these modules are.

Getting unspent outputs, propagating transactions, and signing transactions are all interactions that are very stateful. Keeping these stateful operations outside of the module makes them more apt for interoperability.