Commit Graph

6517 Commits

Author SHA1 Message Date
Valentine Wallace
0fd6004958
multi: partition lnwire.ChanUpdateFlag into ChannelFlags and MessageFlags
In this commit:

* we partition lnwire.ChanUpdateFlag into two (ChanUpdateChanFlags and
ChanUpdateMsgFlags), from a uint16 to a pair of uint8's

* we rename the ChannelUpdate.Flags to ChannelFlags and add an
additional MessageFlags field, which will be used to indicate the
presence of the optional field HtlcMaximumMsat within the ChannelUpdate.

* we partition ChannelEdgePolicy.Flags into message and channel flags.
This change corresponds to the partitioning of the ChannelUpdate's Flags
field into MessageFlags and ChannelFlags.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2019-01-22 08:42:26 +01:00
Wilmer Paulino
552b71c620
rpcserver: forward gRPC proxy requests to localhost when listening on all interfaces
This prevents certificate issues when accessing the gRPC REST proxy externally.
2019-01-21 16:07:19 -08:00
Olaoluwa Osuntokun
375be936ce
Merge pull request #2314 from wpaulino/chainnotifier-subserver
chainntnfs+lnrpc/chainrpc: add ChainNotifier RPC subserver
2019-01-21 15:19:12 -08:00
Wilmer Paulino
59e2be5306
config: add ChainRPC config 2019-01-21 14:02:00 -08:00
Wilmer Paulino
3d91aa2312
lnrpc/chainrpc: add ChainNotifier subserver registration driver 2019-01-21 14:01:22 -08:00
Wilmer Paulino
1f8eef2833
lnrpc/chainrpc: add ChainNotifier subserver implementation 2019-01-21 14:01:22 -08:00
Wilmer Paulino
5e98af8c99
lnrpc/chainrpc: add ChainNotifier subserver Config 2019-01-21 14:01:22 -08:00
Wilmer Paulino
d06f6c14f5
lnrpc/chainrpc: add ChainNotifier subserver protos 2019-01-21 14:01:20 -08:00
Wilmer Paulino
26d53c64f1
chainntnfs: dispatch block notification for current tip upon registration 2019-01-21 13:58:52 -08:00
Wilmer Paulino
568f8271a0
chainntnfs/neutrinonotify: track best block hash 2019-01-21 13:58:52 -08:00
Wilmer Paulino
060f2f7774
chainntnfs: add Done chan to events to signal reorg safety 2019-01-21 13:58:52 -08:00
Wilmer Paulino
52a80f2d37
chainntnfs/txnotifier: track reorg risk for transactions within ConnectTip 2019-01-21 13:58:52 -08:00
Wilmer Paulino
0c579b110c
chainntnfs: add support to cancel pending registered confirmation 2019-01-21 13:58:52 -08:00
Wilmer Paulino
be2c321c8c
chainntnfs: declare common ErrChainNotifierShuttingDown for all backends 2019-01-21 13:58:52 -08:00
Wilmer Paulino
50650d054e
chainntnfs: include transaction in confirmation details 2019-01-21 13:58:52 -08:00
Wilmer Paulino
5ab30cf7ea
chainntnfs/interface_test: add script dispatch test cases 2019-01-21 13:57:43 -08:00
Wilmer Paulino
83c7f204cd
chainntnfs: modify GetTestTxidAndScript to generate new P2PKH scripts
In this commit, we modify GetTestTxidAndScript to generate new P2PKH
scripts. This is needed to properly test confirmations and spends of
unique scripts on-chain within the set of interface-level test cases.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
52db5ed682
chainntnfs/neutrinonotify: support registration for script spends
In this commit, we extend the NeutrinoNotifier to support registering
scripts for spends notifications. Once the script has been detected as
spent within the chain, a spend notification will be dispatched through
the Spend channel of the SpendEvent returned upon registration.

For scripts that have been spent in the past, the rescan logic has been
modified to match on the script rather than the outpoint. A concurrent
queue for relevant transactions has been added to proxy notifications
from the underlying rescan to the txNotifier. This is needed for
scripts, as we cannot perform a historical rescan for scripts through
`GetUtxo`, like we do with outpoints.

For scripts that are unspent, a filter update is sent to the underlying
rescan to ensure that we match and dispatch on the script when
processing new blocks.

Along the way, we also address an issue where we'd miss detecting that
an outpoint/script has been spent in the future due to not receiving a
historical dispatch request from the underlying txNotifier. To fix this,
we ensure that we always request the backend to notify us of the spend
once it detects it at tip, regardless of whether a historical rescan was
detected or not.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
482f05a3bc
chainntnfs/bitcoindnotify: support registration for script spends
In this commit, we extend the BitcoindNotifier to support registering
scripts for spends notifications. Once the script has been detected as
spent within the chain, a spend notification will be dispatched through
the Spend channel of the SpendEvent returned upon registration.

For scripts that have been spent in the past, the rescan logic has been
modified to match on the script rather than the outpoint. This is done
by re-deriving the script of the output a transaction input is spending
and checking whether it matches ours.

For scripts that are unspent, a request to the backend will be sent to
alert the BitcoindNotifier of when the script was spent by a
transaction. To make this request we encode the script as an address, as
this is what the backend uses to detect the spend. The transaction will
then be proxied through the txUpdates concurrent queue, which will hand
it off to the underlying txNotifier and dispatch spend notifications to
the relevant clients.

Along the way, we also address an issue where we'd miss detecting that
an outpoint/script has been spent in the future due to not receiving a
historical dispatch request from the underlying txNotifier. To fix this,
we ensure that we always request the backend to notify us of the spend
once it detects it at tip, regardless of whether a historical rescan was
detected or not.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
808c6ae660
chainntnfs/btcdnotify: support registration for script spends
In this commit, we extend the BtcdNotifier to support registering
scripts for spends notifications. Once the script has been detected as
spent within the chain, a spend notification will be dispatched through
the Spend channel of the SpendEvent returned upon registration.

For scripts that have been spent in the past, the rescan logic has been
modified to match on the script rather than the outpoint. This is done
by encoding the script as an address.

For scripts that are unspent, a request to the backend will be sent to
alert the BtcdNotifier of when the script was spent by a transaction. To
make this request we encode the script as an address, as this is what
the backend uses to detect the spend. The transaction will then be
proxied through the txUpdates concurrent queue, which will hand it off
to the underlying txNotifier and dispatch spend notifications to the
relevant clients.

Along the way, we also address an issue where we'd miss detecting that
an outpoint/script has been spent in the future due to not receiving a
historical dispatch request from the underlying txNotifier. To fix this,
we ensure that we always request the backend to notify us of the spend
once it detects it at tip, regardless of whether a historical rescan was
detected or not.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
f02590d8c0
chainntnfs/neutrinonotify: support registration for script confirmations
In this commit, we extend the NeutrinoNotifier to support registering
scripts for confirmation notifications. Once the script has been
detected as confirmed within the chain, a confirmation notification will
be dispatched to through the Confirmed channel of the ConfirmationEvent
returned upon registration.

For scripts that have confirmed in the past, the `historicalConfDetails`
method has been modified to determine whether the script has been
confirmed by locating the script in an output of a confirmed
transaction.

For scripts that have yet to confirm, a filter update is sent to the
underlying rescan to ensure that we match and dispatch on the script
when processing new blocks.

Along the way, we also address an issue where we'd miss detecting that a
transaction/script has confirmed in the future due to not receiving a
historical dispatch request from the underlying txNotifier. To fix this,
we ensure that we always update our filters to detect the confirmation
at tip, regardless of whether a historical rescan was detected or not.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
1a41e23bf4
chainntnfs/bitcoindnotify: support registration for script confirmations
In this commit, we extend the BitcoindNotifier to support registering
scripts for confirmation notifications. Once the script has been
detected as confirmed within the chain, a confirmation notification will
be dispatched to through the Confirmed channel of the ConfirmationEvent
returned upon registration.

For scripts that have confirmed in the past, the `historicalConfDetails`
method has been modified to skip the txindex and go straight to scanning
the chain manually if confirmation request is for a script. When
scanning the chain, we'll determine whether the script has been
confirmed by locating the script in an output of a confirmed
transaction.

For scripts that have yet to confirm, they will be properly tracked
within the TxNotifier.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
1323c92947
chainntnfs/btcdnotify: support registration for script confirmations
In this commit, we extend the BtcdNotifier to support registering
scripts for confirmation notifications. Once the script has been
detected as confirmed within the chain, a confirmation notification will
be dispatched to through the Confirmed channel of the ConfirmationEvent
returned upon registration.

For scripts that have confirmed in the past, the `historicalConfDetails`
method has been modified to skip the txindex and go straight to scanning
the chain manually if confirmation request is for a script. When
scanning the chain, we'll determine whether the script has been
confirmed by locating the script in an output of a confirmed
transaction.

For scripts that have yet to confirm, they will be properly tracked
within the TxNotifier.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
72cc843e92
chainntnfs/interface: update docs to note support for scripts 2019-01-21 13:57:43 -08:00
Wilmer Paulino
c72da48111
multi: update to latest ChainNotifier impl New method 2019-01-21 13:57:43 -08:00
Wilmer Paulino
969acf6145
chainntnfs/neutrinonotify: clean up neutrinonotify.New 2019-01-21 13:57:43 -08:00
Wilmer Paulino
686e734e22
chainntnfs/bitcoindnotify: add chainParams parameter to bitcoindnotify.New
In this commit, we add the current chain parameters to the
BitcoindNotifier. This will be used in a future commit in order to
convert outputs scripts into addresses. This is needed since the
bitcoind backend uses these addresses to detect whether the script
encoded within it was spent by a transaction in the chain.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
1ee8d7518c
chainntnfs/btcdnotify: add chainParams parameter to btcdnotify.New
In this commit, we add the current chain parameters to the BtcdNotifier.
This will be used in a future commit in order to convert outputs scripts
into addresses. This is needed since the btcd backend uses these
addresses to detect whether the script encoded within it was spent by a
transaction in the chain.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
7f644019b8
chainntnfs/txnotifier_test: update tests with new registration changes 2019-01-21 13:57:43 -08:00
Wilmer Paulino
c3d5204f09
chainntnfs/txnotifier: refactor ProcessRelevantSpendTx to detect script spends
In this commit, we refactor the TxNotifier's ProcessRelevantSpendTx to
also detect script spends. This can easily be done as the transaction
filtering logic was refactored into its own method in a previous commit.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
8042d4f1c8
chainntnfs/txnotifier: batch update confirm and spends hints for scripts 2019-01-21 13:57:43 -08:00
Wilmer Paulino
f4f5c1ef8b
chainntnfs/txnotifier: support reorg detection for scripts 2019-01-21 13:57:43 -08:00
Wilmer Paulino
83c8ccb3eb
chainntnfs/txnotifier: notify confirmations and spends of scripts at tip 2019-01-21 13:57:43 -08:00
Wilmer Paulino
ecd70deb8c
chainntnfs/txnotifer: detect confirmations and spends of scripts at tip
In this commit, we modify the TxNotifier's ConnectTip method to also
detect whether a registered script has been confirmed or spent on-chain
by a transaction in the connected block. Once detected, notifications
for them will be queued up for dispatch as with txids/outpoints.

We've also refactored the ConnectTip method into smaller and reusable
methods, which will serve useful later.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
b579c23310
chainntnfs/txnotifier: support registration of scripts for spends 2019-01-21 13:57:43 -08:00
Wilmer Paulino
0f4ff2d09c
chainntnfs/txnotifier: support registration of scripts for confirmations 2019-01-21 13:57:43 -08:00
Wilmer Paulino
a0d3b7d9e3
chainntnfs: support caching confirm/spend hints for scripts
In this commit, we refactor the HeightHintCache and its underlying
interfaces to be able to manipulate hints for ConfRequests and
SpendRequests. By doing so, we'll be able to manipulate hints for
scripts if the request includes either a zero hash or a zero outpoint.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
de0adc4d52
chainntnfs/txnotifier: add ConfRequest and SpendRequest structs
These structs allow us to request notifications for either
txids/outpoints or output scripts. We'll be using these in later commits
to index confirmation and spend requests within the TxNotifier.
2019-01-21 13:57:43 -08:00
Wilmer Paulino
cdf2a65db6
build: update deps to support detecting script spends within rescans 2019-01-21 13:57:43 -08:00
Johan T. Halseth
f48c8f91c4
lnd+pilot: use WeightedCombAttachment
We make the default autopilot agent use the WeightedCombAttachment.
Currently it uses only one sub-heuristic, prefAttachment.
2019-01-21 09:44:38 +01:00
Johan T. Halseth
bdbadeaa75
autopilot: add WeightedCombAttachment
This commit defines a new heuristic WeightedCombAttachment that takes a
set of sub-heuristics, and produces a final node score by querying the
sub-heuristics and combining the scores from them according to their
weights.

This way it will look like a regular, single heuristic to the autopilot
agemnt, but can be a more complex combination of several.
2019-01-21 09:44:38 +01:00
Johan T. Halseth
592ce92c72
autopilot/interface+prefattach: scale node scores to range [0.0, 1.0]
To prepare for combinning scores from multiple heuristics, we require the
scores returned from the NodeSores API to be in the range [0.0, 1.0].

The prefAttach heuristic is altered to scale the returned scores such
that the most connected node in the grpah is given a score of 1.0.
2019-01-21 09:44:37 +01:00
Olaoluwa Osuntokun
4537c63dbd
Merge pull request #2504 from Roasbeef/vendor-with-release
build: update release.sh to contain vendor archive + source code
2019-01-18 19:16:36 -08:00
Olaoluwa Osuntokun
b7244244ae
peer: disconnect peers that don't have our required feature bits 2019-01-18 18:30:55 -08:00
Olaoluwa Osuntokun
9c344ec311
Merge pull request #2499 from Roasbeef/code-cont-replace
docs: add new section to contribution guidelines for go mod replace
2019-01-18 18:19:55 -08:00
Olaoluwa Osuntokun
aa5e3fed43
Merge pull request #2503 from cfromknecht/wtserver-reward-script
watchtower/wtserver/server: return valid reward script
2019-01-18 12:51:52 -08:00
Olaoluwa Osuntokun
df45cc19a3
build: update release.sh to contain vendor archive + source code
In this commit, we update the release script to include a directory
containing all of our vendored dependencies. This makes out releases
more self contained as they can be built using `go build -mod=vendor`
without requiring any package fetching.

Additionally, we pacakge the entire source as well.

Fixes #1550.
2019-01-17 23:40:11 -08:00
Conner Fromknecht
f78319d32c
watchtower/wtserver/server: return valid reward script 2019-01-17 22:19:28 -08:00
Conner Fromknecht
7e1b399437
Merge pull request #2494 from halseth/make-flakehunter-build-itest
[trivial] build lnd-itest before flakehunting
2019-01-17 19:22:01 -08:00
Olaoluwa Osuntokun
c815821679
server: require the DLP bit for all incoming/outgoing connections
In this commit, we modify our default local feature bits to require the
Data Loss Protection (DLP) feature to be active. Once full Static
Channel Backups are implemented, if we connect to a peer that doesn't
follow the DLP protocol, then the SCBs are useless, as we may not be
able to recover funds. As a result, in prep for full SCB deployment,
we'll now ensure that any peer we connect to, knows of the DLP bit. This
could be a bit more relaxed and allow _connections_ to non-DLP peers,
but reject channel requests to/from them. However, this implementation is
much simpler.
2019-01-17 16:53:43 -08:00