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.
This commit adds the SingleFundingSignComplete message to the single
funder transaction workflow. This marks the second to last message sent
in the workflow. The message transports Bob’s signature for the
commitment transaction, allowing Alice to broadcast the funding
transaction as she can now refund her inputs.
This commit adds the SingleFundingComplete message to the single funder
channel workflow. This is the 3rd message sent in the workflow,
traveling from Alice to Bob once Alice is able to construct the final
commitment transaction.
Only nested p2sh or pure witness outputs are used when selecting coins
for inputs to a funding transaction.
The funding transaction output now uses p2wsh rather than regular p2sh.
All tests have been updated accordingly.
The new available address types are: regular p2pkh, p2wkh, and finally
p2wkh nested within p2sh. The latter address type will initially be
used to allow users to “fund” the lnd wallet.
