Continue External Signer Support #408

Activity

1. ariard commented on Dec 2, 2019

   

   ariard

   on Dec 2, 2019

   More actions

   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.
2. TheBlueMatt commented on Dec 2, 2019

   

   TheBlueMatt

   on Dec 2, 2019

   CollaboratorAuthor

   More actions

   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.
3. TheBlueMatt

   added this to the 0.0.11 milestone on Dec 11, 2019
4. TheBlueMatt commented on Dec 13, 2019

   

   TheBlueMatt

   on Dec 13, 2019

   CollaboratorAuthor

   More actions

   #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.
5. devrandom commented on Jul 28, 2020

   

   devrandom

   on Jul 28, 2020

   Last edited by devrandom

   Member

   More actions

   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 #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.
6. jkczyz

   changed the title [-]Continue External SIgner Support[/-] [+]Continue External Signer Support[/+] on Jul 29, 2020
7. devrandom commented on Dec 2, 2020

   

   devrandom

   on Dec 2, 2020

   Member

   More actions

   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.
8. TheBlueMatt commented on Jun 8, 2021

   

   TheBlueMatt

   on Jun 8, 2021

   CollaboratorAuthor

   More actions

   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.
9. TheBlueMatt

   removed this from the 0.0.50 milestone on Jun 8, 2021
10. TheBlueMatt

    closed this as a duplicateof async signing completion #3489 on Oct 1, 2025