This commit introduces a RetributionStore interface, which
establishes the methods used to access persisted information
regarding breached channels. A RetributionStore is used to
persist retributionInfo regarding all channels for which
the wallet has signaled a breach.
The current design could be improved by moving certain
functionality, e.g. closing channels and htlc links, such
that they are handled by upstream by their respective
subsystems. This was investigated, but deemed preferable to
postpone to a later update to prevent the current
implementation from sprawling amongst too many packages.
The test suite creates a mockRetributionStore and ensures that
it exhibits the same behavior as the retribution store backed
by a channeldb.DB.
This commit adds a breached contract retribution storage layer using
boltdb to the breach arbiter. The breach arbiter now stores retribution
state on disk between detecting a contract breach, broadcasting a
justice transaction that sweeps the channel, and finally witnessing the
justice transaction confirm on the blockchain. It is critical that such
state is persisted on disk, so that if our node restarts at any point
during the retribution procedure, we can recover and continue from the
persisted state.
This commit updates the glide packages in the repo to point to the
latest btcsuite repos. With this change, we’ll now be able to take
advantage of many of the recent updates to the btcsuite package of
repos. One highlight is that after this commit, we’ll now be using
bech32 by default for p2wkh addresses.
This commit updates the installation docs to specify the min golfing
version. Additionally, we ensure that users running on linux will
download the latest version of golfing from their ppa. Finally, we also
now link directly to the golfing page of pre-compiled binaries for
users that seek to grab the source directly from the official goading
website.
Fixes#263.
This commit fixes a bug that could arise if either we had not, or the
remote party had not advertised a routing policy for either outgoing
channel edge. In this commit, we now detect if a policy wasn’t
advertised, falling back to the default routing policy if so.
Fixes#259.
This commit is a precautionary commit put in place in order to ensure
that the logic of macaroon retrieval doesn’t run into a bug triggered
by returning a reference into bolt’s active memory map. This can arise
if one returns a pointer directly read from the database. We seek to
avoid this by instead ensuring all byte slices are fully copied before
returning.
This commit ensures that we *always* populate the ChainHash field when
we’re crafting new channel update messages either due to the periodic
broadcast, or when we’re updating the routing policies of a set of
target channels. Previously, this wasn’t set which would cause nodes to
reject the newly crafted ChannelUpdate messages.
This commit modifies the HTLC integration tests to be mindful of the
max payment size. Rather than sending the payment in one large batch,
we instead now send it in chunks of the max payment size.
This commit modifies the relevant RPC’s to enforce the max payment size
as defined in BOLT-0002. With this commit the largest payment possible
is now 2^32 mSAT, or 4,294,967 satoshis.
This commit adds a new reqQuit channel within SendPayment. The inner
goroutine will use this channel to detect if the request itself has
exited or not. Without this method, we’d possible leak a goroutine if a
client never closed the payment stream.
This commit modifies NewWitnessAddress to return nested p2wkh address.
We do this as this RPC call was put in place to be used within GUI’s to
allow users to deposit funds into their LN wallet. By using nested
p2wkh, we ensure that the generate address that can be used to directly
create channels.
This commit adds to new RPC’s to the Lightning service: UpdateFees and
FeeReport. Additionally, we also update to the latest version of protc,
golang protobuf, and the gRPC gateway.
This commit modifies the way that we create the macaroon database, and
also create the initial macaroons themselves. Rather than creating a
new macaroon DB for each chain, we instead create a single instance for
all chains. Additionally, if the datadir has been modified, and the
macaroon paths haven’t been modified, the macaroons are now scoped to
those paths.
