Continue External Signer Support

[TheBlueMatt]

404 is starting a signing API, which should support hardware wallets and have some guarantees about what the external signer can enforce on the library in terms of what its willing to sign. Lots of work to be done here, but first we've gotta not have any access to private keys except through the API.

[ariard]

I've had a quick skim on #404, I think external signer support could be also extended to key_storage in ChannelMonitor, make Storage some kind of abstract interface too.

[TheBlueMatt]

Indeed, I haven't started playing with it in the ChannelMonitor context, cause that's quite a different thing (eg you may just do it in the "watchtower" mode), but that would have to come eventually.

[TheBlueMatt]

408 finishes most of the work on the Channel side of things (just needs a quick sed to get public keys directly from the ChannelKeys instead of private keys and then calculate the pubkey). Next step is to convert ChannelMonitor to use it. This is probably a good thing to do at the same time as refactor the whole ChannelMonitor to split signing and broadcasting logic to make watchtower support easier to write.

[devrandom]

Here are some design considerations to think about. I'm mostly motivated by the goals of the Lightning Signer project, which defines an API and reference implementation in Rust for external Lightning signers that will interface with any node implementation. The project maintains a comprehensive list of policy controls that are required in order for the external signer to secure funds even if the rest of the node software is compromised by an attacker.

Here are some design constraints on the external signer:

• the signer must completely understand the transactions which it is signing - it cannot treat them as opaque blobs
• the signer must maintain enough state to prevent some attacks - e.g. it must not sign revoked commitment transactions
• the signer must have the blockchain state proven to it so that it can enforce timing related policy - for example, it must ensure that an input channel is confirmed on-chain before routing incoming payments from the channel

Given the above constraints, here are some plausible design choices:

• the signer is stateful and tracks channel state such as: channel accepted (with counterparty data), channel closed, last commitment number, revoked commitment number.
• instead of decoding the transaction blob to derive transaction parameters, it is less error prone to (re-)construct the transaction on the signer. This ensures that an attacker can't alter an aspect of the transaction that we neglected to examine.
• the signer must receive assertions by an oracle about the inclusion of funding transactions on-chain

There are a series of PRs that are working towards this goal, including https://github.com/rust-bitcoin/rust-lightning/pull/658.

Some open questions:

• we are currently modifying the ChannelKeys API to be stateful. This means that we are losing the original stateless design. Do we still want that design for implementations that don't want to use an external signer, or for use as a utility for external signers?
• what is the best way to handle errors? for example, if a closing transaction was signed, trying to sign a commitment transaction should fail.

[devrandom]

Part of this work is to pass around the semantic transaction rather than the Bitcoin transaction. This will allow a higher level of assurance that all relevant aspects of the transactions were checked for policy violations in the signer.

[TheBlueMatt]

Dropping the milestone because I dunno if we need to tie any RL releases to this. It can continue to happen as lightning-signer moves forward.