2016-12-19 09:14:01 +03:00
|
|
|
package routing
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
|
|
|
import (
|
2018-01-31 07:26:26 +03:00
|
|
|
"bytes"
|
2017-06-16 23:37:36 +03:00
|
|
|
"encoding/binary"
|
2017-08-22 09:43:20 +03:00
|
|
|
"fmt"
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
"math"
|
|
|
|
|
2017-03-20 00:15:58 +03:00
|
|
|
"container/heap"
|
|
|
|
|
2018-07-31 10:17:17 +03:00
|
|
|
"github.com/btcsuite/btcd/btcec"
|
|
|
|
"github.com/btcsuite/btcd/chaincfg/chainhash"
|
2018-03-11 06:00:57 +03:00
|
|
|
"github.com/coreos/bbolt"
|
2017-06-16 23:37:36 +03:00
|
|
|
"github.com/lightningnetwork/lightning-onion"
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
"github.com/lightningnetwork/lnd/channeldb"
|
2017-08-22 09:43:20 +03:00
|
|
|
"github.com/lightningnetwork/lnd/lnwire"
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
|
|
|
// HopLimit is the maximum number hops that is permissible as a route.
|
|
|
|
// Any potential paths found that lie above this limit will be rejected
|
|
|
|
// with an error. This value is computed using the current fixed-size
|
|
|
|
// packet length of the Sphinx construction.
|
|
|
|
HopLimit = 20
|
|
|
|
|
|
|
|
// infinity is used as a starting distance in our shortest path search.
|
2018-02-13 03:27:30 +03:00
|
|
|
infinity = math.MaxInt64
|
2018-06-09 23:36:48 +03:00
|
|
|
|
|
|
|
// RiskFactorBillionths controls the influence of time lock delta
|
|
|
|
// of a channel on route selection. It is expressed as billionths
|
|
|
|
// of msat per msat sent through the channel per time lock delta
|
|
|
|
// block. See edgeWeight function below for more details.
|
|
|
|
// The chosen value is based on the previous incorrect weight function
|
|
|
|
// 1 + timelock + fee * fee. In this function, the fee penalty
|
|
|
|
// diminishes the time lock penalty for all but the smallest amounts.
|
|
|
|
// To not change the behaviour of path finding too drastically, a
|
|
|
|
// relatively small value is chosen which is still big enough to give
|
|
|
|
// some effect with smaller time lock values. The value may need
|
|
|
|
// tweaking and/or be made configurable in the future.
|
|
|
|
RiskFactorBillionths = 15
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
)
|
|
|
|
|
2018-03-27 07:00:24 +03:00
|
|
|
// HopHint is a routing hint that contains the minimum information of a channel
|
|
|
|
// required for an intermediate hop in a route to forward the payment to the
|
|
|
|
// next. This should be ideally used for private channels, since they are not
|
|
|
|
// publicly advertised to the network for routing.
|
|
|
|
type HopHint struct {
|
|
|
|
// NodeID is the public key of the node at the start of the channel.
|
|
|
|
NodeID *btcec.PublicKey
|
|
|
|
|
|
|
|
// ChannelID is the unique identifier of the channel.
|
|
|
|
ChannelID uint64
|
|
|
|
|
|
|
|
// FeeBaseMSat is the base fee of the channel in millisatoshis.
|
|
|
|
FeeBaseMSat uint32
|
|
|
|
|
|
|
|
// FeeProportionalMillionths is the fee rate, in millionths of a
|
|
|
|
// satoshi, for every satoshi sent through the channel.
|
|
|
|
FeeProportionalMillionths uint32
|
|
|
|
|
|
|
|
// CLTVExpiryDelta is the time-lock delta of the channel.
|
|
|
|
CLTVExpiryDelta uint16
|
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// ChannelHop describes the channel through which an intermediate or final
|
|
|
|
// hop can be reached. This struct contains the relevant routing policy of
|
|
|
|
// the particular edge (which is a property of the source node of the channel
|
2018-07-31 10:19:49 +03:00
|
|
|
// edge), as well as the total capacity. It also includes the origin chain of
|
2018-06-12 14:04:40 +03:00
|
|
|
// the channel itself.
|
2017-03-21 04:15:50 +03:00
|
|
|
type ChannelHop struct {
|
2018-06-04 23:10:05 +03:00
|
|
|
// Bandwidth is an estimate of the maximum amount that can be sent
|
|
|
|
// through the channel in the direction indicated by ChannelEdgePolicy.
|
|
|
|
// It is based on the on-chain capacity of the channel, bandwidth
|
|
|
|
// hints passed in via SendRoute RPC and/or running amounts that
|
|
|
|
// represent pending payments. These running amounts have msat as
|
|
|
|
// unit. Therefore this property is expressed in msat too.
|
|
|
|
Bandwidth lnwire.MilliSatoshi
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2017-03-21 04:15:50 +03:00
|
|
|
// Chain is a 32-byte has that denotes the base blockchain network of
|
|
|
|
// the channel. The 32-byte hash is the "genesis" block of the
|
|
|
|
// blockchain, or the very first block in the chain.
|
|
|
|
//
|
|
|
|
// TODO(roasbeef): store chain within edge info/policy in database.
|
|
|
|
Chain chainhash.Hash
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2017-03-21 04:15:50 +03:00
|
|
|
*channeldb.ChannelEdgePolicy
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// Hop represents an intermediate or final node of the route. This naming
|
|
|
|
// is in line with the definition given in BOLT #4: Onion Routing Protocol.
|
|
|
|
// The struct houses the channel along which this hop can be reached and
|
|
|
|
// the values necessary to create the HTLC that needs to be sent to the
|
2018-07-31 10:19:49 +03:00
|
|
|
// next hop. It is also used to encode the per-hop payload included within
|
2018-06-12 14:04:40 +03:00
|
|
|
// the Sphinx packet.
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
type Hop struct {
|
2018-06-12 14:04:40 +03:00
|
|
|
// Channel is the active payment channel edge along which the packet
|
|
|
|
// travels to reach this hop. This is the _incoming_ channel to this hop.
|
2017-03-09 01:24:59 +03:00
|
|
|
Channel *ChannelHop
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2017-06-16 23:33:50 +03:00
|
|
|
// OutgoingTimeLock is the timelock value that should be used when
|
|
|
|
// crafting the _outgoing_ HTLC from this hop.
|
|
|
|
OutgoingTimeLock uint32
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
|
|
|
// AmtToForward is the amount that this hop will forward to the next
|
|
|
|
// hop. This value is less than the value that the incoming HTLC
|
|
|
|
// carries as a fee will be subtracted by the hop.
|
2017-08-22 09:43:20 +03:00
|
|
|
AmtToForward lnwire.MilliSatoshi
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
|
|
|
// Fee is the total fee that this hop will subtract from the incoming
|
|
|
|
// payment, this difference nets the hop fees for forwarding the
|
|
|
|
// payment.
|
2017-08-22 09:43:20 +03:00
|
|
|
Fee lnwire.MilliSatoshi
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// edgePolicyWithSource is a helper struct to keep track of the source node
|
|
|
|
// of a channel edge. ChannelEdgePolicy only contains to destination node
|
|
|
|
// of the edge.
|
|
|
|
type edgePolicyWithSource struct {
|
|
|
|
sourceNode *channeldb.LightningNode
|
|
|
|
edge *channeldb.ChannelEdgePolicy
|
|
|
|
}
|
|
|
|
|
2017-08-22 09:43:20 +03:00
|
|
|
// computeFee computes the fee to forward an HTLC of `amt` milli-satoshis over
|
|
|
|
// the passed active payment channel. This value is currently computed as
|
|
|
|
// specified in BOLT07, but will likely change in the near future.
|
2018-02-13 03:27:30 +03:00
|
|
|
func computeFee(amt lnwire.MilliSatoshi,
|
|
|
|
edge *channeldb.ChannelEdgePolicy) lnwire.MilliSatoshi {
|
|
|
|
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
return edge.FeeBaseMSat + (amt*edge.FeeProportionalMillionths)/1000000
|
|
|
|
}
|
|
|
|
|
2017-03-21 04:15:50 +03:00
|
|
|
// isSamePath returns true if path1 and path2 travel through the exact same
|
|
|
|
// edges, and false otherwise.
|
|
|
|
func isSamePath(path1, path2 []*ChannelHop) bool {
|
2017-04-14 00:42:29 +03:00
|
|
|
if len(path1) != len(path2) {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2017-03-21 04:15:50 +03:00
|
|
|
for i := 0; i < len(path1); i++ {
|
|
|
|
if path1[i].ChannelID != path2[i].ChannelID {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
|
|
|
// Route represents a path through the channel graph which runs over one or
|
|
|
|
// more channels in succession. This struct carries all the information
|
|
|
|
// required to craft the Sphinx onion packet, and send the payment along the
|
|
|
|
// first hop in the path. A route is only selected as valid if all the channels
|
|
|
|
// have sufficient capacity to carry the initial payment amount after fees are
|
|
|
|
// accounted for.
|
|
|
|
type Route struct {
|
|
|
|
// TotalTimeLock is the cumulative (final) time lock across the entire
|
|
|
|
// route. This is the CLTV value that should be extended to the first
|
|
|
|
// hop in the route. All other hops will decrement the time-lock as
|
|
|
|
// advertised, leaving enough time for all hops to wait for or present
|
|
|
|
// the payment preimage to complete the payment.
|
|
|
|
TotalTimeLock uint32
|
|
|
|
|
|
|
|
// TotalFees is the sum of the fees paid at each hop within the final
|
|
|
|
// route. In the case of a one-hop payment, this value will be zero as
|
2017-12-18 05:40:05 +03:00
|
|
|
// we don't need to pay a fee to ourself.
|
2017-08-22 09:43:20 +03:00
|
|
|
TotalFees lnwire.MilliSatoshi
|
2017-03-21 04:15:50 +03:00
|
|
|
|
|
|
|
// TotalAmount is the total amount of funds required to complete a
|
|
|
|
// payment over this route. This value includes the cumulative fees at
|
|
|
|
// each hop. As a result, the HTLC extended to the first-hop in the
|
|
|
|
// route will need to have at least this many satoshis, otherwise the
|
|
|
|
// route will fail at an intermediate node due to an insufficient
|
|
|
|
// amount of fees.
|
2017-08-22 09:43:20 +03:00
|
|
|
TotalAmount lnwire.MilliSatoshi
|
2017-03-21 04:15:50 +03:00
|
|
|
|
|
|
|
// Hops contains details concerning the specific forwarding details at
|
|
|
|
// each hop.
|
|
|
|
Hops []*Hop
|
2017-10-11 05:41:47 +03:00
|
|
|
|
|
|
|
// nodeIndex is a map that allows callers to quickly look up if a node
|
|
|
|
// is present in this computed route or not.
|
2017-09-08 04:25:43 +03:00
|
|
|
nodeIndex map[Vertex]struct{}
|
2017-10-11 05:41:47 +03:00
|
|
|
|
|
|
|
// chanIndex is an index that allows callers to determine if a channel
|
|
|
|
// is present in this route or not. Channels are identified by the
|
|
|
|
// uint64 version of the short channel ID.
|
|
|
|
chanIndex map[uint64]struct{}
|
|
|
|
|
|
|
|
// nextHop maps a node, to the next channel that it will pass the HTLC
|
|
|
|
// off to. With this map, we can easily look up the next outgoing
|
|
|
|
// channel or node for pruning purposes.
|
2017-09-08 04:25:43 +03:00
|
|
|
nextHopMap map[Vertex]*ChannelHop
|
2018-01-11 02:15:49 +03:00
|
|
|
|
|
|
|
// prevHop maps a node, to the channel that was directly before it
|
|
|
|
// within the route. With this map, we can easily look up the previous
|
|
|
|
// channel or node for pruning purposes.
|
|
|
|
prevHopMap map[Vertex]*ChannelHop
|
2017-10-11 05:41:47 +03:00
|
|
|
}
|
|
|
|
|
2017-09-08 04:25:43 +03:00
|
|
|
// nextHopVertex returns the next hop (by Vertex) after the target node. If the
|
2017-10-11 05:41:47 +03:00
|
|
|
// target node is not found in the route, then false is returned.
|
2017-09-08 04:25:43 +03:00
|
|
|
func (r *Route) nextHopVertex(n *btcec.PublicKey) (Vertex, bool) {
|
|
|
|
hop, ok := r.nextHopMap[NewVertex(n)]
|
2018-01-31 07:26:26 +03:00
|
|
|
return Vertex(hop.Node.PubKeyBytes), ok
|
2017-10-11 05:41:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// nextHopChannel returns the uint64 channel ID of the next hop after the
|
2018-01-11 02:15:49 +03:00
|
|
|
// target node. If the target node is not found in the route, then false is
|
2017-10-11 05:41:47 +03:00
|
|
|
// returned.
|
2018-01-11 02:15:49 +03:00
|
|
|
func (r *Route) nextHopChannel(n *btcec.PublicKey) (*ChannelHop, bool) {
|
2017-09-08 04:25:43 +03:00
|
|
|
hop, ok := r.nextHopMap[NewVertex(n)]
|
2018-01-11 02:15:49 +03:00
|
|
|
return hop, ok
|
|
|
|
}
|
|
|
|
|
|
|
|
// prevHopChannel returns the uint64 channel ID of the before hop after the
|
|
|
|
// target node. If the target node is not found in the route, then false is
|
|
|
|
// returned.
|
|
|
|
func (r *Route) prevHopChannel(n *btcec.PublicKey) (*ChannelHop, bool) {
|
|
|
|
hop, ok := r.prevHopMap[NewVertex(n)]
|
|
|
|
return hop, ok
|
2017-10-11 05:41:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// containsNode returns true if a node is present in the target route, and
|
|
|
|
// false otherwise.
|
2017-09-08 04:25:43 +03:00
|
|
|
func (r *Route) containsNode(v Vertex) bool {
|
2017-10-11 05:41:47 +03:00
|
|
|
_, ok := r.nodeIndex[v]
|
|
|
|
return ok
|
|
|
|
}
|
|
|
|
|
|
|
|
// containsChannel returns true if a channel is present in the target route,
|
|
|
|
// and false otherwise. The passed chanID should be the converted uint64 form
|
|
|
|
// of lnwire.ShortChannelID.
|
|
|
|
func (r *Route) containsChannel(chanID uint64) bool {
|
|
|
|
_, ok := r.chanIndex[chanID]
|
|
|
|
return ok
|
2017-03-21 04:15:50 +03:00
|
|
|
}
|
|
|
|
|
2017-06-16 23:37:36 +03:00
|
|
|
// ToHopPayloads converts a complete route into the series of per-hop payloads
|
|
|
|
// that is to be encoded within each HTLC using an opaque Sphinx packet.
|
|
|
|
func (r *Route) ToHopPayloads() []sphinx.HopData {
|
|
|
|
hopPayloads := make([]sphinx.HopData, len(r.Hops))
|
|
|
|
|
|
|
|
// For each hop encoded within the route, we'll convert the hop struct
|
|
|
|
// to the matching per-hop payload struct as used by the sphinx
|
|
|
|
// package.
|
|
|
|
for i, hop := range r.Hops {
|
|
|
|
hopPayloads[i] = sphinx.HopData{
|
|
|
|
// TODO(roasbeef): properly set realm, make sphinx type
|
|
|
|
// an enum actually?
|
|
|
|
Realm: 0,
|
|
|
|
ForwardAmount: uint64(hop.AmtToForward),
|
|
|
|
OutgoingCltv: hop.OutgoingTimeLock,
|
|
|
|
}
|
|
|
|
|
|
|
|
// As a base case, the next hop is set to all zeroes in order
|
|
|
|
// to indicate that the "last hop" as no further hops after it.
|
|
|
|
nextHop := uint64(0)
|
|
|
|
|
|
|
|
// If we aren't on the last hop, then we set the "next address"
|
|
|
|
// field to be the channel that directly follows it.
|
|
|
|
if i != len(r.Hops)-1 {
|
|
|
|
nextHop = r.Hops[i+1].Channel.ChannelID
|
|
|
|
}
|
|
|
|
|
|
|
|
binary.BigEndian.PutUint64(hopPayloads[i].NextAddress[:],
|
|
|
|
nextHop)
|
|
|
|
}
|
|
|
|
|
|
|
|
return hopPayloads
|
|
|
|
}
|
|
|
|
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// newRoute returns a fully valid route between the source and target that's
|
|
|
|
// capable of supporting a payment of `amtToSend` after fees are fully
|
2017-03-20 01:15:24 +03:00
|
|
|
// computed. If the route is too long, or the selected path cannot support the
|
|
|
|
// fully payment including fees, then a non-nil error is returned.
|
|
|
|
//
|
2017-03-21 04:11:22 +03:00
|
|
|
// NOTE: The passed slice of ChannelHops MUST be sorted in forward order: from
|
|
|
|
// the source to the target node of the path finding attempt.
|
2018-04-19 17:32:24 +03:00
|
|
|
func newRoute(amtToSend, feeLimit lnwire.MilliSatoshi, sourceVertex Vertex,
|
2017-10-19 07:43:53 +03:00
|
|
|
pathEdges []*ChannelHop, currentHeight uint32,
|
2018-04-19 17:32:24 +03:00
|
|
|
finalCLTVDelta uint16) (*Route, error) {
|
2017-08-03 07:01:49 +03:00
|
|
|
|
|
|
|
// First, we'll create a new empty route with enough hops to match the
|
|
|
|
// amount of path edges. We set the TotalTimeLock to the current block
|
|
|
|
// height, as this is the basis that all of the time locks will be
|
|
|
|
// calculated from.
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
route := &Route{
|
2017-08-03 07:01:49 +03:00
|
|
|
Hops: make([]*Hop, len(pathEdges)),
|
|
|
|
TotalTimeLock: currentHeight,
|
2017-09-08 04:25:43 +03:00
|
|
|
nodeIndex: make(map[Vertex]struct{}),
|
2017-10-11 05:41:47 +03:00
|
|
|
chanIndex: make(map[uint64]struct{}),
|
2017-09-08 04:25:43 +03:00
|
|
|
nextHopMap: make(map[Vertex]*ChannelHop),
|
2018-01-11 02:15:49 +03:00
|
|
|
prevHopMap: make(map[Vertex]*ChannelHop),
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2017-10-11 05:45:09 +03:00
|
|
|
// We'll populate the next hop map for the _source_ node with the
|
|
|
|
// information for the first hop so the mapping is sound.
|
|
|
|
route.nextHopMap[sourceVertex] = pathEdges[0]
|
|
|
|
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
pathLength := len(pathEdges)
|
2017-03-21 04:11:22 +03:00
|
|
|
for i := pathLength - 1; i >= 0; i-- {
|
|
|
|
edge := pathEdges[i]
|
|
|
|
|
2017-10-25 04:27:29 +03:00
|
|
|
// First, we'll update both the node and channel index, to
|
2017-09-08 04:25:43 +03:00
|
|
|
// indicate that this Vertex, and outgoing channel link are
|
2017-10-11 05:41:47 +03:00
|
|
|
// present within this route.
|
2018-01-31 07:26:26 +03:00
|
|
|
v := Vertex(edge.Node.PubKeyBytes)
|
2017-10-11 05:41:47 +03:00
|
|
|
route.nodeIndex[v] = struct{}{}
|
|
|
|
route.chanIndex[edge.ChannelID] = struct{}{}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// If this isn't a direct payment, and this isn't the edge to
|
2018-07-31 10:19:49 +03:00
|
|
|
// the last hop in the route, then we'll also populate the
|
2018-06-12 14:04:40 +03:00
|
|
|
// nextHop map to allow easy route traversal by callers.
|
2017-10-11 05:41:47 +03:00
|
|
|
if len(pathEdges) > 1 && i != len(pathEdges)-1 {
|
|
|
|
route.nextHopMap[v] = route.Hops[i+1].Channel
|
|
|
|
}
|
|
|
|
|
2017-10-25 04:27:29 +03:00
|
|
|
// Now we'll start to calculate the items within the per-hop
|
2018-06-12 14:04:40 +03:00
|
|
|
// payload for the hop this edge is leading to. This hop will
|
|
|
|
// be called the 'current hop'.
|
|
|
|
|
|
|
|
// If it is the last hop, then the hop payload will contain
|
|
|
|
// the exact amount. In BOLT #4: Onion Routing
|
|
|
|
// Protocol / "Payload for the Last Node", this is detailed.
|
|
|
|
amtToForward := amtToSend
|
|
|
|
|
|
|
|
// Fee is not part of the hop payload, but only used for
|
|
|
|
// reporting through RPC. Set to zero for the final hop.
|
2017-10-25 04:27:29 +03:00
|
|
|
fee := lnwire.MilliSatoshi(0)
|
|
|
|
|
2018-07-31 10:19:49 +03:00
|
|
|
// If the current hop isn't the last hop, then add enough funds
|
2018-06-12 14:04:40 +03:00
|
|
|
// to pay for transit over the next link.
|
2017-10-25 04:27:29 +03:00
|
|
|
if i != len(pathEdges)-1 {
|
2018-06-12 14:04:40 +03:00
|
|
|
// We'll grab the per-hop payload of the next hop (the
|
|
|
|
// hop _after_ the hop this edge leads to) in the
|
|
|
|
// route so we can calculate fees properly.
|
|
|
|
nextHop := route.Hops[i+1]
|
|
|
|
|
2018-07-31 10:19:49 +03:00
|
|
|
// The amount that the current hop needs to forward is
|
2018-06-12 14:04:40 +03:00
|
|
|
// based on how much the next hop forwards plus the fee
|
|
|
|
// that needs to be paid to the next hop.
|
|
|
|
amtToForward = nextHop.AmtToForward + nextHop.Fee
|
|
|
|
|
|
|
|
// The fee that needs to be paid to the current hop is
|
2018-07-31 10:19:49 +03:00
|
|
|
// based on the amount that this hop needs to forward
|
2018-06-12 14:04:40 +03:00
|
|
|
// and its policy for the outgoing channel. This policy
|
|
|
|
// is stored as part of the incoming channel of
|
|
|
|
// the next hop.
|
|
|
|
fee = computeFee(amtToForward, nextHop.Channel.ChannelEdgePolicy)
|
2017-10-25 04:27:29 +03:00
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// Now we create the hop struct for the current hop.
|
|
|
|
currentHop := &Hop{
|
2017-10-25 04:27:29 +03:00
|
|
|
Channel: edge,
|
|
|
|
AmtToForward: amtToForward,
|
|
|
|
Fee: fee,
|
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// Accumulate all fees.
|
|
|
|
route.TotalFees += currentHop.Fee
|
2017-12-07 05:45:45 +03:00
|
|
|
|
2018-04-19 17:32:24 +03:00
|
|
|
// Invalidate this route if its total fees exceed our fee limit.
|
|
|
|
if route.TotalFees > feeLimit {
|
|
|
|
err := fmt.Sprintf("total route fees exceeded fee "+
|
|
|
|
"limit of %v", feeLimit)
|
|
|
|
return nil, newErrf(ErrFeeLimitExceeded, err)
|
2018-02-01 01:36:10 +03:00
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// As a sanity check, we ensure that the incoming channel has
|
|
|
|
// enough capacity to carry the required amount which
|
|
|
|
// includes the fee dictated at each hop. Make the comparison
|
|
|
|
// in msat to prevent rounding errors.
|
2018-06-04 23:10:05 +03:00
|
|
|
if currentHop.AmtToForward+fee > currentHop.Channel.Bandwidth {
|
2018-06-12 14:04:40 +03:00
|
|
|
|
2017-08-22 09:43:20 +03:00
|
|
|
err := fmt.Sprintf("channel graph has insufficient "+
|
|
|
|
"capacity for the payment: need %v, have %v",
|
2018-06-04 23:10:05 +03:00
|
|
|
currentHop.AmtToForward+fee,
|
|
|
|
currentHop.Channel.Bandwidth)
|
2017-08-22 09:43:20 +03:00
|
|
|
|
|
|
|
return nil, newErrf(ErrInsufficientCapacity, err)
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2017-06-16 23:33:50 +03:00
|
|
|
// If this is the last hop, then for verification purposes, the
|
2017-09-12 22:27:41 +03:00
|
|
|
// value of the outgoing time-lock should be _exactly_ the
|
|
|
|
// absolute time out they'd expect in the HTLC.
|
2017-06-16 23:33:50 +03:00
|
|
|
if i == len(pathEdges)-1 {
|
2017-10-19 07:43:53 +03:00
|
|
|
// As this is the last hop, we'll use the specified
|
|
|
|
// final CLTV delta value instead of the value from the
|
|
|
|
// last link in the route.
|
|
|
|
route.TotalTimeLock += uint32(finalCLTVDelta)
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
currentHop.OutgoingTimeLock = currentHeight + uint32(finalCLTVDelta)
|
2017-06-16 23:33:50 +03:00
|
|
|
} else {
|
2017-10-19 07:43:53 +03:00
|
|
|
// Next, increment the total timelock of the entire
|
|
|
|
// route such that each hops time lock increases as we
|
|
|
|
// walk backwards in the route, using the delta of the
|
|
|
|
// previous hop.
|
2018-06-26 06:27:46 +03:00
|
|
|
delta := uint32(pathEdges[i+1].TimeLockDelta)
|
|
|
|
route.TotalTimeLock += delta
|
2017-10-19 07:43:53 +03:00
|
|
|
|
2017-06-16 23:33:50 +03:00
|
|
|
// Otherwise, the value of the outgoing time-lock will
|
|
|
|
// be the value of the time-lock for the _outgoing_
|
2017-08-03 07:01:49 +03:00
|
|
|
// HTLC, so we factor in their specified grace period
|
|
|
|
// (time lock delta).
|
2018-06-12 14:04:40 +03:00
|
|
|
currentHop.OutgoingTimeLock = route.TotalTimeLock - delta
|
2017-06-16 23:33:50 +03:00
|
|
|
}
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
route.Hops[i] = currentHop
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2018-01-11 02:15:49 +03:00
|
|
|
// We'll then make a second run through our route in order to set up
|
|
|
|
// our prev hop mapping.
|
|
|
|
for _, hop := range route.Hops {
|
2018-01-31 07:26:26 +03:00
|
|
|
vertex := Vertex(hop.Channel.Node.PubKeyBytes)
|
2018-01-11 02:15:49 +03:00
|
|
|
route.prevHopMap[vertex] = hop.Channel
|
|
|
|
}
|
|
|
|
|
2018-06-12 14:04:40 +03:00
|
|
|
// The total amount required for this route will be the value
|
|
|
|
// that the first hop needs to forward plus the fee that
|
|
|
|
// the first hop charges for this. Note that the sender of the
|
|
|
|
// payment is not a hop in the route.
|
|
|
|
route.TotalAmount = route.Hops[0].AmtToForward + route.Hops[0].Fee
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
|
|
|
return route, nil
|
|
|
|
}
|
|
|
|
|
2017-09-08 04:25:43 +03:00
|
|
|
// Vertex is a simple alias for the serialization of a compressed Bitcoin
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// public key.
|
2017-09-08 04:25:43 +03:00
|
|
|
type Vertex [33]byte
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2017-09-08 04:25:43 +03:00
|
|
|
// NewVertex returns a new Vertex given a public key.
|
|
|
|
func NewVertex(pub *btcec.PublicKey) Vertex {
|
|
|
|
var v Vertex
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
copy(v[:], pub.SerializeCompressed())
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
|
2017-09-08 04:25:43 +03:00
|
|
|
// String returns a human readable version of the Vertex which is the
|
2017-10-11 05:38:50 +03:00
|
|
|
// hex-encoding of the serialized compressed public key.
|
2017-09-08 04:25:43 +03:00
|
|
|
func (v Vertex) String() string {
|
2017-10-11 05:38:50 +03:00
|
|
|
return fmt.Sprintf("%x", v[:])
|
|
|
|
}
|
|
|
|
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// edgeWeight computes the weight of an edge. This value is used when searching
|
2018-06-09 23:36:48 +03:00
|
|
|
// for the shortest path within the channel graph between two nodes. Weight is
|
2018-07-31 10:19:49 +03:00
|
|
|
// is the fee itself plus a time lock penalty added to it. This benefits
|
|
|
|
// channels with shorter time lock deltas and shorter (hops) routes in general.
|
|
|
|
// RiskFactor controls the influence of time lock on route selection. This is
|
2018-06-09 23:36:48 +03:00
|
|
|
// currently a fixed value, but might be configurable in the future.
|
2018-06-04 23:10:05 +03:00
|
|
|
func edgeWeight(lockedAmt lnwire.MilliSatoshi, fee lnwire.MilliSatoshi,
|
|
|
|
timeLockDelta uint16) int64 {
|
2018-06-09 23:36:48 +03:00
|
|
|
// timeLockPenalty is the penalty for the time lock delta of this channel.
|
|
|
|
// It is controlled by RiskFactorBillionths and scales proportional
|
|
|
|
// to the amount that will pass through channel. Rationale is that it if
|
|
|
|
// a twice as large amount gets locked up, it is twice as bad.
|
2018-06-04 23:10:05 +03:00
|
|
|
timeLockPenalty := int64(lockedAmt) * int64(timeLockDelta) *
|
|
|
|
RiskFactorBillionths / 1000000000
|
2018-02-13 03:27:30 +03:00
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
return int64(fee) + timeLockPenalty
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2017-03-21 04:15:50 +03:00
|
|
|
// findPath attempts to find a path from the source node within the
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// ChannelGraph to the target node that's capable of supporting a payment of
|
2017-03-20 01:15:24 +03:00
|
|
|
// `amt` value. The current approach implemented is modified version of
|
|
|
|
// Dijkstra's algorithm to find a single shortest path between the source node
|
|
|
|
// and the destination. The distance metric used for edges is related to the
|
|
|
|
// time-lock+fee costs along a particular edge. If a path is found, this
|
|
|
|
// function returns a slice of ChannelHop structs which encoded the chosen path
|
2018-06-04 23:10:05 +03:00
|
|
|
// from the target to the source. The search is performed backwards from
|
|
|
|
// destination node back to source. This is to properly accumulate fees
|
|
|
|
// that need to be paid along the path and accurately check the amount
|
|
|
|
// to forward at every node against the available bandwidth.
|
2017-10-11 07:39:54 +03:00
|
|
|
func findPath(tx *bolt.Tx, graph *channeldb.ChannelGraph,
|
2018-03-27 07:14:10 +03:00
|
|
|
additionalEdges map[Vertex][]*channeldb.ChannelEdgePolicy,
|
2017-10-11 07:39:54 +03:00
|
|
|
sourceNode *channeldb.LightningNode, target *btcec.PublicKey,
|
2017-09-08 04:25:43 +03:00
|
|
|
ignoredNodes map[Vertex]struct{}, ignoredEdges map[uint64]struct{},
|
2018-06-04 23:10:05 +03:00
|
|
|
amt lnwire.MilliSatoshi, feeLimit lnwire.MilliSatoshi,
|
2018-05-08 07:04:31 +03:00
|
|
|
bandwidthHints map[uint64]lnwire.MilliSatoshi) ([]*ChannelHop, error) {
|
2017-10-11 07:39:54 +03:00
|
|
|
|
|
|
|
var err error
|
|
|
|
if tx == nil {
|
|
|
|
tx, err = graph.Database().Begin(false)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
defer tx.Rollback()
|
|
|
|
}
|
2017-03-20 00:15:58 +03:00
|
|
|
|
2017-03-20 01:15:24 +03:00
|
|
|
// First we'll initialize an empty heap which'll help us to quickly
|
2017-03-20 00:15:58 +03:00
|
|
|
// locate the next edge we should visit next during our graph
|
|
|
|
// traversal.
|
|
|
|
var nodeHeap distanceHeap
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// For each node in the graph, we create an entry in the distance map
|
|
|
|
// for the node set with a distance of "infinity". graph.ForEachNode
|
2018-06-04 23:10:05 +03:00
|
|
|
// also returns the source node, so there is no need to add the source
|
2018-09-06 11:48:46 +03:00
|
|
|
// node explicitly.
|
2017-09-08 04:25:43 +03:00
|
|
|
distance := make(map[Vertex]nodeWithDist)
|
2017-10-17 04:48:21 +03:00
|
|
|
if err := graph.ForEachNode(tx, func(_ *bolt.Tx, node *channeldb.LightningNode) error {
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// TODO(roasbeef): with larger graph can just use disk seeks
|
|
|
|
// with a visited map
|
2018-01-31 07:26:26 +03:00
|
|
|
distance[Vertex(node.PubKeyBytes)] = nodeWithDist{
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
dist: infinity,
|
|
|
|
node: node,
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
additionalEdgesWithSrc := make(map[Vertex][]*edgePolicyWithSource)
|
|
|
|
for vertex, outgoingEdgePolicies := range additionalEdges {
|
2018-08-10 06:47:56 +03:00
|
|
|
// We'll also include all the nodes found within the additional
|
|
|
|
// edges that are not known to us yet in the distance map.
|
2018-03-27 07:14:10 +03:00
|
|
|
node := &channeldb.LightningNode{PubKeyBytes: vertex}
|
|
|
|
distance[vertex] = nodeWithDist{
|
|
|
|
dist: infinity,
|
|
|
|
node: node,
|
|
|
|
}
|
2018-06-04 23:10:05 +03:00
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// Build reverse lookup to find incoming edges. Needed because
|
|
|
|
// search is taken place from target to source.
|
2018-06-04 23:10:05 +03:00
|
|
|
for _, outgoingEdgePolicy := range outgoingEdgePolicies {
|
|
|
|
toVertex := outgoingEdgePolicy.Node.PubKeyBytes
|
|
|
|
incomingEdgePolicy := &edgePolicyWithSource{
|
|
|
|
sourceNode: node,
|
|
|
|
edge: outgoingEdgePolicy,
|
|
|
|
}
|
|
|
|
|
|
|
|
additionalEdgesWithSrc[toVertex] =
|
|
|
|
append(additionalEdgesWithSrc[toVertex],
|
|
|
|
incomingEdgePolicy)
|
|
|
|
}
|
2018-03-27 07:14:10 +03:00
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
sourceVertex := Vertex(sourceNode.PubKeyBytes)
|
|
|
|
|
2018-03-27 07:14:10 +03:00
|
|
|
// We can't always assume that the end destination is publicly
|
|
|
|
// advertised to the network and included in the graph.ForEachNode call
|
2018-08-10 06:47:56 +03:00
|
|
|
// above, so we'll manually include the target node. The target node
|
|
|
|
// charges no fee. Distance is set to 0, because this is the starting
|
|
|
|
// point of the graph traversal. We are searching backwards to get the
|
|
|
|
// fees first time right and correctly match channel bandwidth.
|
2018-03-27 07:14:10 +03:00
|
|
|
targetVertex := NewVertex(target)
|
|
|
|
targetNode := &channeldb.LightningNode{PubKeyBytes: targetVertex}
|
|
|
|
distance[targetVertex] = nodeWithDist{
|
2018-06-04 23:10:05 +03:00
|
|
|
dist: 0,
|
|
|
|
node: targetNode,
|
|
|
|
amountToReceive: amt,
|
|
|
|
fee: 0,
|
2018-03-27 07:14:10 +03:00
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// We'll use this map as a series of "next" hop pointers. So to get
|
|
|
|
// from `Vertex` to the target node, we'll take the edge that it's
|
|
|
|
// mapped to within `next`.
|
|
|
|
next := make(map[Vertex]*ChannelHop)
|
2018-03-27 07:14:10 +03:00
|
|
|
|
|
|
|
// processEdge is a helper closure that will be used to make sure edges
|
|
|
|
// satisfy our specific requirements.
|
2018-06-04 23:10:05 +03:00
|
|
|
processEdge := func(fromNode *channeldb.LightningNode,
|
|
|
|
edge *channeldb.ChannelEdgePolicy,
|
|
|
|
bandwidth lnwire.MilliSatoshi, toNode Vertex) {
|
2018-03-27 07:14:10 +03:00
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
fromVertex := Vertex(fromNode.PubKeyBytes)
|
2018-03-27 07:14:10 +03:00
|
|
|
|
|
|
|
// If the edge is currently disabled, then we'll stop here, as
|
|
|
|
// we shouldn't attempt to route through it.
|
|
|
|
edgeFlags := lnwire.ChanUpdateFlag(edge.Flags)
|
|
|
|
if edgeFlags&lnwire.ChanUpdateDisabled != 0 {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// If this vertex or edge has been black listed, then we'll
|
|
|
|
// skip exploring this edge.
|
2018-06-04 23:10:05 +03:00
|
|
|
if _, ok := ignoredNodes[fromVertex]; ok {
|
2018-03-27 07:14:10 +03:00
|
|
|
return
|
|
|
|
}
|
|
|
|
if _, ok := ignoredEdges[edge.ChannelID]; ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
toNodeDist := distance[toNode]
|
|
|
|
|
|
|
|
amountToSend := toNodeDist.amountToReceive
|
|
|
|
|
|
|
|
// If the estimated band width of the channel edge is not able
|
|
|
|
// to carry the amount that needs to be send, return.
|
|
|
|
if bandwidth < amountToSend {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// If the amountToSend is less than the minimum required
|
|
|
|
// amount, return.
|
2018-06-04 23:10:05 +03:00
|
|
|
if amountToSend < edge.MinHTLC {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// Compute fee that fromNode is charging. It is based on the
|
|
|
|
// amount that needs to be sent to the next node in the route.
|
|
|
|
//
|
2018-09-06 11:48:46 +03:00
|
|
|
// Source node has no predecessor to pay a fee. Therefore set
|
2018-08-10 06:47:56 +03:00
|
|
|
// fee to zero, because it should not be included in the fee
|
|
|
|
// limit check and edge weight.
|
2018-06-04 23:10:05 +03:00
|
|
|
//
|
2018-08-10 06:47:56 +03:00
|
|
|
// Also determine the time lock delta that will be added to the
|
|
|
|
// route if fromNode is selected. If fromNode is the source
|
|
|
|
// node, no additional timelock is required.
|
2018-06-04 23:10:05 +03:00
|
|
|
var fee lnwire.MilliSatoshi
|
|
|
|
var timeLockDelta uint16
|
|
|
|
if fromVertex != sourceVertex {
|
|
|
|
fee = computeFee(amountToSend, edge)
|
|
|
|
timeLockDelta = edge.TimeLockDelta
|
|
|
|
}
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// amountToReceive is the amount that the node that is added to
|
|
|
|
// the distance map needs to receive from a (to be found)
|
|
|
|
// previous node in the route. That previous node will need to
|
|
|
|
// pay the amount that this node forwards plus the fee it
|
|
|
|
// charges.
|
2018-06-04 23:10:05 +03:00
|
|
|
amountToReceive := amountToSend + fee
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// Check if accumulated fees would exceed fee limit when this
|
|
|
|
// node would be added to the path.
|
2018-06-04 23:10:05 +03:00
|
|
|
totalFee := amountToReceive - amt
|
|
|
|
if totalFee > feeLimit {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// By adding fromNode in the route, there will be an extra
|
|
|
|
// weight composed of the fee that this node will charge and
|
2018-08-10 06:47:56 +03:00
|
|
|
// the amount that will be locked for timeLockDelta blocks in
|
|
|
|
// the HTLC that is handed out to fromNode.
|
2018-06-04 23:10:05 +03:00
|
|
|
weight := edgeWeight(amountToReceive, fee, timeLockDelta)
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// Compute the tentative distance to this new channel/edge
|
|
|
|
// which is the distance from our toNode to the target node
|
|
|
|
// plus the weight of this edge.
|
2018-06-04 23:10:05 +03:00
|
|
|
tempDist := toNodeDist.dist + weight
|
2018-03-27 07:14:10 +03:00
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// If this new tentative distance is not better than the current
|
|
|
|
// best known distance to this node, return.
|
|
|
|
if tempDist >= distance[fromVertex].dist {
|
|
|
|
return
|
|
|
|
}
|
2018-03-27 07:14:10 +03:00
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// If the edge has no time lock delta, the payment will always
|
|
|
|
// fail, so return.
|
|
|
|
//
|
|
|
|
// TODO(joostjager): Is this really true? Can't it be that
|
|
|
|
// nodes take this risk in exchange for a extraordinary high
|
|
|
|
// fee?
|
|
|
|
if edge.TimeLockDelta == 0 {
|
|
|
|
return
|
2018-03-27 07:14:10 +03:00
|
|
|
}
|
2018-06-04 23:10:05 +03:00
|
|
|
|
|
|
|
// All conditions are met and this new tentative distance is
|
|
|
|
// better than the current best known distance to this node.
|
2018-08-10 06:47:56 +03:00
|
|
|
// The new better distance is recorded, and also our "next hop"
|
|
|
|
// map is populated with this edge.
|
2018-06-04 23:10:05 +03:00
|
|
|
distance[fromVertex] = nodeWithDist{
|
|
|
|
dist: tempDist,
|
|
|
|
node: fromNode,
|
|
|
|
amountToReceive: amountToReceive,
|
|
|
|
fee: fee,
|
|
|
|
}
|
|
|
|
|
|
|
|
next[fromVertex] = &ChannelHop{
|
|
|
|
ChannelEdgePolicy: edge,
|
|
|
|
Bandwidth: bandwidth,
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add this new node to our heap as we'd like to further
|
|
|
|
// explore backwards through this edge.
|
|
|
|
heap.Push(&nodeHeap, distance[fromVertex])
|
2018-03-27 07:14:10 +03:00
|
|
|
}
|
|
|
|
|
2017-10-11 07:39:54 +03:00
|
|
|
// TODO(roasbeef): also add path caching
|
|
|
|
// * similar to route caching, but doesn't factor in the amount
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// To start, our target node will the sole item within our distance
|
2017-03-20 00:15:58 +03:00
|
|
|
// heap.
|
2018-06-04 23:10:05 +03:00
|
|
|
heap.Push(&nodeHeap, distance[targetVertex])
|
2017-03-20 00:15:58 +03:00
|
|
|
|
|
|
|
for nodeHeap.Len() != 0 {
|
|
|
|
// Fetch the node within the smallest distance from our source
|
|
|
|
// from the heap.
|
2017-03-21 04:15:50 +03:00
|
|
|
partialPath := heap.Pop(&nodeHeap).(nodeWithDist)
|
|
|
|
bestNode := partialPath.node
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// If we've reached our source (or we don't have any incoming
|
2017-03-09 01:24:59 +03:00
|
|
|
// edges), then we're done here and can exit the graph
|
|
|
|
// traversal early.
|
2018-06-04 23:10:05 +03:00
|
|
|
if bytes.Equal(bestNode.PubKeyBytes[:], sourceVertex[:]) {
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now that we've found the next potential step to take we'll
|
2018-06-04 23:10:05 +03:00
|
|
|
// examine all the incoming edges (channels) from this node to
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// further our graph traversal.
|
2018-01-31 07:26:26 +03:00
|
|
|
pivot := Vertex(bestNode.PubKeyBytes)
|
2017-10-11 07:39:54 +03:00
|
|
|
err := bestNode.ForEachChannel(tx, func(tx *bolt.Tx,
|
2017-04-14 23:14:54 +03:00
|
|
|
edgeInfo *channeldb.ChannelEdgeInfo,
|
2018-06-04 23:10:05 +03:00
|
|
|
_, inEdge *channeldb.ChannelEdgePolicy) error {
|
|
|
|
|
|
|
|
// If there is no edge policy for this candidate
|
|
|
|
// node, skip. Note that we are searching backwards
|
|
|
|
// so this node would have come prior to the pivot
|
|
|
|
// node in the route.
|
|
|
|
if inEdge == nil {
|
|
|
|
return nil
|
|
|
|
}
|
2017-03-09 01:24:59 +03:00
|
|
|
|
2018-05-08 07:04:31 +03:00
|
|
|
// We'll query the lower layer to see if we can obtain
|
|
|
|
// any more up to date information concerning the
|
|
|
|
// bandwidth of this edge.
|
|
|
|
edgeBandwidth, ok := bandwidthHints[edgeInfo.ChannelID]
|
|
|
|
if !ok {
|
|
|
|
// If we don't have a hint for this edge, then
|
|
|
|
// we'll just use the known Capacity as the
|
|
|
|
// available bandwidth.
|
|
|
|
edgeBandwidth = lnwire.NewMSatFromSatoshis(
|
|
|
|
edgeInfo.Capacity,
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// Before we can process the edge, we'll need to fetch
|
|
|
|
// the node on the _other_ end of this channel as we
|
|
|
|
// may later need to iterate over the incoming edges of
|
|
|
|
// this node if we explore it further.
|
|
|
|
channelSource, err := edgeInfo.FetchOtherNode(
|
|
|
|
tx, pivot[:],
|
|
|
|
)
|
2018-06-04 23:10:05 +03:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2018-08-10 06:47:56 +03:00
|
|
|
// Check if this candidate node is better than what we
|
|
|
|
// already have.
|
2018-06-04 23:10:05 +03:00
|
|
|
processEdge(channelSource, inEdge, edgeBandwidth, pivot)
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
return nil
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-03-27 07:14:10 +03:00
|
|
|
|
|
|
|
// Then, we'll examine all the additional edges from the node
|
|
|
|
// we're currently visiting. Since we don't know the capacity
|
|
|
|
// of the private channel, we'll assume it was selected as a
|
|
|
|
// routing hint due to having enough capacity for the payment
|
|
|
|
// and use the payment amount as its capacity.
|
2018-06-04 23:10:05 +03:00
|
|
|
bandWidth := partialPath.amountToReceive
|
|
|
|
for _, reverseEdge := range additionalEdgesWithSrc[bestNode.PubKeyBytes] {
|
|
|
|
processEdge(reverseEdge.sourceNode, reverseEdge.edge, bandWidth, pivot)
|
2018-03-27 07:14:10 +03:00
|
|
|
}
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// If the source node isn't found in the next hop map, then a path
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
// doesn't exist, so we terminate in an error.
|
2018-06-04 23:10:05 +03:00
|
|
|
if _, ok := next[sourceVertex]; !ok {
|
2017-03-19 21:40:25 +03:00
|
|
|
return nil, newErrf(ErrNoPathFound, "unable to find a path to "+
|
|
|
|
"destination")
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|
|
|
|
|
2018-06-04 23:10:05 +03:00
|
|
|
// Use the nextHop map to unravel the forward path from source to target.
|
|
|
|
pathEdges := make([]*ChannelHop, 0, len(next))
|
|
|
|
currentNode := sourceVertex
|
|
|
|
for currentNode != targetVertex { // TODO(roasbeef): assumes no cycles
|
|
|
|
// Determine the next hop forward using the next map.
|
|
|
|
nextNode := next[currentNode]
|
|
|
|
|
|
|
|
// Add the next hop to the list of path edges.
|
|
|
|
pathEdges = append(pathEdges, nextNode)
|
|
|
|
|
|
|
|
// Advance current node.
|
|
|
|
currentNode = Vertex(nextNode.Node.PubKeyBytes)
|
2017-03-20 01:15:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// The route is invalid if it spans more than 20 hops. The current
|
|
|
|
// Sphinx (onion routing) implementation can only encode up to 20 hops
|
|
|
|
// as the entire packet is fixed size. If this route is more than 20
|
|
|
|
// hops, then it's invalid.
|
2017-03-21 04:15:50 +03:00
|
|
|
numEdges := len(pathEdges)
|
|
|
|
if numEdges > HopLimit {
|
2017-03-19 21:40:25 +03:00
|
|
|
return nil, newErr(ErrMaxHopsExceeded, "potential path has "+
|
|
|
|
"too many hops")
|
2017-03-20 01:15:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return pathEdges, nil
|
|
|
|
}
|
2017-03-21 04:22:04 +03:00
|
|
|
|
|
|
|
// findPaths implements a k-shortest paths algorithm to find all the reachable
|
|
|
|
// paths between the passed source and target. The algorithm will continue to
|
|
|
|
// traverse the graph until all possible candidate paths have been depleted.
|
|
|
|
// This function implements a modified version of Yen's. To find each path
|
|
|
|
// itself, we utilize our modified version of Dijkstra's found above. When
|
|
|
|
// examining possible spur and root paths, rather than removing edges or
|
2017-09-08 04:25:43 +03:00
|
|
|
// Vertexes from the graph, we instead utilize a Vertex+edge black-list that
|
2017-03-21 04:22:04 +03:00
|
|
|
// will be ignored by our modified Dijkstra's algorithm. With this approach, we
|
|
|
|
// make our inner path finding algorithm aware of our k-shortest paths
|
|
|
|
// algorithm, rather than attempting to use an unmodified path finding
|
|
|
|
// algorithm in a block box manner.
|
2017-10-11 07:39:54 +03:00
|
|
|
func findPaths(tx *bolt.Tx, graph *channeldb.ChannelGraph,
|
|
|
|
source *channeldb.LightningNode, target *btcec.PublicKey,
|
2018-06-04 23:10:05 +03:00
|
|
|
amt lnwire.MilliSatoshi, feeLimit lnwire.MilliSatoshi, numPaths uint32,
|
2018-05-08 07:04:31 +03:00
|
|
|
bandwidthHints map[uint64]lnwire.MilliSatoshi) ([][]*ChannelHop, error) {
|
2017-03-21 04:22:04 +03:00
|
|
|
|
|
|
|
ignoredEdges := make(map[uint64]struct{})
|
2017-09-08 04:25:43 +03:00
|
|
|
ignoredVertexes := make(map[Vertex]struct{})
|
2017-03-21 04:22:04 +03:00
|
|
|
|
|
|
|
// TODO(roasbeef): modifying ordering within heap to eliminate final
|
|
|
|
// sorting step?
|
|
|
|
var (
|
|
|
|
shortestPaths [][]*ChannelHop
|
|
|
|
candidatePaths pathHeap
|
|
|
|
)
|
|
|
|
|
|
|
|
// First we'll find a single shortest path from the source (our
|
|
|
|
// selfNode) to the target destination that's capable of carrying amt
|
|
|
|
// satoshis along the path before fees are calculated.
|
2018-02-13 03:18:44 +03:00
|
|
|
startingPath, err := findPath(
|
2018-03-27 07:14:10 +03:00
|
|
|
tx, graph, nil, source, target, ignoredVertexes, ignoredEdges,
|
2018-06-04 23:10:05 +03:00
|
|
|
amt, feeLimit, bandwidthHints,
|
2018-02-13 03:18:44 +03:00
|
|
|
)
|
2017-03-21 04:22:04 +03:00
|
|
|
if err != nil {
|
|
|
|
log.Errorf("Unable to find path: %v", err)
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Manually insert a "self" edge emanating from ourselves. This
|
|
|
|
// self-edge is required in order for the path finding algorithm to
|
|
|
|
// function properly.
|
|
|
|
firstPath := make([]*ChannelHop, 0, len(startingPath)+1)
|
|
|
|
firstPath = append(firstPath, &ChannelHop{
|
|
|
|
ChannelEdgePolicy: &channeldb.ChannelEdgePolicy{
|
|
|
|
Node: source,
|
|
|
|
},
|
|
|
|
})
|
|
|
|
firstPath = append(firstPath, startingPath...)
|
|
|
|
|
|
|
|
shortestPaths = append(shortestPaths, firstPath)
|
|
|
|
|
|
|
|
// While we still have candidate paths to explore we'll keep exploring
|
|
|
|
// the sub-graphs created to find the next k-th shortest path.
|
2018-02-13 03:18:44 +03:00
|
|
|
for k := uint32(1); k < numPaths; k++ {
|
2017-03-21 04:22:04 +03:00
|
|
|
prevShortest := shortestPaths[k-1]
|
|
|
|
|
|
|
|
// We'll examine each edge in the previous iteration's shortest
|
|
|
|
// path in order to find path deviations from each node in the
|
|
|
|
// path.
|
|
|
|
for i := 0; i < len(prevShortest)-1; i++ {
|
2017-09-08 04:25:43 +03:00
|
|
|
// These two maps will mark the edges and Vertexes
|
2017-03-21 04:22:04 +03:00
|
|
|
// we'll exclude from the next path finding attempt.
|
|
|
|
// These are required to ensure the paths are unique
|
|
|
|
// and loopless.
|
|
|
|
ignoredEdges = make(map[uint64]struct{})
|
2017-09-08 04:25:43 +03:00
|
|
|
ignoredVertexes = make(map[Vertex]struct{})
|
2017-03-21 04:22:04 +03:00
|
|
|
|
|
|
|
// Our spur node is the i-th node in the prior shortest
|
|
|
|
// path, and our root path will be all nodes in the
|
|
|
|
// path leading up to our spurNode.
|
|
|
|
spurNode := prevShortest[i].Node
|
|
|
|
rootPath := prevShortest[:i+1]
|
|
|
|
|
|
|
|
// Before we kickoff our next path finding iteration,
|
|
|
|
// we'll find all the edges we need to ignore in this
|
2018-02-13 03:18:44 +03:00
|
|
|
// next round. This ensures that we create a new unique
|
|
|
|
// path.
|
2017-03-21 04:22:04 +03:00
|
|
|
for _, path := range shortestPaths {
|
|
|
|
// If our current rootPath is a prefix of this
|
2017-04-14 00:44:53 +03:00
|
|
|
// shortest path, then we'll remove the edge
|
2017-03-21 04:22:04 +03:00
|
|
|
// directly _after_ our spur node from the
|
|
|
|
// graph so we don't repeat paths.
|
2017-04-14 00:44:53 +03:00
|
|
|
if len(path) > i+1 && isSamePath(rootPath, path[:i+1]) {
|
2017-03-21 04:22:04 +03:00
|
|
|
ignoredEdges[path[i+1].ChannelID] = struct{}{}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Next we'll remove all entries in the root path that
|
2018-02-13 03:18:44 +03:00
|
|
|
// aren't the current spur node from the graph. This
|
|
|
|
// ensures we don't create a path with loops.
|
2017-03-21 04:22:04 +03:00
|
|
|
for _, hop := range rootPath {
|
2018-01-31 07:26:26 +03:00
|
|
|
node := hop.Node.PubKeyBytes
|
|
|
|
if node == spurNode.PubKeyBytes {
|
2017-03-21 04:22:04 +03:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2018-01-31 07:26:26 +03:00
|
|
|
ignoredVertexes[Vertex(node)] = struct{}{}
|
2017-03-21 04:22:04 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// With the edges that are part of our root path, and
|
2017-09-08 04:25:43 +03:00
|
|
|
// the Vertexes (other than the spur path) within the
|
2017-03-21 04:22:04 +03:00
|
|
|
// root path removed, we'll attempt to find another
|
|
|
|
// shortest path from the spur node to the destination.
|
2018-02-13 03:18:44 +03:00
|
|
|
spurPath, err := findPath(
|
2018-03-27 07:14:10 +03:00
|
|
|
tx, graph, nil, spurNode, target,
|
2018-06-04 23:10:05 +03:00
|
|
|
ignoredVertexes, ignoredEdges, amt, feeLimit,
|
2018-05-08 07:04:31 +03:00
|
|
|
bandwidthHints,
|
2018-02-13 03:18:44 +03:00
|
|
|
)
|
2017-03-21 04:22:04 +03:00
|
|
|
|
|
|
|
// If we weren't able to find a path, we'll continue to
|
|
|
|
// the next round.
|
2017-03-19 21:40:25 +03:00
|
|
|
if IsError(err, ErrNoPathFound) {
|
2017-03-21 04:22:04 +03:00
|
|
|
continue
|
|
|
|
} else if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create the new combined path by concatenating the
|
|
|
|
// rootPath to the spurPath.
|
2017-04-14 00:48:11 +03:00
|
|
|
newPathLen := len(rootPath) + len(spurPath)
|
|
|
|
newPath := path{
|
|
|
|
hops: make([]*ChannelHop, 0, newPathLen),
|
|
|
|
dist: newPathLen,
|
|
|
|
}
|
|
|
|
newPath.hops = append(newPath.hops, rootPath...)
|
|
|
|
newPath.hops = append(newPath.hops, spurPath...)
|
2017-03-21 04:22:04 +03:00
|
|
|
|
2017-08-16 05:56:28 +03:00
|
|
|
// TODO(roasbeef): add and consult path finger print
|
|
|
|
|
2017-03-21 04:22:04 +03:00
|
|
|
// We'll now add this newPath to the heap of candidate
|
|
|
|
// shortest paths.
|
2017-04-14 00:48:11 +03:00
|
|
|
heap.Push(&candidatePaths, newPath)
|
2017-03-21 04:22:04 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// If our min-heap of candidate paths is empty, then we can
|
|
|
|
// exit early.
|
|
|
|
if candidatePaths.Len() == 0 {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
// To conclude this latest iteration, we'll take the shortest
|
|
|
|
// path in our set of candidate paths and add it to our
|
|
|
|
// shortestPaths list as the *next* shortest path.
|
|
|
|
nextShortestPath := heap.Pop(&candidatePaths).(path).hops
|
|
|
|
shortestPaths = append(shortestPaths, nextShortestPath)
|
|
|
|
}
|
|
|
|
|
|
|
|
return shortestPaths, nil
|
routing: rewrite package to conform to BOLT07 and factor in fees+timelocks
This commit overhauls the routing package significantly to simplify the
code, conform to the rest of the coding style within the package, and
observe the new authenticated gossiping scheme outlined in BOLT07.
As a major step towards a more realistic path finding algorithm, fees
are properly calculated and observed during path finding. If a path has
sufficient capacity _before_ fees are applied, but afterwards the
finalized route would exceed the capacity of a single link, the route
is marked as invalid.
Currently a naive weighting algorithm is used which only factors in the
time-lock delta at each hop, thereby optimizing for the lowest time
lock. Fee calculation also isn’t finalized since we aren’t yet using
milli-satoshi throughout the daemon. The final TODO item within the PR
is to properly perform a multi-path search and rank the results based
on a summation heuristic rather than just return the first (out of
many) route found.
On the server side, once nodes are initially connected to the daemon,
our routing table will be synced with the peer’s using a naive “just
send everything scheme” to hold us over until I spec out some a
efficient graph reconciliation protocol. Additionally, the routing
table is now pruned by the channel router itself once new blocks arrive
rather than depending on peers to tell us when a channel flaps or is
closed.
Finally, the validation of peer announcements aren’t yet fully
implemented as they’ll be implemented within the pending discovery
package that was blocking on the completion of this package. Most off
the routing message processing will be moved out of this package and
into the discovery package where full validation will be carried out.
2016-12-27 08:20:26 +03:00
|
|
|
}
|