Commit Graph

8586 Commits

Author SHA1 Message Date
Johan T. Halseth
2026d3b45e
Merge pull request #3432 from cfromknecht/bolt11-features
zpay32: BOLT 11 Feature Bits
2019-08-28 15:23:13 +02:00
Conner Fromknecht
1311baf51f
zpay32: add BOLT 11 feature bits and test vectors 2019-08-27 15:51:24 -07:00
Conner Fromknecht
8c2176fbf8
lnwire/features: add EncodeBase32 and DecodeBase32 w/ generic helpers 2019-08-27 15:51:24 -07:00
Conner Fromknecht
2953f3532a
lnwire/features: add SerializeSize32 for base32 encodings 2019-08-27 15:51:24 -07:00
Olaoluwa Osuntokun
3868bdc490
Merge pull request #3405 from wpaulino/chainrpc-sane-defaults
chainntnfs: validate conf/spend ntfn registration parameters
2019-08-26 16:25:06 -07:00
Johan T. Halseth
9ef66f568f
Merge pull request #2203 from ccdle12/reject-htlc-option
htlcswitch+config+server: adding RejectHTLC flag
2019-08-26 14:53:32 +02:00
Johan T. Halseth
d2435a4dc3
Merge pull request #3059 from champo/rpc_drop
lnd: close the wallet unlock grpc server
2019-08-26 14:18:33 +02:00
Olaoluwa Osuntokun
ebb3e987b1
lnrpc/routerrpc: complete JSON naming for mc responses 2019-08-23 16:36:35 -07:00
Olaoluwa Osuntokun
557083c41b
Merge pull request #3372 from joostjager/mc-successes
routing: process payment successes in mission control
2019-08-23 16:33:18 -07:00
Olaoluwa Osuntokun
441b15055b
channeldb: properly compare payment attempts in serialization test 2019-08-23 12:50:25 -07:00
Joost Jager
ff0c5a0d5e
routing: process successes in mission control
This commit modifies paymentLifecycle so that it not only feeds
failures into mission control, but successes as well.
This allows for more accurate probability estimates. Previously,
the success probability for a successful pair and a pair with
no history was equal. There was no force that pushed towards
previously successful routes.
2019-08-23 09:15:41 +02:00
Joost Jager
2594abfba1
routing/test: remove unused parameter in mission control test 2019-08-23 09:15:39 +02:00
Olaoluwa Osuntokun
64c7a0faa8
Merge pull request #3362 from Roasbeef/tlv-onion-payload
multi: update the switch+router to be aware of the new TLV EOB format
2019-08-22 19:10:19 -07:00
Olaoluwa Osuntokun
b1aea41d20
lntest/itest: force dave to use the legacy onion payload in multi-hop pay test
In this commit, we force Dave to use the legacy onion payload for the
multi-hop test to ensure that we're able to properly mix the old and new
formats, and have all nodes properly decode+forward the HTLC.
2019-08-22 18:53:10 -07:00
Olaoluwa Osuntokun
653d557fec
config: add new legacy protocol build tag protected sub-config for legacy onion
In this commit, we add a new build tag protected sub-config for legacy
protocol features. The goal of this addition is to be able to default to
new feature within lnd, but expose hooks at the config level to allow
integration tests to force the old behavior to ensure that we're able to
support both the old+new versions.
2019-08-22 18:53:08 -07:00
Olaoluwa Osuntokun
1345ca2038
server: set new optional global TLV feature bit by default 2019-08-22 18:53:07 -07:00
Olaoluwa Osuntokun
9145c0fd38
lnwire: add new TLV onion feature bits 2019-08-22 18:53:06 -07:00
Olaoluwa Osuntokun
23cc8389f2
multi: add TLV awareness to htlcswitch, pass extra EOB to the invoice registry
In this commit, we update the `HopIterator` to gain awareness of the new
TLV hop payload. The default `HopIterator` will now hide the details of
the TLV from the caller, and return the same `ForwardingInfo` struct in
a uniform manner. We also add a new method: `ExtraOnionBlob` to allow
the caller to obtain the raw EOB (the serialized TLV stream) to pass
around.

Within the link, we'll now pass the EOB information into the invoice
registry. This allows the registry to parse out any additional
information from the EOB that it needs to settle the payment, such as a
preimage shard in the AMP case.
2019-08-22 18:53:05 -07:00
Olaoluwa Osuntokun
c78e3aaa9d
channeldb: update route.Hop serialization to include new EOB related fields
We also include a migration for the existing routes stored on disk.
2019-08-22 18:53:04 -07:00
Olaoluwa Osuntokun
763cb6c09d
lnrpc+lnrpc/routerrpc: add a new TLV record field to the Hop proto
In this commit, we add a new field to the Hop proto to allow callers to
be able to specify TLV records for the SendToRoute call, and also to be
able to display TLV records that were used during regular path finding.

We also update SendPayment to support dest TLV records.
2019-08-22 18:53:03 -07:00
Olaoluwa Osuntokun
4697cfde30
routing: extend path finding to be TLV-EOB aware, allow dest TLV records
In this commit, we extend the path finding to be able to recognize when
a node needs the new TLV format, or the legacy format based on the
feature bits they expose. We also extend the `LightningPayment` struct
to allow the caller to specify an arbitrary set of TLV records which can
be used for a number of use-cases including various variants of
spontaneous payments.
2019-08-22 18:53:01 -07:00
Olaoluwa Osuntokun
5b4c8ac232
routing/route+tlv: add new TLV-EOB awareness to Hop+Route
In this commit, we extend the Hop struct to carry an arbitrary set of
TLV values, and add a new field that allows us to distinguish between
the modern and legacy TLV payload.

We add a new `PackPayload` method that will be used to encode the
combined required routing TLV fields along any set of TLV fields that
were specified as part of path finding.

Finally, the `ToSphinxPath` has been extended to be able to recognize if
a hop needs the modern, or legacy payload.
2019-08-22 18:53:00 -07:00
Olaoluwa Osuntokun
e60b36751c
tlv: display the unknown primitive type in MakePrimitiveRecord error message 2019-08-22 18:52:59 -07:00
Olaoluwa Osuntokun
aea529d9f6
tlv: add new Type() and Encode() methods to Record
In this commit, we add two new method so the `Record` struct: Type() and
Encode(). These are useful when a caller is handling a record and may
not know its underlying type and may need to encode a record in
isolation.
2019-08-22 18:52:58 -07:00
Olaoluwa Osuntokun
ac6f56566e build: point to latest lightning-onion w/ EOB support 2019-08-22 18:52:53 -07:00
Wilmer Paulino
2e122a807b
Merge pull request #3406 from cfromknecht/die-spew
pilot+discovery: die spew
2019-08-22 15:33:56 -07:00
Wilmer Paulino
2cc5891c8c
lnrpc/walletrpc: use current height as height hint for cpfp
In this commit, we address an issue that would cause us to scan from the
genesis block for the spend of an output that we wish to use to raise
the fee of a transaction through CPFP. This was due to setting a 0
height hint when constructing the input required by the sweeper and was
discovered due to the recently added validation checks at the chain
notifier level. We'll now use the current height as the height hint
instead as the sweeper will end up creating a new transaction that
spends the input.
2019-08-22 13:49:42 -07:00
Wilmer Paulino
9e8a1707cc
lnwallet: modify FetchInputInfo to return additional information for utxos 2019-08-22 13:49:41 -07:00
Wilmer Paulino
8b398bdbd1
sweep: remove unnecessary use of FetchInputInfo within CraftSweepAllTx
We already have all of the information required for the outputs from the
ListUnspent method.
2019-08-22 13:49:40 -07:00
Wilmer Paulino
c7bdfe149a
lnwallet/btcwallet: remove internal utxoCache
The cache wasn't really serving a purpose as FetchInputInfo isn't known
to be a hot path. Also, with a planned addition of returning the
confirmation status of an output within FetchInputInfo in a later
commit, caching won't be useful as we'll have to go to disk anyway to
determine the confirmation status.
2019-08-22 13:49:39 -07:00
Wilmer Paulino
a9efb61767
lnwallet: remove irrelevant fields in Utxo struct
These fields are only relevant for spent transaction outputs.
2019-08-22 13:49:38 -07:00
Wilmer Paulino
cb1d6683d9
chainntnfs: acquire TxNotifier lock after closing quit chan
This prevents a deadlock while tearing down the TxNotifier if it's
currently blocked delivering a notification. By closing the quit chan
first, we ensure blocked sends/reads can exit and allow the TxNotifier
to proceed tearing down.
2019-08-22 13:49:38 -07:00
Wilmer Paulino
17b6205f3a
chainntnfs: validate conf/spend ntfn registration parameters
A height hint not being set would cause lnd to scan for the
confirmation/spend of a txid/outpoint/address from genesis.

The number of confirmations not being set within a confirmation request
would cause the internal TxNotifier to deadlock when dispatching
updates.
2019-08-22 13:49:37 -07:00
Wilmer Paulino
7821eb6ffb
chainntnfs: refactor common registration code within RegisterSpendNtfn 2019-08-22 13:49:35 -07:00
Wilmer Paulino
5089311ca1
chainntnfs: refactor common registration code within RegisterConfirmationsNtfn 2019-08-22 13:49:33 -07:00
Olaoluwa Osuntokun
0a5080c144
Merge pull request #3424 from cfromknecht/tlv-limit-decode
tlv: limit decoded record size
2019-08-21 18:17:38 -07:00
Conner Fromknecht
1cc48ceaf5
tlv/stream: create MaxRecordSize, remove lnwire import, add test 2019-08-21 18:12:57 -07:00
nsa
dfd1b38648
tlv: fix panic with large length
This commit fixes a panic where a large length in a record could
cause the DVarBytes function to fail to allocate a byte slice.
2019-08-21 16:48:23 -07:00
Wilmer Paulino
c4ba5577cc
Merge pull request #3366 from wpaulino/prevent-initial-gossip-sync-broadcast
discovery: prevent broadcast of anns received during initial graph sync
2019-08-21 13:07:14 -07:00
Wilmer Paulino
e15e524637
discovery: prevent broadcast of anns received during initial graph sync
There's no need to broadcast these as we assume that online nodes have
already received them. For nodes that were offline, they should receive
them as part of their initial graph sync.
2019-08-21 12:06:33 -07:00
Olaoluwa Osuntokun
216d1e8017
Merge pull request #3419 from Roasbeef/sign-create-key-if-not-found
lnwallet: when signing create account if not found
2019-08-20 20:53:01 -07:00
Olaoluwa Osuntokun
cc4daa04ad
lnwallet: when signing create account if not found
In this commit, we address an edge case that can happen a user rescans
w/ their seed, while retaining their existing `channel.db`. Once they
rescan, if they go to sign for a channel sweep for example, the
commitment key family (actually an account) may not yet have been
created, causing the signing attempt to fail.

We remedy this always creating the account if we go to sign, and the
account isn't found. The change has been structured to make this the
exception, so we'll avoid always needing to do 2 DB hits (check if
account exists, sign), each time we sign.

A new test has been added to exercise this behavior. If the diff from
the `signer.go` file is removed, then the test will fail.
2019-08-20 19:08:03 -07:00
Olaoluwa Osuntokun
2f8d3c4526
Merge pull request #3256 from joostjager/failure-attribution
routing: failure attribution
2019-08-20 16:53:56 -07:00
Conner Fromknecht
c9a6d5bad5
utxonursery: demote building nursery report log to debug
Log can be pretty spammy when using the pendingchannels rpc, which
creates a log for each closing channel. Should help clear up logs for
more pertinent information.
2019-08-20 14:13:05 -07:00
Conner Fromknecht
e2a53f71d0
pilot+discovery: remove info spews 2019-08-20 14:13:05 -07:00
ccdle12
05d0d028bc
htlcswitch+config+server: Adds a rejecthtlc flag that disables forwarded
htlcs

config: Adding RejectHTLC field in config struct

This commit adds a RejectHTLC field in the config struct in config.go.
This allows the user to run lnd as a node that does not accept onward
HTLCs.

htlcswitch/switch: Adding a field RejectHTLC to the switch config

This commit adds a field RejectHTLC to the switch config. When the
switch receives an HTLC it will check this flag and if the HTLC is not
from the source hop, the HTLC will be rejected.

htlcswitch/switch: adding check for RejectHTLC flag and incomingChanID

This commit adds a check when receiving UpdateAddHTLC. The check looks
for the RejectHTLC flag set and whether the HTLC is from the sourceHop
(the local switch). If the HTLC is not from the sourceHop, then we
reject the HTLC and return a FailChannelDisabled error.

server: adding RejectHTLC field to initialization of switch

lnd_test: adding test for RejectHTLC

This commit adds a test which tests that a node with the --rejecthtlc
flag will reject any onward HTLCs but still can receive direct HTLCs and
can send HTLCs.
2019-08-20 11:01:44 +01:00
Olaoluwa Osuntokun
701244012a
Merge pull request #3402 from joostjager/remove-debug-invoice
multi: remove debug invoices
2019-08-19 18:42:34 -07:00
Joost Jager
d9ec158412
routing: stricter payment result interpretation
This commit overhauls the interpretation of failed payments. It changes
the interpretation rules so that we always apply the strongest possible
set of penalties, without making assumptions that would hurt good nodes.

Main changes are:

- Apply different rule sets for intermediate and final nodes. Both types
of nodes have different sets of failures that we expect. Penalize nodes
that send unexpected failure messages.

- Distinguish between direct payments and multi-hop payments. For direct
payments, we can infer more about the performance of our peer because we
trust ourselves.

- In many cases it is impossible for the sender to determine which of
the two nodes in a pair is responsible for the failure. In this
situation, we now penalize bidirectionally. This does not hurt the good
node of the pair, because only its connection to a bad node is
penalized.

- Previously we always penalized the outgoing connection of the
reporting node. This is incorrect for policy related failures. For
policy related failures, it could also be that the reporting node
received a wrongly crafted htlc from its predecessor. By penalizing the
incoming channel, we surely hit the responsible node.

- FailExpiryTooSoon is a failure that could have been caused by any node
up to the reporting node by delaying forwarding of the htlc. We don't
know which node is responsible, therefore we now penalize all node pairs
in the route.
2019-08-17 10:24:09 +02:00
Joost Jager
e7a457f1ce
routing: query bandwidth hints before each payment attempt
Previously the bandwidth hints were only queried once per payment. This
did not allow for concurrent payments changing channel balances.
2019-08-17 10:24:07 +02:00
Joost Jager
67e40d4433
htlcswitch: always assume an onion error for malformed htlc failures
Previously a temporary channel failure was returning for unexpected
malformed htlc failures. This is not what we want to communicate to the
sender, because the sender may apply a penalty to us only.

Returning the temporary channel failure is especially problematic if we
ourselves are the sender and the malformed htlc failure comes from our
direct peer. When interpretating the failure, we aren't able to
distinguish anymore between our channel not having enough balance and
our peer sending an unexpected failure back.
2019-08-17 10:24:05 +02:00