This commit fixes a bug which would potentially cause a panic if a
channel returned from FetchOpenChannels attempted to access the
internal pointer to the database.
To fix this bug, the pointer is now properly set once the channel has
been loaded from the database.
This commit introduces the concept of “closing” an already active
channel. Closing a channel causes all the channel state to be purged
from the database, and also triggers the creation of a small “summary”
kept concerning details of the previously open channel.
This commit also updates the previous test case(s), and includes the
close channel bucket in the database deletion in the .Wipe() method.
This commit fixes a bug introduced within a prior commit. The prior
commit failed to drollery reverse the txid string taken in as user
input, therefore in order to properly close a channel, the user needed
to manually reverse the txid themselves.
With this change, `wire.NewShaHashFromStr` is used which properly
reverses the string within the constructor. This allows the string
reported not be directly used to the close an active channel.
This commit also corrects a few logging messages.
Currently positional arguments *are not* supported, and all arguments
must be passed via unix-style command line arguments.
In a later commit support for concurrent positional, and manually
specified arguments will be added.
This commit adds the necessary plumbing within the server, peer, and
rpcServer to handle opening and cooperatively closing a channel with a
remote peer.
Many new data structures have been added to the peer in order to allow
it to efficiently manage opening+.losing new/existing lightning
channels. Additional documentation has been added to several methods
within the peer struct, with some minor renaming along with way. The
peer has also gained a dedicated goroutine whose job it is to manage
any requests pertaining to opening, or closing any channels with the
remote peer.
The messages have been added to lnrpc define the requests and responses
to channel open+close messages. Additional channel logic has been added
between the rpcServer, peer, and server in order to properly manage the
necessary synchronization.
This commit introduces the fundingManger which is used as a bridge
between the wallet’s internal ‘ChannelReservation’ workflow, and the
wire protocol’s funding messages.
The funding manger is responsible for progressing the workflow, and
communicating any errors generated during the workflow back to the
source peer.
This commit adds additional test cases to test both cases (initiator vs
responder) for a single funder channel workflow. Additionally, the
previous dual funder tests have been extended in order to detect proper
funding channel broadcast, and the ChainNotifier’s role in notifying
upstream callers that a funding transaction has been embedded in the
chain at a sufficient depth.
At this point the tests certainly need to be cleaned up. bobNode should
be replaced with a second instance of the wallet modeling a remote
peer.
This commit modifies the existing workflow to add additional paths to
be used when on the responding side of a single funder workflow.
Additionally, several bugs encountered within the existing dual funder
workflow logic have been fixed, and modified to account for the wallet
being on the igniting side of a single funder workflow.
The previous logic incorrectly assumed the returned address was already
a p2wkh address. Instead, a p2sh address was returned. So we now
correctly craft both the sigScript and witness stack for a nested p2sh
spend.
This is required since for single funder channels, we don’t contribute
any funds so we don’t need to select any change or coins for input into
the funding transaction.
This commit adds 3 methods to lnwallet.ChannelReservation intended to
facilitating a single funder channel workflow between two nodes. A
single funder workflow is characterized as the initiator committing all
the funds to a channel, with the responder only providing public keys,
and a revocation hash.
The workflow remains the same for the initiator of the funding
transaction, however for the responder, the following methods are
instead called in order:
* .ProcessSingleConribution()
* .CompleteSingleContribution()
* .FinalizeReservation()
These methods are required for the responder as they are never able to
construct the full funding transaction, and only receive the out point
of the funding transaction once available.
A cooperative closure of a LightningChannel proceeds in two steps.
First, the party who wishes to close the channel sends a signature for
the closing transaction. Next, the responder reconstructs the closing
transaction identically as the initiator did using a canonical
input/output ordering, and the currently settled balance within the
channel. At this point, the responder then broadcasts the closure
transaction. It is the responsibility of the initiator to watch for
this transaction broadcast within the network to clean up any resources
they committed to the active channel.
This commit modifies most of the wire messages to uniquely identify any
*active* channels by their funding output. This allows the wire
protocol to support funding transactions which open several channels in
parallel.
Any pending channels created by partial completion of the funding
workflow are to be identified by a uint64 initialized by both sides as
follows: the initiator of the connection starts from 0, while the
listening node starts from (1 << 63). These pending channel identifiers
are expected to be monotonically increasing with each new funding
workflow between two nodes. This identifier is volatile w.r.t to each
connection initiation.
The call to copy used incorrect slicing on `greetingMsg` which caused
the remote node to always reject the auth attempt as all zeroes
(0000..) was being sent as the local node’s guess to the remote node’s
public key identity.
This commit overhauls the current schema for storing active channels in
order to support tracking+updating multiple open channels for a
particular peer.
Channels are now uniquely identified by an output (txid:index) rather
than an arbitrary hash value. As a result, the funding transaction is
no longer stored, as only the txin is required to lookup the original
transaction, and to sign for new commitment states.
A new bucket, nested within the bucket for a node’s Lightning ID has
been created. This new bucket acts as an index to the active channels
for a particular peer by storing all the active channel points as keys
within the bucket. This bucket can then be scanned in a linear fashion,
or queried randomly in order to retrieve channel information.
The split between top-level, and channel-level keys remains the same.
The primary modification comes in using the channel ID (the funding
outpoint) as the key suffix for all top-level and channel-level keys.
This commit adds a new method to the ChainNotifier interface which
subscribes the caller to a continuous stream of notifications generated
by new blocks added to the tip of the Bitcoin main chain.
Concurrently, this method is intended to be used in order to obtain the
necessary block height information to properly handle the timeout
period on any pending HTLCs. A continuos stream, rather than a one-off
notification is chosen in order to discourage a goroutine-per-HTLC
model which would be rather wasteful.
This commit updates the documentation for the chainntfs interface to
specify that notifications for spends registered with
`RegisterSpendNtfn` should be triggered *only* once a transaction
spending the target outpoint is *seen* within the network.
This strictness is required in order to allow an ‘honest’ counter-party
to properly sweep funds within channels with short delays.
This commit adds some cursory documentation along wit minor field
modifications to all messages which deal with adding HTLC’s, or
updating remote commitment transactions.
The messages for dual funding of channel is left purposefully
undocumented as all initial negotiations will be single funder by
default.
A revamp of the testing infrastructure of lnwire will be committed in
the near future.
The SFOP is the final message sent during the single funding channel
negotiation protocol. Once Alice sends the SFOP message to Bob, Bob
will then commit resources to watching and updating the newly created
channel with Alice.
This commit adds some additional documentation in the form of comments
to the start of the revised single funder workflow.
A primary change lies in the introduction of the exchange of Channel
Derivation Points (CDP’s) for both sides. Using CDP’s we can derive
channel authentication proofs which are both unforgettable and binding.
