Commit Graph

11 Commits

Author SHA1 Message Date
Oliver Gugger
7dfe4018ce
multi: use btcd's btcec/v2 and btcutil modules
This commit was previously split into the following parts to ease
review:
 - 2d746f68: replace imports
 - 4008f0fd: use ecdsa.Signature
 - 849e33d1: remove btcec.S256()
 - b8f6ebbd: use v2 library correctly
 - fa80bca9: bump go modules
2022-03-09 19:02:37 +01:00
Oliver Gugger
ffee7d1bcf
multi: fix newly detected linter issues 2022-02-10 11:02:02 +01:00
Dimitris Apostolou
530a2059e5
multi: Fix typos [skip ci] 2022-01-24 12:19:02 +02:00
Wilmer Paulino
e15ad026d4
chanacceptor: include commitment type in channel acceptor requests 2021-10-19 18:30:45 -07:00
Andras Banki-Horvath
80bc46e614
lint: fix proto message no-copy linter warnings 2021-05-04 17:33:14 +02:00
Calvin Zachman
19440c1e39 ensure 64bit alignment of atomically accessed field in ChannelAcceptor
- help lnd avoid a bug in the `sync/atomic` package which requires 64-bit alignment of atomically accessed fields
2020-12-28 10:04:13 -06:00
carla
5679dde1bc
multi: add channel open parameters to channel acceptor
Add more fields to channel acceptor response so that users can have more
fine grained control over their incoming channels. With our chained
acceptor, it is possible that we get inconsistent responses from
multiple chained acceptors. We create a conjugate repsponse from all the
set fields in our various responses, but fail if we get different, non-
zero responses from our various acceptors. Separate merge functions are
used per type so that we avoid unexpected outcomes comparing interfaces
(panic on comparing types that aren't comparable), with casting used
where applicable to avoid code duplication.
2020-11-10 21:09:10 +02:00
carla
38fd7d206f
multi: add custom error messages to channel acceptor
This commit adds an optional error message to the channel acceptor's
reponse to allow operators to inform (or insult) unsuccessful channel
initiators as to the reason for their rejection.

This field is added in addition to the existing accept field to maintain
backwards compatibity. If we were to deprecate accept and interpret a
non-nil error as rejecting the channel, then received a response with
accept=false and a nil error, the server cannot tell whether this is a
legacy rejection or new mesage type acceptance (due to nil error),
so we keep both fields.
2020-11-10 11:38:47 +02:00
carla
54c3e98b40
multi: move channel acceptor logic out of rpcserver
This commit moves and partially refactors the channel acceptor logic
added in c2a6c86e into the channel acceptor package. This allows us to
use the same logic in our unit tests as the rpcserver, rather than
needing to replicate it in unit tests.

Two changes are made to the existing implementation:
- Rather than having the Accept function run a closure, the closure
  originally used in the rpcserver is moved directly into Accept
- The done channel used to signal client exit is moved into the acceptor
  because the rpc server does not need knowledge of this detail (in
  addition to other fields required for mocking the actual rpc).

Crediting orginal committer as co-author:
Co-authored-by: Crypt-iQ
2020-11-10 11:38:45 +02:00
nsa
423887d3d8
chanacceptor: adding tests for the RPCAcceptor
This commit adds the TestRPCMultipleAcceptClients test which asserts
that the RPCAcceptor correctly handles multiple Accept callers.
2019-09-25 12:07:31 -04:00
nsa
2bd2e2e5ce
chanacceptor: Adding Chained and RPC acceptors
This commit introduces the chanacceptor package which is used
to determine, by a set of heuristics, which open channel messages
to accept and reject. Currently, two acceptors are implemented
via the ChannelAcceptor interface: ChainedAcceptor and RPCAcceptor.
The RPCAcceptor allows the RPC client to respond to the open channel
request, and the ChainedAcceptor allows a conjunction of acceptors
to be used.
2019-09-25 12:07:30 -04:00