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 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 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 returns the BtcWallet wrapper struct back to conformance to
the WalletController interface by adding support for
SubscribeTransactions.
The implementation of the lnwallet.TransactionSubscription consists
simply of a proxy goroutine which forwards notifications from the
wallet’s internal NotificaitonServer.
This commit adds a new simple interface related to the WalletController
which allows for subscribing to new notifications as transactions
relevant to the wallet are seen on at the network and/or mined. The
TransactionSubscription interface will prove useful for building higher
level UI’s on-top of the daemon which update the presentation layer in
response to received notifications.
This commit implements the new ListTransactionDetails method within
btcwallet’s concrete implementation of the WalletController interface.
Both mined and unmined transactions are currently returned via the same
method. Unmined transactions are indicated by their lack of an
inclusion block hash and lack of confirmations.
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 slightly modifies btcwallet’s SignOutputRaw method to work
properly in the case that the pkScript of the output being spent isn’t
one of the template pkScripts (p2pkh, multi-sig, etc). Rather than
examining the address, we now attempt to find the private key which
matches the public key passed within the sign descriptor.
This commit adds full persistence logic of the current lowest
un-revoked height within each commitment chain. The newly added
channeldb methods for record state transitions within both commitment
chains are now utilized. This un-settled HTLC state is now read upon
initialization, with the proper log entries inserted into the state
update log which reflect the garbage collected log right before the
restart.
A new set of tests have been added to exercise a few edge cases around
HTLC persistence to ensure the in-memory log is properly restored based
on the on-disk snapshot.
This commit implements a state update log which is intended the record
the relevant information for each state transition on disk. For each
state transition a delta should be written recording the new state. A
new method is also provided which is able to retrieve a previous
channel state based on a state update #.
At the moment no measures has been taken to optimize the space
utilization of each update on disk. There are several low-hanging
fruits which can be addressed at a later point. Ultimately the update
log itself should be implemented with an append-only flat file at the
storage level. In any case, the high level abstraction should be able
to maintained independent of differences in the on-disk format itself.
This commit removes a flaky assertion within the interaction tests. Due
to differences in final coin selection across tests due to the
pseudo-random nature of map iterations, a single output might be
selected rather than two as we previously expected.
Additionally a duplicate test has been removed, and the locked output tests
simplified a bit.
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 file is no longer needed as each implementation of the
WalletController is expected to handle its own set up via an instance
of the WalletDriver factory struct.
This commit adds the first concrete implementation of the
WalletController interface: BtcWallet. This implementation is simply a
series of wrapper functions are the base btcwallet struct.
Additionally, for ease of use both the BlockChain IO and Signer
interface are also implemented by BtcWallet. Finally a new WalletDriver
implementation has been implemented, and will be register by the init()
method within this new package.
This commit revamps the previous WalletController interface, edging it
closer to a more complete version.
Additionally, this commit also introduces two new interfaces:
BlockchainIO, and Singer along with a new factor driver struct, the
WalletDriver.
This BlockChainIO abstracts read-only access to the blockchain, while
the Singer interface abstracts the signing of inputs from the base
wallet paving the way to hardware wallets, air-gapped signing, etc.
Finally, in order to provide an easy method for selecting a particular
concrete implementation of a WalletController interface, the concept of
registering “WalletDriver”s has been introduced. A wallet driver is
essentially the encapsulation of a factory function capable of create a
new instance of a Wallet Controller.
This commit removes the wrapper functions used to rely on the coinset
package for coin selection. In a future commit the prior behavior will
be replaced by a custom coin selection implementation which estimates
the size of the funding transaction.
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 fixes a bug in the lockTimeToSequence function when mapping
a block-based relative lock time to the proper sequence number.
Applying the mask isn’t necessary since the values are expected to be
blow 65K blocks.
