This commit adds the FundingManagerPersistence test to ensure that the
funding process completes as expected when nodes shutdown after the the
funding transaction has been broadcast. Note that the final parts of
several wallet tests have been removed, as functionality has been moved
to the Funding Manager and should now be tested there.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
When a pending channel is persisted and then reloaded upon system startup
it's necessary to also persist the number of confirmations that will be required
before the pending channel can be opened.
In order to facilitate persistence during the funding process, added
the isPending flag to channels so that when the daemon restarts, we can
properly re-initialize the chain notifier and update the state of
channels that were going through the funding process.
In this commit the initial implementation of revocation hash
generation 'elkrem' was replaced with 'shachain' Rusty Russel
implementation which currently enshrined in the spec. This alghoritm has
the same asymptotic characteristics but has more complex scheme
to determine wish hash we can drop and what needs to be stored
in order to be able to achive full compression.
Fix SetStateNumHint and GetStateNumHint to properly
set and get the stateNumHints using the lower 24 bits
of the locktime of the commitment transaction as the
lower 24 bits of the obfuscated state number and the
lower 24 bits of the sequence field as the higher 24
bits.
This commit fixes a bug in the wallet’s internal reservation manager
that prevented it from cleaning up the resources used by a reservation
after it was finished running through the workflow.
We fix this issue by ensuring the reservations context is deleted from
the funding limbo.
It is the callers responsibility to properly .Cancel() a reservation in
the case of an error during the funding workflow.
This commit removes the BlockChainIO interface as a dependency to the
LightningChannel struct as the interface is no longer used within the
operation of the LightningChannel.
This commit ensures that we now properly handle and propagate errors
that arise when attempting to create a new channel after the funding
transaction is believed to be confirmed.
A previous edge case would arise when a user attempted to create a new
channel, but their corresponding btcd node wasn’t yet fully synced.
This commit adds support to the wallet’s internal funding workflow for
pushing a certain amount of BTC to the responder’s side for a single
funder workflow as part of the first commitment.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
This commit slightly modifies the channel reservation workflow to
expose the new information conerning the exact confirmation location of
the channel provided by the ChainNotifier. The DispatchChan() method of
the ChannelReservation now also returns the blockHeight and txIndex
where the transaction was ultimately confirmed. This information will
be needed by the fundingManager so it can properly generate the
authenticated channel announcement proofs.
This commit fixes a lingering bug within the channel funding
reservation workflow that caused the address of a channel counter-party
to not be written to disk, resulting in an error on start up. To fix
this, we now properly populate the node’s TCP address when initiating
the reservation.
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 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 existing channel reservation workflow slightly
to thread through the IP address that we were able to reach the node
at, or the one which the node reached us via. Additionally, rather than
using OpenChannel.FullSync() at the end of the reservation workflow, we
now use OpenChannel.FullSyncWithAddr() in order to create the
relationship in the database between the channel, and the p2p node we
created the channel with.
All tests, as well as a portion of the fundingManager have been updated
accordingly,
This commit modifies the lnwallet code and related tests in order to
adhere to the recent field-name change to channeldb.OpenChannel.
Instead of having the field ‘TheirLNID’ which is the sha256 of the
node’s public key, we now instead use the public key directly in all
contexts.
This commit consists of a mass variable renaming to call the pkScript being executed for segwit outputs the `witnessScript` instead of `redeemScript`. The latter naming convention is generally considered to be reserved for the context of BIP 16 execution. With segwit to be deployed soon, we should be using the correct terminology uniformly through the codebase.
In addition some minor typos throughout the codebase has been fixed.
This commit modifies the prior funding workflow to account for fees
when creating the funding output. As a stop gap, the current fee for
the commitment transaction is now hard-coded at 5k satoshis. Once the
fee models are in place this should instead be some high multiple of
the current “average” fee rate within the network, continuing, the
proper fee should be adjusted from the commitment transaction has
outputs are added/removed.
This commit introduces the concept of a manually initiated “force”
closer within the channel state machine. A force closure is a closure
initiated by a local subsystem which broadcasts the current commitment
state directly on-chain rather than attempting to cooperatively
negotiate a closure with the remote party.
A force closure returns a ForceCloseSummary which includes all the
details required for claiming all rightfully owned outputs within the
broadcast commitment transaction.
Additionally two new publicly exported channels are introduced, one
which is closed due a locally initiated force closure, and the other
which is closed once we detect that the remote party has executed a
unilateral closure by broadcasting their version of the commitment
transaction.
This commit performs a major refactor of the current wallet,
reservation, and channel code in order to call into a WalletController
implementation rather than directly into btcwallet.
The current set of wallets tests have been modified in order to test
against *all* registered WalletController implementations rather than
only btcwallet. As a result, all future WalletControllers primary need
to ensure that their implementation passes the current set of tests
(which will be expanded into the future), providing an easy path of
integration assurance.
Rather than directly holding the private keys throughout funding and
channel creation, the burden of securing keys has been shifted to the
specified WalletController and Signer interfaces. All signing is done
via the Signer interface rather than directly, increasing flexibility
dramatically.
During channel funding, rather than creating a txscript.Engine to
verify commitment signatures, regular ECDSA sig verification is now
used instead. This is faster and more efficient.
Finally certain fields/methods within ChannelReservation and
LightningChannel have been exposed publicly in order to restrict the
amount of modifications the prior tests needed to undergo in order to
support testing directly agains the WalletController interface.
This commit modifies the elkrem root derivation for each newly created
channel. First a master elkrem root is derived from the rood HD seed
generated from private wallet data. Next, a HKDF is used with the
secret being the master elkrem root.
This commit refactors the code within lnwallet interacting with the
ChainNotifier to accept, and call against the implementation rather
than a single concrete implementation.
LightningWallet no longer creates it’s own BtcdNotifier implementation
doing construction, now instead accepting a pre-started `ChainNotifier`
interface. All imports have been updated to reflect the new naming
scheme.
This commit changes prior behavior which stored a “hot” commitment
transaction, meaning one which all the sigScript fully assembled and
able to be broadcast.
Instead, we now store the current signature for our commitment
transaction as a separate field within the database and within memory.
As a result, this eliminates a class of bugs which would erroneously
broadcast a fully loaded commitment transaction, either leading to a
loss of funds, or suspending availability to funds for a period of
time.
This update the wallet to implement the new single funder workflow
which uses revocation keys rather than revocation hashes for the
commitment transactions.
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 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.
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.
