This commit adds a new package “zpay32”: which is used within the
daemon to encode/decode payment requests. A payment request currently
consists of: the public key of the payee, the payment hash to use, and
finally the amount to send over the network. The encoded payment
request consists of the mentioned fields concatenated to each other, a
cc32 checksum is added, then the blob is finally encoded using zbas32.
I call the resulting scheme “zpay32”.
A number of extensions may be explored in future commits including
adding a version byte, adding “hint” routing information,
cryptographically signed receipts and more,
Use [33]byte for graph vertex representation.
Delete unneeded stuff:
1. DeepEqual for graph comparison
2. EdgePath
3. 2-thread BFS
4. Table transfer messages and neighborhood radius
5. Beacons
Refactor:
1. Change ID to Vertex
2. Test use table driven approach
3. Add comments
4. Make graph internal representation private
5. Use wire.OutPoint as EdgeId
6. Decouple routing messages from routing implementation
7. Delete Async methods
8. Delete unneeded channels and priority buffer from manager
9. Delete unneeded interfaces in internal graph realisation
10. Renamed ID to Vertex
This commit modifies both the Sphinx packet generation and processing
for recent updates to the API.
With the version 1 Sphinx specification, the payment hash is now
included in the MACs in order to thwart any potential replay attacks.
As a result, any attempts to replay previous HTLC packets MUST re-use
the same payment hash, meaning that the first-hop node can simply
settle the HTLC immediately, thwarting the attacker.
Additionally, within the Sphinx packet, each hop now gets a per-hop
payload which contains the necessary details (CTLV value, fee, etc) for
the node to successfully forward the payment. This per-hop payload is
protected by a packet-wide MAC.
This commit adds a REST interface to the existing gRPC server by
employing a simple http proxy auto-generated from the existing protobuf
files. Currently full-support for any streaming RPC’s are currently
untested. In addition to auto-generating a REST proxy server, a
swagger.json is also generated which allows for gRPC-like native
objects with higher-level clients, and also for auto-generated
documentation.
Due to limitations with accepting raw byte strings as parameters, some
RPC’s have been modified to take both raw-bytes and string arguments.
Additionally a new RPC has been added ‘NewWitnessAddress’ since the
proxy doesn’t currently support enum-based arguments.
Currently the proxy server is embedded within the daemon as an active
HTTP server, however we may want to package the proxy server as a
separate binary in the future. Similarly, we may want to add additional
configuration information which controls the optional inclusion of the
REST proxy.
Atm, just like the current gRPC interface, the REST API is fully
unauthenticated. Before moving to an initial alpha release after making
the necessary changes to meet the spec drafted in Milan, authentication
of the RPC interfaces will be addressed.
LIGHT-131, LIGHT-140, LIGHT-138
`lncli showroutingtable` may output routing table as image.
Use graphviz for graph rendering.
Add explicit version dependency for tools. Add error checking.
This commit adds glide integration in order to make lnd builds fully
reproducible. Rather than using “go get” users should now manually pull down
the repo, use glide to fetch+install the dependancies, then manually install
all related binaries.
With this change we no longer have to chase dependancies making breaking API
changes under us. We can manually update the managed dependancies once a new
stable release of a defendant package is released.
Additionally, reproducible builds are a strong requirement in order to securely
distribute future major releases of lnd.
