Commit Graph

12 Commits

Author SHA1 Message Date
Yaacov Akiba Slama
90008386d8 Copy InputIndex into the underlying SignDescriptor struct
When the InputIndex is not 0, the index is not currently copied into the
underlying SignDescriptor structure and the siganture generated is not
valid.
2020-02-09 10:55:50 +02:00
Oliver Gugger
4f98642b5e
signrpc: derive custom shared key
With this commit we add the ability to create a shared DH key by using
a custom node private key instead of the node's identity private key.
If no key locator is specified the node's identity private key will be
used as a fallback.
2020-01-06 14:53:32 +01:00
Oliver Gugger
33e8077181
signrpc: add DeriveSharedKey 2019-12-20 09:25:52 +01:00
Oliver Gugger
95226771ed
signrpc+rpcserver: add signer macaroon permissions 2019-12-11 22:37:40 +01:00
Oliver Gugger
9a73b9be78
signrpc: sign and verify messages with custom key
To allow signing of messages with any key in the key chain
we add two new methods to the signer RPC. These behave differently
to the methods with the same name in the main RPC as described
in the documentation comment.
2019-12-11 22:37:39 +01:00
Joost Jager
8996a1490d
lnrpc: reuse common FileExists function 2019-02-01 09:47:31 +01:00
Joost Jager
9e012ecc93
multi: move Input interface and related code
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
2019-01-31 13:25:33 +01:00
Wilmer Paulino
3420d6d917
lnrpc/signrpc/signer_server: fix incorrect lnwallet.InputScript field 2019-01-15 19:27:28 -08:00
Olaoluwa Osuntokun
4d647b6e5d
lnrpc/signrpc: add macaroon perms for ComputeInputScript 2018-12-09 15:10:35 -08:00
Olaoluwa Osuntokun
b0a7a57f57
lnrpc/signrpc: add ComputeInputScript implementation 2018-11-28 20:57:13 -08:00
Olaoluwa Osuntokun
4002caec69
config+rpc: create new generalized dynamic sub rpc server config framework
In this commit, we add the glue infrastructure to make the sub RPC
server system work properly. Our high level goal is the following: using
only the lnrpc package (with no visibility into the sub RPC servers),
the RPC server is able to find, create, run, and manage the entire set
of present and future sub RPC servers. In order to achieve this, we use
the reflect package and build tags heavily to permit a loosely coupled
configuration parsing system for the sub RPC servers.

We start with a new `subRpcServerConfigs` struct which is _always_
present.  This struct has its own group, and will house a series of
sub-configs, one for each sub RPC server. Each sub-config is actually
gated behind a build flag, and can be used to allow users on the command
line or in the config to specify arguments related to the sub-server. If
the config isn't present, then we don't attempt to parse it at all, if
it is, then that means the RPC server has been registered, and we should
parse the contents of its config.

The `subRpcServerConfigs` struct has two main methods:
`PopulateDependancies` and `FetchConfig`. The `PopulateDependancies` is
used to dynamically locate and set the config fields for each new
sub-server. As the config may not actually have any fields (if the build
flag is off), we use the reflect pacakge to determine if things are
compiled in or not, then if so, we dynamically set each of the config
parameters. The `PopulateDependancies` method implements the
`lnrpc.SubServerConfigDispatcher` interface. Our goal is to allow sub
servers to look up their actual config in this main config struct. We
achieve this by using reflect to look up the target field _as if it were
a key in a map_. If the field is found, then we check if it has any
actual attributes (it won't if the build flag is off), if it is, then we
return it as we expect it to be populated already.
2018-11-28 20:57:05 -08:00
Olaoluwa Osuntokun
b7757683b2
lnrpc/signrpc: implement new SignerServer sub RPC server
In this commit, we add a full implementation of the new SignerServer sub
RPC service within the main root RPC service. This service is able to
fully manage its macaroons, and service any connected clients. Atm, this
service only has a single method: SignOutputRaw which mimics the
existing lnwallet.Signer interface within lnd itself. As the API's are
so similar, it will be possible for a client to directly use the
lnwallet.Signer interface, and have a proxy that sends the request over
RPC, and translates the proto layer on both sides. To the client, it
doesn't know that it's using a remote, or local RPC.
2018-11-28 20:57:01 -08:00