This commit modifies the login of sent/recv’d wire messages in trace
mode in order utilize the more detailed, and automatically generated
logging statements using pure spew.Sdump.
In order to avoid the spammy messages due to spew printing the
btcec.S256() curve paramter within wire messages with public keys, we
introduce a new logging function to unset the curve paramter to it
isn’t printed in its entirety. To insure we don’t run into any panics
as a result of a nil pointer defense, we now copy the public keys
during the funding process so we don’t run into a panic due to
modifying a pointer to the same object.
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.
We now enforce that the site of all revocation pre-images+hashes (used
for HTLC’s) are now 32-bytes.
Additionally, all payment pre-images are now required to be 32-bytes
not he wire. There also exists a Script level enforcement of the
payment pre-image size at a lower level.
This commit serves to unify the sizes of all hashes/pre-images across
the codebase.
This commit modifies most of the wire messages to uniquely identify any
*active* channels by their funding output. This allows the wire
protocol to support funding transactions which open several channels in
parallel.
Any pending channels created by partial completion of the funding
workflow are to be identified by a uint64 initialized by both sides as
follows: the initiator of the connection starts from 0, while the
listening node starts from (1 << 63). These pending channel identifiers
are expected to be monotonically increasing with each new funding
workflow between two nodes. This identifier is volatile w.r.t to each
connection initiation.
This commit adds some cursory documentation along wit minor field
modifications to all messages which deal with adding HTLC’s, or
updating remote commitment transactions.
The messages for dual funding of channel is left purposefully
undocumented as all initial negotiations will be single funder by
default.
A revamp of the testing infrastructure of lnwire will be committed in
the near future.
* Added description in lnwire/README.md for state machine
* Figured out mutex stuff...
* Started the State Machine (using dummy functions for net/db)
* Minor corrections in wire protocol (changed some names/types)
- Renamed StagingID to HTLCKey of type HTLCKey (uint64)
* Structs and wire messages for HTLCs
* Wire protocol for a state machine with no blocking(!!!)
(I will write the state machine)
TL;DR: Can do multiple HTLC modifications in-flight, dead simple wire
protocol. Both sides can update their Commitments unliaterally without
waiting for the other party's signature. Will have basic/preliminary
notes in the README
* Added **swp to .gitignore because of vim annoyances
