core-lightning/hsmd/capabilities.h

#ifndef LIGHTNING_HSMD_CAPABILITIES_H
#define LIGHTNING_HSMD_CAPABILITIES_H

#define HSM_CAP_ECDH 1
#define HSM_CAP_SIGN_GOSSIP 2
#define HSM_CAP_SIGN_ONCHAIN_TX 4
#define HSM_CAP_COMMITMENT_POINT 8
#define HSM_CAP_SIGN_REMOTE_TX 16
#define HSM_CAP_SIGN_CLOSING_TX 32

#define HSM_CAP_MASTER 1024
#endif /* LIGHTNING_HSMD_CAPABILITIES_H */
hsm: Unifying the client creation and adding client capabilities We had a number of entry points into the HSM, all with different behavior, so this is my attempt at unifying the way we handle clients. Every client, except master, now takes the same path entry point to the HSM and we use capability bit flags to indicate whether the client is allowed to execute a set of operations. Signed-off-by: Christian Decker <decker.christian@gmail.com> 2017-11-28 16:46:14 +01:00			`#ifndef LIGHTNING_HSMD_CAPABILITIES_H`
			`#define LIGHTNING_HSMD_CAPABILITIES_H`

			`#define HSM_CAP_ECDH 1`
			`#define HSM_CAP_SIGN_GOSSIP 2`
hsmd: add routines to sign onchain transactions, part 1. This handles the "to-us" transactions which return funds to the wallet. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2018-07-23 11:53:02 +09:30			`#define HSM_CAP_SIGN_ONCHAIN_TX 4`
hsmd: provide routine to get the per-commitment point. This will be used by onchaind for now, but also for openingd and channeld in future, so it returns the old revocation secret as well. Of course, the HSM should refuse to sign a commitment transaction if it has handed out the revocation secret previously! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2018-07-23 11:53:02 +09:30			`#define HSM_CAP_COMMITMENT_POINT 8`
hsmd: routines to sign remote commitment and HTLC txs. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2018-07-23 11:53:03 +09:30			`#define HSM_CAP_SIGN_REMOTE_TX 16`
hsmd: add message to sign the mutual close transaction. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2018-07-23 11:53:03 +09:30			`#define HSM_CAP_SIGN_CLOSING_TX 32`
hsm: Unifying the client creation and adding client capabilities We had a number of entry points into the HSM, all with different behavior, so this is my attempt at unifying the way we handle clients. Every client, except master, now takes the same path entry point to the HSM and we use capability bit flags to indicate whether the client is allowed to execute a set of operations. Signed-off-by: Christian Decker <decker.christian@gmail.com> 2017-11-28 16:46:14 +01:00
hsm: Make the master simply a client with special capabilities 2017-11-29 12:09:06 +01:00			`#define HSM_CAP_MASTER 1024`
hsm: Unifying the client creation and adding client capabilities We had a number of entry points into the HSM, all with different behavior, so this is my attempt at unifying the way we handle clients. Every client, except master, now takes the same path entry point to the HSM and we use capability bit flags to indicate whether the client is allowed to execute a set of operations. Signed-off-by: Christian Decker <decker.christian@gmail.com> 2017-11-28 16:46:14 +01:00			`#endif /* LIGHTNING_HSMD_CAPABILITIES_H */`