This commit adds detection of contract breaches within the commitment
state-machine for a channel. A contract breach is defined as the event
wherein a channel counter-party broadcasts a previously revoked
commitment transaction. Such an event immediately closes a channel as
the funds are now in a state of dispute.
Once a breach is detected, a snapshot of the breached state is
retrieved from the database’s revocation log. This snapshot is then
used to generate the revocation leaf used within this particular state
along with all the other information ncessary to sweep ALL active funds
within the channel. This information is encapsulated within the
BreachRetribution struct which is sent over a new channel dedicated to
sending/receiving BreachRetributions.
This commit modifies the logic within the state machine to properly
populate the new field of `OutputIndex` which the HTLC stored within a
channel delta.
With this change, in the future we’ll be able to quickly locate a
particular HTLC output in the scenario that the commitment transaction
has been broadcast on-chain and we need to sweep it. Allocating a few
extra bytes on-disk saves us from the guess-and-check logic+code
required otherwise.
This commit adds some necessary locking to ensure that all updates to
the internal state of the commitment state machine are fully serial and
thread-safe. This change is required to ensure future actions w.r.t
taking action once a revoked commitment transaction has been broadcast
are not carried out while the channel’s state is being updated.
This commit extends the SignDescriptor with a single attribute, the
‘PrivateTweak’. The duties of the Signer interface have also been
augmented to properly derive a private key using the specified tweak,
iff it’s non-nil.
As currently defined in order to generate the proper private key based
off of a PrivateTweak, the signer is to add the tweak value to the
private key for the specified public key. This generated value is to be
used for signing within the specified context.
This change paves the way for automatic revoked output sweeping with
signatures generated directly by the Signer interface, maintaining the
structure of the abstraction.
A test has been added at the interface level in order to excerise each
WalletController’s implementation of the key derivation as currently
defined.
This commit converts the rearming two commitment spend functions to use
the lnwallet.Signer interface directly rather than manually manage
private keys during the signing process. This commit is in preparation
for implementation of fully automated revoked uncooperative closure
detection and retribution.
This commit finalizes the implementation of #58 by integrating passing
around the obfuscate state hints into the funding workflow of the
wallet, and also the daemon’s funding manager.
In order to amend the tests, the functions to set and receive the state
hints are now publicly exported.
This commit modifies the channel state machine slightly to encode the
current state number using 30-bits of the sequence number within the
commitment transaction’s only input.
Such a modification reduces up the processing time required to punish
the counter party for breaching the contract established within the
channel by broadcasting an older revoked state.
This fixes#58 with a minor modification to what was originally
suggested.
This commit removes the prior test for the node restart method as it
can be very flaky due to process not always relinquishing ports they
were blinded to.
The solution for this problem is to have the lnd processes obtain ports
to listen on based on their process ID.
This commit modifies the ChannelType enum to no longer use iota as
changes in the definition would cause the values to shift, breaking the
long-term stability required for persistence. Instead, we now select
values manually to indicate the particular channel type.
This commit modifies the existing OpenChannel struct slightly to store
a bool which indicates if we were the one who initially initiated the
channel or not. This information is relevant as in the current draft of
the specification, much of the fee related negotiation is contingent on
who initiated the channel.
This commit removes all prior fee tracking attributes along with the
persistence code from OpenChannel. The rationale is that fees actually
don’t exist at the channel level, and instead should be tracked at
higher level of abstraction as fees come from the inbound/outbound
satoshi spread.
This commit modifies the OpenChannel struct along with all related
persistent to additional store a single byte which indicates the exact
type of the channel. This may be useful in the future as higher level
behavior may change depending on the precise type of the channel.
This commit adds two utility functions along with corresponding tests
for adding obfuscated state number hints to each commitment
transaction.
Such a feature reduces the search time to recover the necessary
material to punish a counterpaty for broadcasting an invalid state from
O(N), to O(1), where N is the number of states in the channel’s
transcript. By encoding the obsfucated state number, either side is
able to quickly obtain the ncessary state to excerise “justice”.
This commit adds a new feature to the network harness: test writers are
now able to select arbitrary nodes, causing them to restart.
This functionality will be useful in the future in order to test
scenarios like persisting data across restarts, re-syncing after
re-connections, reacting to the counter party broadcasting revoked
states, etc.
This commit modifies the current implementation to more closely match
what’s currently specified within the spec.
The encrypted+MAC’d packet length is no longer included as the
associated data for the encryption/decryption of transport messages.
This isn’t required as if an active attacker swaps out the encrypted
length in the byte string, the decryption+MAC check will simply fail as
the nonce won’t be in proper sequence.
This commit modifies the ChannelBalance RPC to fetch the balance from
disk since channels are now able to efficiently retrieved from disk due
to recent index that have been added. Previously this RPC would only
return accurate information if we had an active connection to the
counter party for each channel.
This RPC implements the two new RPC methods added in a prior commit.
This involved a slight refactoring to make use of duplicated code
amongst the sync and async variants of the methods.
This commit adds synchronous version of the RPC’s to send payments over
channels and open new channels. The previous async versions of these
RPC calls have been removed from the REST interface.
Additionally for these two RPC calls any field which accepted byte
slices now also accept a variant of the field which is a hex-encoded
string.
The OpenChannelSync RPC is intended to be used along with either the
ListChannels or PendingChannels RPC to poll for a channels existence or
non-existence as a signal that the channel is finally open.
This commit implements key rotation for brontide as-per the current
draft of the LN p2p crypto spec. Key rotation is currently performed
every 1000 messages encrypted/decrypted with a cipherState object. Key
rotation is performed by evaluating the HKDF (extracting exactly 64
bytes) with the current chaining key, and cipher key. The key rotation
is to attempted after each nonce increment making implementation easy
as the current nonce value will already be within the local scope.
This commit refactors the peer struct slightly in order to implement
the new ping/pong workflow added in a prior commit. Pings are currently
sent every 30 seconds unconditionally.
This commit adds Ping and Pong messages to the suite of lnwire
messages. The usage of these messages within the daemon are similar to
the usage of Bitcoin’s ping/pong messages. Pings are to be sent
periodically with a random nonce to check connection activity and also
to gauge latency. Pong’s are to be sent in reply to ping messages,
echo’ing the same nonce used.
This commit adds a document which outlines some of the traits desired
in future contributions to the daemon. It’s my hope that this document
will allow new contributors to quickly get up to speed on what is
desired in new contributions, possibly directly speeding up review
times.
This commit implements message chunking within the implementation of
net.Conn which implements our initial handshake, then uses the crypto
to read/write messages.
With this change it’s now possible to send message larger than 65535
bytes over a p2p crypto connection by properly chunking the messages on
the side of the connection that’s writing.
This commit modifies the current implementation of the p2p crypto
protocol to further constrain the max allowed payload size. With this
change we now use 16-bits (2-bytes) for the maximum payload length.
This change puts us closer to strict adherence of the Noise spec, and
simplifies the memory management w.r.t implementing the current version
of our scheme.
Note that this doesn’t restrict the size of messages that are able to
be sent over the wire within the LN p2p protocol. Larger message can
safely be encapsulated within the crypt messages via fragmentation that
will detected take place if a larger message is detected.
This commit modifies lnwire.NetAddress by adding a .Network() method.
With this added method the struct now implements the net.Addr interface
meaning that it can now be transparently passed into any context where
a net.Addr is requested.
This change paves the way to integration of btcd’s new connmgr into the
daemon to handle establishing persistent connections to all channel
counter parties.
This commit modifies both the Sphinx packet generation and processing
for recent updates to the API.
With the version 1 Sphinx specification, the payment hash is now
included in the MACs in order to thwart any potential replay attacks.
As a result, any attempts to replay previous HTLC packets MUST re-use
the same payment hash, meaning that the first-hop node can simply
settle the HTLC immediately, thwarting the attacker.
Additionally, within the Sphinx packet, each hop now gets a per-hop
payload which contains the necessary details (CTLV value, fee, etc) for
the node to successfully forward the payment. This per-hop payload is
protected by a packet-wide MAC.
