Construct Transaction API

[n8maninger]

Adds two new endpoints to construct transactions. This combines and simplifies the existing fund flow for sending siacoin and siafund transactions.

Requires #210

[lukechampine]

Definitely not safe to blindly sign whatever hashes a server gives you. 😬 This is a good illustration of how, strictly speaking, it's not possession of private keys that matters, but control.

Clients need to know what they're signing, which means they need to compute the hash. And they can't compute the hash blindly either (i.e. call BLAKE2b on a buffer returned by the server) for the same reason. At best, the server could return a buffer with preallocated space for the client to write the SiacoinOutputs into. But that's still vulnerable: the server could trick the client by having it write the outputs into ArbitraryData, while the actual SiacoinOutputs are malicious. So the client needs to be able to parse transactions. As far as I can tell, this is unavoidable.

IMO, any client should have the ability to parse transactions anyway (so that it can display them to the user), in addition to managing private keys and hashing/signing.

[n8maninger]

Definitely not safe to blindly sign whatever hashes a server gives you. 😬 This is a good illustration of how, strictly speaking, it's not possession of private keys that matters, but control.

You’re absolutely right that blindly signing hashes from an untrusted server is a security risk. However, this API is intended for trusted scenarios where the user controls both the client and the server.

IMO, any client should have the ability to parse transactions anyway (so that it can display them to the user), in addition to managing private keys and hashing/signing.

Requiring an implementation of full transaction parsing and sighash calculation in every possible language is really poor devex. Displaying a JSON object in a UI is relatively straightforward, implementing full sighash calculation is much more complex. For most languages, ed25519 libraries are available, but Sia specific transaction hashing logic isn’t.

The goal is to provide a minimal, generic, and language-agnostic flow for developers to interact with that balances usability and security for trusted implementations. For users that need maximum security and control, they still have the existing fund flow and can calculate the sig hash manually in Go or Rust.

I'm sure we can come up with a flow that is secure enough for daily use without requiring developers to dig into low-level Sia specific code unless they want to. Maybe it's as simple as adding additional steps so the user has to pass the transaction back to the server and can inspect it rather than caching it server-side?

[n8maninger]

@lukechampine I removed the signing flow from this. Now it just builds a transaction and returns it for manual signing.

[peterjan]

LGTM 👍