The number and the name will be separate on the rpc level, so we remove
the feature bit from the string. Currently this method is unused apart
from maybe in some rare logging instances.
This commit removes an unnecessarely large 32 byte buffer in favor of
a small 2 byte buffer and cleans up type conversion between uint16
and uint32 values.
This commit adds the feature bit and additional fields
required in `open_channel` and `accept_channel` wire
messages for `option_upfront_shutdown_script`.
This commit introduces a feature.Manager, which derives feature vectors
for various contexts within the daemon. The sets can be described via a
staticly compiled format, which makes any runtime adjustments to the
feature sets when the manager is initialized.
In this commit we change path finding to no longer consider all channels
between a pair of nodes individually. We assume that nodes forward
non-strict and when we attempt a connection between two nodes, we don't
want to try multiple channels because their policies may not be identical.
Having distinct policies for channel to the same peer is against the
recommendation in the spec, but it happens in the wild. Especially since
we recently changed the default cltv delta value.
What this commit introduces is a unified policy. This can be looked upon
as the greatest common denominator of all policies and should maximize
the probability of getting the payment forwarded.
Extends the invalid payment details failure with the new accept height
field. This allows sender to distinguish between a genuine invalid
details situation and a delay caused by intermediate nodes.
Align naming better with the lightning spec. Not the full name of the
failure (FailIncorrectOrUnknownPaymentDetails) is used, because this
would cause too many long lines in the code.
Methods on failure message types used to be defined on value receivers.
This allowed assignment of a failure message to ForwardingError both as
a value and as a pointer. This is error-prone, especially when using a
type switch.
In this commit the failure message methods are changed so that they
target pointer receivers.
Two instances where a value was assigned instead of a reference are
fixed.
In this commit, we modify the decoding of the FailUnknownPaymentHash
message to ensure we're able to fully decode the legacy serialization of
the onion error. We do this by catching the `io.EOF` error as it's
returned when _no_ bytes are read. If this is the case, then only the
error type was serialized and not also the optional amount.
In this commit, we fix a bug in the way we defined our even/odd features
for a particular feature. The check for if a feature bit is part of a
pair assumes that the pair bit has the exact same name as the bit being
queried. The way we defined our feature map didn't take note of this
assumption, as a result, any attempts to require a new bit moving from
optional to required would fail since the bit would be found, but the
names differed.
In this commit, we deprecate the `IncorrectHtlcAmount` onion error.
We'll still decode this error to use when retrying paths, but we'll no
longer send this ourselves. The `UnknownPaymentHash` error has been
amended to also include the value of the payment as well. This allows us
to worry about one less error.
In this commit, we add a field to the ChannelUpdate
denoting the maximum HTLC we support sending over
this channel, a field which was recently added to the
spec.
This field serves multiple purposes. In the short
term, it enables nodes to signal the largest HTLC
they're willing to carry, allows light clients who
don't verify channel existence to have some guidance
when routing HTLCs, and finally may allow nodes to
preserve a portion of bandwidth at all times.
In the long term, this field can be used by
implementations of AMP to guide payment splitting,
as it becomes apparent to a node the largest possible
HTLC one can route over a particular channel.
This PR was made possible by the merge of #1825,
which enables older nodes to properly retain and
verify signatures on updates that include new fields
(like this new max HTLC field) that they haven't yet
been updated to recognize.
In addition, the new ChannelUpdate fields are added to
the lnwire fuzzing tests.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
In this commit, we fix the problem where it's annoying to parse a
bitfield printed out in decimal by writing a String method for the
ChanUpdate[Chan|Msg]Flags bitfield.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
In this commit:
* we partition lnwire.ChanUpdateFlag into two (ChanUpdateChanFlags and
ChanUpdateMsgFlags), from a uint16 to a pair of uint8's
* we rename the ChannelUpdate.Flags to ChannelFlags and add an
additional MessageFlags field, which will be used to indicate the
presence of the optional field HtlcMaximumMsat within the ChannelUpdate.
* we partition ChannelEdgePolicy.Flags into message and channel flags.
This change corresponds to the partitioning of the ChannelUpdate's Flags
field into MessageFlags and ChannelFlags.
Co-authored-by: Johan T. Halseth <johanth@gmail.com>
In this commit we fix a compatibility issue with other implementations.
Before this commit, when writing out an onion error that includes a
`ChannelUpdate` we would use the `MaxPayloadLength` to get the length to
encode. However, a recent update has modified that to be the max
`brontide` payload length as it's possible to pad out the message with
optional fields we're unaware of. As a result, we would always write out
a length of 65KB or so. This didn't effect our parser as we ignore the
length and decode the channel update directly as we don't need the
length to do that. However, other implementations depended on the length
rather than just reading the channel update, meaning that they weren't
able to decode our onion errors that had channel updates.
In this commit we fix that by introducing a new
`writeOnionErrorChanUpdate` which will write out the precise length
instead of using the max payload size.
Fixes#2450.
In this commit, we ensure that when we read node aliases from the wire,
we ensure that they're valid. Before this commit, we would read the raw
bytes without checking for validity which could result in us writing in
invalid node alias to disk. We've fixed this, and also updated the
quickcheck tests to generate valid strings.
In this commit, we export the ReadElements and WriteElements functions.
We do this as exporting these functions makes it possible for outside
packages to define serializations which use the BOLT 1.0 wire format.
In this commit we add a check to HtlcSatifiesPolicy to verify that the
time lock for the outgoing htlc that is requested in the onion packet
isn't too far in the future.
Without this check, anyone could force an unreasonably long time lock on
the forwarding node.
This commit adds the required feature name to our
set of local known features. This will allow other
peers connecting to us to set the required gossip
queries feature bit. This is required for the
subsequent commits, which instruct the server to
set the bit depending on user configured preferences.
In this commit, we add a new field to all the existing gossip messages:
ExtraOpqueData. We do this, as before this commit, if we came across a
ChannelUpdate message with a set of optional fields, then we wouldn't be
able to properly parse the signatures related to the message. If we
never corrected this behavior, then we would violate the forwards
compatible principle we use when parsing existing messages.
As these messages can now be padded out to the max message size, we've
increased the MaxPayloadLength value for all of these messages.
Fixes#1814.
In this commit, we add a compatibility mode for older version of
clightning to ensure that we're able to properly parse all their channel
updates. An older version of c-lightning would send out encapsulated
onion error message with an additional type byte. This would throw off
our parsing as we didn't expect the type byte, and so we always 2 bytes
off. In order to ensure that we're able to parse these messages and make
adjustments to our path finding, we'll first check to see if the type
byte is there, if so, then we'll snip off two bytes from the front and
continue with parsing. if the bytes aren't found, then we can proceed as
normal and parse the request.
In this commit, we alter the behavior of the regular
short channel id encoding, such that it returns a nil
slice if the decoded number of elements is 0. This is
done so that it matches the behavior of the zlib
decompression, allowing us to test both in using the
same corpus.
Modifies the behavior of the quick test for
MsgQueryShortChanIDs, such that the generated
slice of expected short chan ids is always nil
if no elements are returned. This mimics the
behavior of the zlib decompression, where
elements are appended to the slice, instead of
assigning to preallocated slice.
In this commit, we add a new package level mutex. Each time we decode a
new set of chan IDs w/ zlib, we also grab this mutex. The purpose here
is to ensure that we only EVER allocate the maxZlibBufSize globally
across all peers. Otherwise, it may be possible for us to allocate up to
64 MB for _each_ peer, exposing an easy OOM attack vector.
In this commit, we implement zlib encoding and decoding for the channel
range queries. Notably, we utilize an io.LimitedReader to ensure that we
can enforce a hard cap on the total number of bytes we'll ever allocate
in a decoding attempt.
In this commit, we fix a slight bug in the parsing of encoded short
channel ID's. Before this commit, we would always assume that the remote
peer was sending us the sorted+encoded variant of the short channel
ID's. In the case that they weren't (as there isn't yet a feature bit),
we would assert this check and fail early as atm we don't support any
sort of compression.
In this commit, we add recognition of the data loss protected feature
bit. We already implement the full feature set, but then never added the
bit to our set of known features.
In this commit, we fix a minor deviation in our implementation from the
specification. Before if we encountered an unknown error type, we would
disconnect the peer. Instead, we’ll now just continue along parsing the
remainder of the messages. This was flared up recently by some
c-lightning related incompatibilities that emerged on main net.
In this commit, we modify lnwire.MilliSatoshi to be an unsigned
integer. We do this as all values within the specification are meant to
be unsigned unless otherwise specified. Our usage of signed integers to
this date has caused some compatibility issues with the other
implementations, so this is the first step to reconciling these
compatibility issues.
In this commit, we replace all instances of *btcec.PublicKey within the
announcement messages with a simple [33]byte. We do this as usually we
don’t need to immediately validate an announcement, therefore we can
avoid the scalar multiplications during decoding.
In this commit, we add a new signature type. We’ll use this type to
avoid fully decoding a signature on the wire into a btcec.Signature.
This type is only really needed when we need to do signature
validation, as a result, always encoding it is a waste. Several helper
methods have been added to the new struct in order to ensure that we
can use it in the existing codebase without substantial issues.
This commit adds the `lnnet` package which contains an
implementation of the newly created LightningNet interface which
multiplexes the Dial and DNS-related functions to use net
by default and torsvc if a flag is specified. This modularization
makes for cleaner code.
This commit alters the NodeAlias String method to trim null-bytes from
the end of the alias. This is helpful for presentation in contexts such
as the GetInfo response.
In this commit, we add additional detail in the error return hen were’e
unable to properly decode an encapsulated error. This additional
logging was added with the goal of being able to track down a lingering
bug, where at times lnd cannot decode a TemporaryChannelFailure
message.
This changes the circuit map internals and API to reference circuits
by a primary key of (channel ID, HTLC ID) instead of paymnet
hash. This is because each circuit has a unique offered HTLC, but
there may be multiple circuits for a payment hash with different
source or destination channels.
In this commit, we add a new type to the lnwire package:
ChanUpdateFlag. This type represent the bitfield that’s used within the
ChannelUpdate message to give additional details as how the message
should be interpreted.
In this commit we correct an off by one error on the Shutdown and
ClosingSigned message types. Additionally, we fix an error related to
the numbering of the UpdateFee message. With this we, gain proper
compatibility with the other implementations when it comes to
commitment hygiene, and also the cooperative closure process.
Early in the lifetime of the project here were a few files we either
copied entirely, or used as the basis for code within lnd. Before this
PR, this was not recognized by retaining the original copyright. With
this commit, we remedy that by explicitly noting the copyright in the
relevant files.
Fixes#423.
In this commit, we add support within lnwire for the optional dataloss
fields in ChannelReestablish. With these fields, it’s possible to:
verify that the remote node really knows of the state of our prior
local commitment, and also that they’ve sent us the current commitment
point for their current state.
In the event of dataloss, it’s possible for the party which lost data
to claim their commitment output in the remote party’s commitment if
they broadcast their current commitment transaction.
In this commit, we begin implementing the latest spec change to reduce
the attack surface on online channels. In this commit, we introduce a
distinct HTLC base point which will be used to sign the second-level
HTLC transactions for each active HLTC on the commitment transaction of
the remote node. With this, we allow the commitment key to remain
offline, as it isn’t needed in routine channel updates, unless we need
to go to chain.
For Part 1 of Issue #275. Create isolated private struct in
networkHandler goroutine that will de-duplicate
announcements added to the batch. The struct contains maps
for each of channel announcements, channel updates, and
node announcements to keep track of unique announcements.
The struct has a Reset method to reset stored announcements, an
AddMsg(lnwire.Message) method to add a new message to the current
batch, and a Batch method to return the set of de-duplicated
announcements.
Also fix a few minor typos.
In this commit the reestablish message have been added, which serves as
channel state synchronization message. Before exchanging the messages
for particular channel peers have to send it to each other as the
first message in order to be sure that non of the updates have been
lost because of the previous disconnect.
In this commit we add a new type to the lnwire package: FundingFlag.
This type will serve as an enum to describe the possible flags that can
be used within the ChannelFlags field in the OpenChannel struct.
We also define the first assigned flag: FFAnnounceChannel, which
indicates if the initiator of the funding flow wishes to announce the
channel to the greater network.
This is a rewrite of feature vectors in lnwire. This has a few
benefits:
1) a simpler interface
2) separate structs for a plain set of feature bits and a feature
vector with associated feature names
their respective feature sets
3) loosened requirements that bits MUST be assigned in pairs
4) fix endianness of encoding/decoding
This commit fixes an incorrectly calculated size of a
*FeatureVector in the serializedSize() function. go-fuzz
found that when calling NewFeatureVectorFromReader, if
a flag is invalid, it is not added to f.flags. However,
it will skip the index that wasn't included. This
becomes a problem when serializedSize() calculates the
length of f.flags via len() which can lead to an index
out of range since certain flags may be missing.
This commit fixes an existing deviation in the way we encode+decode the
addresses within the NodeAnnouncement message with that of the
specification. Prior to this commit, we would encode the _number_ of
addresses, rather than the number of bytes it takes to encode all the
addresses.
In this commit, we fix this mistake by properly writing out the total
number of bytes, modifying our parsing to take account of this new
encoding.
This commit fixes an existing, unnoticed bug within the lnwire.
NewChanIDFromOutPoint function. Two lingering issues cause the function
to not do anything at all, meaning that the channel ID, would be the
exact same as the actual txid passed in.
The first issue was that the xorTxid function wasn’t actually XOR’ing
the last two bytes. This was due to the fact that the function wasn’t
taking a pointer to the target ChannelID, meaning that the mutation
wouldn’t be seen outside of the scope of the function. Second, we had
our slicing reversed, rather than buf[30:], we were using buf[:30],
meaning that we were weren’t properly filling the buffer with the lower
2-bytes of the passed index.
This commit modifies the main test loop within
TestChannelIDOutPointConversion stricter. With this commit, we now
ensure that the conversion function actually does _something_. This is
the first in a series of commits to fix a recently discovered bug
within the outpoint to channel ID conversion routines.
This is a very simple bug that go-fuzz found. If length of an address
within CloseSigned is greater than 34, a runtime error: slice bounds out
of range happens. An error should be returned instead.
In this commit we reverse the ordering of the MinAcceptDepth and
HltcMinimum fields within the AcceptChannel message. Previously, the
order of these two fields were reversed, meaning the remote peer
would’ve attempted to parse the MinAcceptDepth (as we intended), as
part of the HtlcMinimum, leading to a garbage value.
This commit fixes a diversion from the way the UpdateAddHTLC message is
defined within the specification. We had the HTLC expiry value in the
wrong place on the wire, which meant that we couldn’t parse the
messages as sent by the other LN implementations.
This corrects the fuzz test in TestLightningWireProtocol for
MsgCommitSig to avoid creating an empty slice since the decoded message
only creates a slice when there are greater than zero signatures and an
empty slice is not considered equal to a nil slice under reflection.
This can be tested by running the TestLightningWireProtocol 1000 times
in a loop with and without this change.
This commit does away with the ErrorCode field in order to ensure that
we’re properly compatible with BOLT-0002. In the future the error code
field may be re-introduced as it’s much easier to check against an
internet error rather than interpret a byte slice describing the error.
This commit modifies the NodeAnnouncement message to ensure that it
matches the current spec ordering. The spec was recently modified to
place the feature vector first to allow for future changes to the
fields to be forwards compatible.
This commit updates the encoding/decoding for the onion errors to
properly match BOLT-0004. This commit does to major things: we increase
the max message size to 256 bytes to account for recent modifications
to the ChannelUpdate message, and also fold in the error code into the
failure message encapsulation itself.
This commit adds a new type to the lnwire package: MilliSatoshi. A
milli-satoshi is simply 1/1000th of a satoshi, and will be used for all
internal accounting when sending payments, calculating fees, updating
commitment state, etc. Two helper methods are added: ToBTC(), and
ToSatoshis() to make manipulation of the values easy.
This commit adds a new field to the CommitSig message: HtlcSigs. This
new field will house signatures for each of the HTLC’s on the newly
created commitment state. This addition allows us to implement the new
commitment transaction structure outlined within the specification
which modifies HTLC’s such that the claiming process is now a two-phase
process. The first state transitions an HTLC to the delay+claim state,
and the second state (after the delay has passed) allows the
broadcaster of the commitment transaction to sweep the HTLC’s.
Fixes#61.
This commit modifies the readElement and writeElement functions to add
the capability of reading/writing a slice of btcec.Signature. This new
case is required for the upcoming commit which will modify the
CommitSig message to include a field which houses signatures of reach
HTLC on the commitment transaction.
This commit adds the new set of single funder messages from the
specification. As a result, after this commit and a follow up, all of
our messages will directly line up with those that are detailed within
the specification.
The new set of funding messages are very similar to our prior ones,
aside from the main difference of the addition of several channel level
constraints that give nodes control over their exposure, throughput,
and other values.
This commit modifies the RevokeAndAck message in order to bring it more
in line with the current draft of the specification. The prior version
was based on a version that used a revocation hash for HTLC’s and a
revocation key for commitment outputs. The current commitment design
uses revocation keys uniformly throughout.
This commit removes the original single funder wire messages as they’ve
now been deprecated by the new commitment and HTLC structure within the
latest draft of the specification.
In this commit BOLT#4 specification message have been added to the
lnwire package. This messsage is needed in order to notify payment
sender that forwarding node unable to parse the onion blob.
In this commit onion routing error from BOLT#4 have been added, the
initial error construction have been splitted on two parts: The first
part which contains the actual data will reside inside the lnwire
package because it contains all necessary function to decode/encode
the data. The second part obfuscation and hmac checking will resides
inside the lighting-onion package because it requires the key
generation.
This commit updates the OnionPacketSize constant in order to reflect
the size of the onion payload as a result of the recent changes to the
sphinx packet format in the specification.
This commit gives the start for making the htlc manager and htlc switch
testable. The testability of htlc switch have been achieved by mocking
all external subsystems. The concrete list of updates:
1. create standalone package for htlc switch.
2. add "ChannelLink" interface, which represent the previous htlc link.
3. add "Peer" interface, which represent the remote node inside our
subsystem.
4. add htlc switch config to htlc switch susbystem, which stores the
handlers which are not elongs to any of the above interfaces.
With this commit we are able test htlc switch even without having
the concrete implementation of Peer, ChannelLink structures, they will
be added later.
This commit changes the cooperative channel close workflow to comply
with the latest spec. This adds steps to handle and send shutdown
messages as well as moving responsibility for sending the channel close
message from the initiator to the responder.
This commit fixes a deviant in the way we serialize and deserialize the
node announcement message from that which is currently in the spec.
Before this commit we reversed the order of features and addresses.
Instead, on the wire, features should come _before_ the addresses.
We also add a new temporary feature bit to ensure nodes that don’t
directly connect to each other if they don’t have this new update.
However, this will also partition any current tests nets when new nodes
join them as the digest signed has changed, therefore invalidating any
older messages.
Fixes#207.
This commit modifies ReadMessage to no longer return the total bytes
read as this value will now be calculated at a higher level. The
io.Reader that’s passed to ReadMessage is expected to contain the
_entire_ message rather than be a pointer into a stream that contains
the message itself.
This commit does away with all the old manual message equality tests
and replace it with a single property-based test that uses the
testing/quick package. This test uses a single scenario which MUST hold
for all the messages type and all possible messages generated for those
types. As a result we are able to do away with all the prior manually
generated test data as the fuzzer to scan the input space looking for a
message that violates the scenario.
This commit abandons our old bitcoin inspired message header and
replaces it with the bare type-only message headers that’s currently
used within the draft specification. As a result the message header now
consists of only 2-bytes for the message type, then actual payload
itself. With this change, the daemon will now need to switch to a
purely message based wire protocol in order to be able to handle the
extra data that can be extended to arbitrary messages.
This commit fixes a bug lingering in the decoding of the feature
vectors which was masked by the prior method of reading the _entire_
message from the stream before parsing it. The issue was that
performing a zero-byte Read on an io.Reader that’s purely streaming
will result in an indefinite block. We fix this bug by properly using
io.ReadFull in this context.
This commit modifies the Message interface to convert the Command
method to a MsgType method that uses a new set of message type for all
the defined messages. These new messages types nearly exactly match the
message types used within the current draft of the BOLT specifications.
This commit revues the Validate method from the Message interface as
the method is no longer used and is a relic from an older version of
the codebase.
This commit implements the new ping/pong messages along with their new
behavior. The new set of ping/pong messages allow clients to generate
fake cover traffic as the ping messages tells the pong message how many
bytes to included and can also be padded itself.
This commit does to things: moves the prior ShortChannelID struct into
a new short_channel_id.go file, and also implements the new ChannelID’s
currently used within he specification.
These new ID’s are 32-bytes in length and used during initial channel
funding as well as during normal channel updates. During initial
channel funding, the ID is to be a random 32-byte string, while once
normal channel operation has began, the ID is to be (txid XOR index),
where index is the index of the funding outpoint.
Change the name of fields of messages which are belong to the discovery
subsystem in a such way so they were the same with the names that are
defined in the specification.
In this commit announcement signature message has been added which is
needed when peers want to announce their channel to the rest of the
network. This message acts as half proof carrier, nodes exchanges
their half proofs with each other and after that they are able to
construct the full proof.
This commit modifies address handling in the NodeAnnouncement struct,
switching from net.TCPAddr to []net.Addr. This enables more flexible
address handling with multiple types and multiple addresses for each
node. This commit addresses the first part of issue #131 .
This commit modifies the ChannelUpdateAnnouncement to rename the Expiry
variable instead of TimeLockDelta as that is more descriptive of the
purpose of the attribute itself.
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.
This commit also removes the SingleFundingOpenProof message.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
This commit removes the String() method from the FeatureVector as it
can produce confusing output when revving a feature vector and not
knowing the strip mapping ahead of time.
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 modifies the prior HTLCSettleRequest to more closely match
the UpdateFufillHTLC defined within the specification. The only
semantic change is the move from a slice of pre-images (for “multi-sig”
LN) to a single payment preimage.
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.
This commit renames and modifies the CommitSignature message to more
closely match the CommitSig message defined within the current set of
draft specifications.
The major change within the new message is that we now longer
explicitly specify the update log index of the remote node that this
signature covers. This is due to the fact the revocation message now
also double as acknowledgements of the remote parties recevied
commitment update messages.
This commit renames the prior CommitRevocation message to RevokeAndAck
in order to better align the set of wire messages implemented by the
`lnwire` message with those currently defined within the specification.
'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 restriction around funding channels at the
daemon level: lnd nodes will not allow either the initiation or the
acceptance of a channel before the node is fully synced to the best
known chain.
This fixes a class of bug that arises when a new node joins the network
and either attempts to open a channel or has a channel extended to them
before the node is fully synced to the network.
This commit adds a new error type to the `lnwire` package:
`UnknownMessage`. With this error we can catch the particular case of a
an error during reading that encounters a new or unknown message. When
we encounter this message in the peer’s readHandler, we can now
gracefully handle it by just skipping to the next message rather than
closing out the section entirely.
This puts us a bit closer to the spec, but not exactly as it has an
additional constraint that we can only ignore a new message if it has
an odd type. In a future release, we’ll modify this code to match the
spec as written.
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 adds a new paramter to the initial channel creation:
‘PushSatoshis’. This new field allows the funder of a channel to push
over a certain amount to the responder as part of the initial channel
state. This ability creates a new streamlined UX of finalizing a
payment as a part of the channel creation.
