This commit creates a distint type for the opaque failure reason within
the UpdateFailHTLC message. This new type is needed as this is the only
variable length byte slice within the protocol and therefore requires a
length prefix in order to serialize/deserialize properly.
This commit morphs the prior CancelHTLC into the new UpdateFailHTLC
message and also gets rid of the obsolete HLTCAddReject message while
we’re at it.
The primary change from the CancelHTLC message to the UpdateFailHTLC
message is that the CancelReason is now simply called Reason and that
it’s now an opaque encrypted set of bytes. With this update the failure
messages are now more flexible (they can even carry new
ChannelUpdate’s) and also don’t reveal the exact cause of failure to
intermediate nodes.
'init' message is the first message reveals the features supported or required
by this node. Nodes wait for receipt of the other's features to simplify error
diagnosis where features are incompatible. This message will help negotioate the
the features which are supported by both sides.
This commit adds a new field to the CancelHTLC message which describes
the event that led to an HTLC being cancelled up stream.
A new enum has been added which describers the “why” concerning the
cancellation of the HTLC. Currently the encoding and back propagation
of the errors aren’t properly implemented as defined within the spec.
As a result the current error types provide to privacy as the error are
in plain-site rather doing being properly encrypted.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
This commit removes the older routing/discovery messages from the
unwire package, as we’ll be converging towards BOLT07 in the near-term.
In the mid to far term we’ll be revisiting integrating Flare into the
newer scheme in order to take advantage of its scaling characteristics.
This commit modifies the Alias type to only hold the non-zero portion
of the alias as encoded on the wire. Previously the entire 32-bytes
would be read and stored, including the zeroes at the end used as
padding. Within the constructor, we now parse the alias properly,
discarding the trailing zeroes within the passed byte slice.
Additionally, the .String() method of Alias will now also only print
the non-zero prefix of the decoded alias.
This commit modifies the encoding of signatures on the wire to use
a fixed-size 64-byte format. This change is required as the current spec
draft dictates that all signatures be encoded as `R` and `S` as 32-byte
big-endian integers. With this, signatures are now always a _fixed_ size
slice of bytes on the wire, which is nice to have.
Fixes#83.
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
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.
* 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
* FundingSignAccept and FundingSingComplete had *[]btcec.Signature and
instead it's now []*btcec.Signature to match other slice types.
* Refactored lnwire's when doing readElement/writeElement on slices
Running "go test -v" will show the serialization and deserialization.
Doing the rest of the wire stuff should be *much* faster since I figured
everything out...
