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);
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.