lnwire

package
v0.0.2 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Oct 3, 2016 License: MIT Imports: 10 Imported by: 0

README

Funding (segwit+CSV)

This is two-party funder for a single Funding Transaction (more efficient and makes the channel creation atomic, but doesn't work for CSV-no-malleability-fix).

Funding Request

Someone wants to open a channel. The requester provides any inputs and relevant information on how much they want to fund and the parameters, these paramters are a proposal.

Funding Response

If the responder accepts the request, they also provide any inputs, and returns with parameters as well. These parameters are now considered "Committed" and the negotation has finished. If the requester doesn't agree with the new conditions, they stop. The response also contains the first Commitment pubkey provided by the responder, which refunds the initial balance back to both parties.

Funding SignAccept

The requester now has sufficient information to get a refund if the transaction is ever broadcast. The requester signs the Funding Transaction and this message gives the signature to the responder. The requester also provides the signature for the initial Commitment Transaction.

Funding SignComplete

The responder has sufficient information to broadcast the Funding Transaction (with the ability to receive a refund), the responder broadcasts on the blockchain and returns the txid to the requester, with the signature of the Funding Transaction. This is provided as a courtesy, it cannot be relied upon with non-cooperative channel counterparties and the Funding Transaction can be braodcast without this message being received by the requester. After the necessary number of confirmations, Lightning Network transactions can proceed.

Cooperative Channel Close

This is when either party want to close out a channel with the current balance. Requires the cooperation of both parites for this type. In the event of non-cooperation, either party may broadcast the most recent Commitment Transaction.

Close Request

One party unilaterally sends their sig and fee amount to the other party. No further channel updates are possible. In the future, we might include HTLCs in the outputs, but for now, we're assuming all HTLCs are cleared out.

Close Complete

Returns the Txid and sig as a courtesy. The counterparty might not send this if they're being non-cooperative.

Commitments and HTLCs

This is designed to be non-blocking where there can be multiple Commitments per person and the Commitments do not need to match. A HTLC is only believed to be added when it's in both parties' most recent Commitment (same with timeout/settle) and all prior Commitments not reflecting the change are revoked by the counterparty.

As a result, there can easily be hundreds of state updates/payments per second per channel.

Commitment States

Commitments:

  1. HTLCs, can be modified. Any add/settlement/timeout/etc. gets added to staging.
  2. Signed, more than one signed state at a time may exist per party. Takes HTLCs staging and locks it in, can now be broadcast on-chain by the counterparty.
  3. Completed and Revoked, other party sends their revocation accepting this Commitment. Sending a revocation means you ACCEPT the Commitment. There should never be a case where a Commitment Signature happens and the client refusees to revoke -- instead the client should immediately close out the channel.
  4. Deprecated, a commitment is old, marked as deprecated when there is a new Commitment and this one is revoked. These commitments never be broadcasted.
  5. Invalid, close out channel immediately.

There can be multiple commitments going at a time per party (currently limits a total of 16 possible in-flight that can be broadcast for sanity, but there's no real limit).

For validity, all you do is ensure that the changes from the old commitment are legit (based on your HTLC/staging data) COMMIT_STAGING COMMIT_SIGNED COMMIT_COMPLETE

Messages: CommitSignature: Signature to establish COMMIT_SIGNED state CommitRevocation: Revoke prior states

ADD HTLCs

Requester Add HTLC states (Adding HTLCs):

  1. Pre-staged, don't know if the other person wants it
  2. Staged, both parties agree to add this HTLC. If a staging request packet is received, then BOTH PARTIES will have it in their next Commitment. Nothing is guaranteed here, but violations are treated as immediate channel closure.
  3. Signed and sent the Commitment Tx to the counterparty, one should now assume that there's a possibility that this HTLC will be boradcast on-chain.
  4. Completed and Revoked, counterparty has included this in the Commitment they're broadcasting and revoked their prior state. This means the Requeseter can continue to take action, since the Commitment they have, the HTLC doesn't exist (no payment), and the Responder will broadcast with the payment to the Responder. However, the Responder cannot treat the HTLC as cleared.
  5. Cleared. Both parties have signed and revoked. Responder can continue routing. Make sure it's included in BOTH COMMITMENTS and ALL PREVIOUS REVOKED
  6. Staging Reject, removal request, tx rejected, begin flow to reject HTLC from other channels, can only be sent during the pre-staging state

In the event that an HTLC stays in "Completed and Revoked" and it is timed out, and the counterparty refuses to add it into a new Commitment, the channel is closed out on-chain. In other words, when checking which ones to send a settle/timeout notification, do it for anything which is ADD_SIGNING_AND_REVOKING, or ADD_COMPLETE (AND ALL OTHER PRE-COMPLETE STAGES, e.g. in timeout or settlement).

As part of moving to any further stage, check if it's timed out.

If there is a request to stage and it's already staged, treat it as accepting.

When it has cleared and timed out, a timeout notification is sent.

HTLC ID numbers are uint64 and each counterparty is responsible to only make sequential/incremental, and each party can only make evens/odds (odd channel creation responder, evens channel creation initiator)

State is for YOUR signatures (what kind of action you need to do in the future) ADD_PRESTAGE ADD_STAGED ADD_SIGNING_AND_REVOKING ADD_COMPLETE ADD_REJECTED

Messages: HTLCAddRequest: Request to add to staging HTLCAddAccept: Add to staging (both parties have added when recv) HTLCAddReject: Deny add to staging (both parties don't have in staging)

HTLC Settle (payment success)

Requester Settle HTLC states (Fulfill HTLCs):

  1. Pre-staged, don't know if the other person will agree to settle
  2. Staged, both parties agree to settle this HTLC
  3. Signed and sent Commitment Tx to the counterparty, there is now the possibility that the HTLC does not exist on-chain (of course, the Commitment includes the payment so there's no real loss of funds). In the event that it does not complete past this step, then one must close out on-chain as if it was never staged/signed in the first place and the counterparty went offline.
  4. Both parties have signed and revoked, the settlement is complete (there is no intermediate step of Revoked because this is only reliable and actionable if BOTH PARTIES have updated their settlement state).

This has one less state because when adding, you're encumbering yourself. With removing, both parties are potentially encumbered, so they cannot take action until it's fully settled.

State is for your signatures SETTLE_PRESTAGE SETTLE_STAGED SETTLE_SIGNING_AND_REVOKING SETTLE_COMPLETE

Message: HTLCSettleRequest: Request to add to staging the removal from Commitment. HTLCSettleAccept: Add to staging the removal from Commitment. (There is no HTLCSettleReject as the counterparty should immediately close out or at worst ignore if it's getting garbage requests)

Timeout (falure/refund)

Requester Timeout HTLC States:

  1. Pre-staged
  2. Staged, both parties agree to time out the HTLC and refund the money
  3. Signe dnad sent commitment to the counterparty, there is now the possibility that the transaction will no longer exist on-chain (of course, they can be redeemed either way). In the even that it does not complete past this step, then one must close out on-chain as if it was never staged/signed in the first place adn the counterparty was offline.
  4. Both parties have signed and revoked, the settlement is complete (there is no intermediate step of Revoked because there is only reliable and actionable if BOTH PARTIES have updated their settlement state).

Similar to HTLC Settlement, there is one less state.

State is for your signatures TIMEOUT_PRESTAGE TIMEOUT_STAGED TIMEOUT_SIGNING_AND_REVOKING TIMEOUT_COMPLETE

Example (this section to be removed)

A bit redundant, but this was written first... will merge with "Add" example

Adding a single HTLC process:

  1. Requester flags as pre-staged, and sends an "add requeset"
  2. Responder decides whether to add. If they don't, they invalidate it. If they do, they send a message accepting the staging request. It is now marked as staged on both sides and is ready to be accepted into a Commitment.
  3. When a party wants to update with a new Commitment, they send a new signed Commitment, this includes data that the HTLC is part of it. Let's say it's the Requester that sends this new Commitment. As a result, the HTLC is marked BY THE RESPONDER as Signed. It's only when the Responder includes a transaction including the new HTLC in a new Commitment that the Requester marks it as Signed.
  4. Upon the Responder receiving the new Commitment, they send the revocation for the old Commitment, and commit to broadcasting only the new one.
  5. The Requester marks the HTLC as complete, but the Responder waits until they receive a Commitment (and the old one is revoked) before marking it as complete on the Responder's end.
  6. When both parties have the new Commitments and the old ones are revoked, then the HTLC is marked as complete

The two Commitment Transactions may not be completely in sync, but that's OK! What's added in both (and removed in both) are regarded as valid and locked-in. If it's only added to one, then it's regarded as in-transit and can go either way.

The behavior is to sign after all additions/removals/cancellations, but there may be multiple in the staging buffer.

Each party has their own revocation height (for the other party to use), and they may be different.

Documentation

Overview

Code derived from https:// github.com/btcsuite/btcd/blob/master/wire/message.go

Index

Constants

View Source 
const (
	// Commands for opening a channel funded by one party (single funder).
	CmdSingleFundingRequest      = uint32(100)
	CmdSingleFundingResponse     = uint32(110)
	CmdSingleFundingComplete     = uint32(120)
	CmdSingleFundingSignComplete = uint32(130)
	CmdSingleFundingOpenProof    = uint32(140)

	// Commands for the workflow of cooperatively closing an active channel.
	CmdCloseRequest  = uint32(300)
	CmdCloseComplete = uint32(310)

	// Commands for negotiating HTLCs.
	CmdHTLCAddRequest    = uint32(1000)
	CmdHTLCAddAccept     = uint32(1010)
	CmdHTLCAddReject     = uint32(1020)
	CmdHTLCSettleRequest = uint32(1100)
	CmdCancelHTLC        = uint32(1300)

	// Commands for modifying commitment transactions.
	CmdCommitSignature  = uint32(2000)
	CmdCommitRevocation = uint32(2010)

	// Commands for routing
	CmdNeighborHelloMessage        = uint32(3000)
	CmdNeighborUpdMessage          = uint32(3010)
	CmdNeighborAckMessage          = uint32(3020)
	CmdNeighborRstMessage          = uint32(3030)
	CmdRoutingTableRequestMessage  = uint32(3040)
	CmdRoutingTableTransferMessage = uint32(3050)

	// Commands for reporting protocol errors.
	CmdErrorGeneric = uint32(4000)
)

Commands used in lightning message headers which detail the type of message.

View Source 
const MaxMessagePayload = 1024 * 1024 * 32 //  32MB

MaxMessagePayload is the maximum bytes a message can be regardless of other individual limits imposed by messages themselves.

View Source 
const MaxSliceLength = 65535

MaxSliceLength is the maximum allowed lenth for any opaque byte slices in the wire protocol.

View Source 
const MessageHeaderSize = 12

MessageHeaderSize is the number of bytes in a lightning message header. The bytes are allocated as follows: network magic 4 bytes + command 4 bytes + payload length 4 bytes. Note that a checksum is omitted as lightning messages are assumed to be transmitted over an AEAD secured connection which provides integrity over the entire message.

Variables

This section is empty.

Functions

func WriteMessage 

func WriteMessage(w io.Writer, msg Message, pver uint32, btcnet wire.BitcoinNet) (int, error)

WriteMessage writes a lightning Message to w including the necessary header information and returns the number of bytes written.

Types

type CancelHTLC 

type CancelHTLC struct {
	// ChannelPoint is the particular active channel that this CancelHTLC
	// is binded to.
	ChannelPoint *wire.OutPoint

	// HTLCKey references which HTLC on the remote node's commitment
	// transaction has timed out.
	HTLCKey HTLCKey
}

CancelHTLC is sent by Alice to Bob in order to remove a previously added HTLC. Upon receipt of an CancelHTLC the HTLC should be removed from the next commitment transaction, with the CancelHTLC propgated backwards in the route to fully un-clear the HTLC.

func NewHTLCTimeoutRequest 

func NewHTLCTimeoutRequest() *CancelHTLC

CancelHTLC creates a new CancelHTLC message.

func (*CancelHTLC) Command 

func (c *CancelHTLC) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*CancelHTLC) Decode 

func (c *CancelHTLC) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized CancelHTLC message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CancelHTLC) Encode 

func (c *CancelHTLC) Encode(w io.Writer, pver uint32) error

Encode serializes the target CancelHTLC into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*CancelHTLC) MaxPayloadLength 

func (c *CancelHTLC) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a CancelHTLC complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CancelHTLC) String 

func (c *CancelHTLC) String() string

String returns the string representation of the target CancelHTLC. This is part of the lnwire.Message interface.

func (*CancelHTLC) Validate 

func (c *CancelHTLC) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the CancelHTLC are valid.

This is part of the lnwire.Message interface.

type CloseComplete 

type CloseComplete struct {
	// ChannelPoint serves to identify which channel is to be closed.
	ChannelPoint *wire.OutPoint

	// ResponderCloseSig is the signature of the responder for the
	// transaction which closes the previously active channel.
	ResponderCloseSig *btcec.Signature
}

CloseComplete is sent by Bob signalling a fufillment and completion of Alice's prior CloseRequest message. After Alice receives Bob's CloseComplete message, she is able to broadcast the fully signed transaction executing a cooperative closure of the channel.

NOTE: The responder is able to only send a signature without any additional message as all transactions are assembled observing BIP 69 which defines a cannonical ordering for input/outputs. Therefore, both sides are able to arrive at an identical closure transaction as they know the order of the inputs/outputs.

func NewCloseComplete 

func NewCloseComplete() *CloseComplete

NewCloseComplete creates a new empty CloseComplete message. TODO(roasbeef): add params to all constructors...

func (*CloseComplete) Command 

func (c *CloseComplete) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*CloseComplete) Decode 

func (c *CloseComplete) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized CloseComplete message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CloseComplete) Encode 

func (c *CloseComplete) Encode(w io.Writer, pver uint32) error

Encode serializes the target CloseComplete into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*CloseComplete) MaxPayloadLength 

func (c *CloseComplete) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a CloseComplete complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CloseComplete) String 

func (c *CloseComplete) String() string

String returns the string representation of the target CloseComplete.

This is part of the lnwire.Message interface.

func (*CloseComplete) Validate 

func (c *CloseComplete) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the CloseComplete are valid.

This is part of the lnwire.Message interface.

type CloseRequest 

type CloseRequest struct {
	// ChannelPoint serves to identify which channel is to be closed.
	ChannelPoint *wire.OutPoint

	// RequesterCloseSig is the signature of the requester for the fully
	// assembled closing transaction.
	RequesterCloseSig *btcec.Signature

	// Fee is the required fee-per-KB the closing transaction must have.
	// It is recommended that a "sufficient" fee be paid in order to achieve
	// timely channel closure.
	// TODO(roasbeef): if initiator always pays fees, then no longer needed.
	Fee btcutil.Amount
}

CloseRequest is sent by either side in order to initiate the cooperative closure of a channel. This message is rather sparse as both side implicitly know to craft a transaction sending the settled funds of both parties to the final delivery addresses negotiated during the funding workflow.

NOTE: The requester is able to only send a signature to initiate the cooperative channel closure as all transactions are assembled observing BIP 69 which defines a cannonical ordering for input/outputs. Therefore, both sides are able to arrive at an identical closure transaction as they know the order of the inputs/outputs.

func NewCloseRequest 

func NewCloseRequest(cp *wire.OutPoint, sig *btcec.Signature) *CloseRequest

NewCloseRequest creates a new CloseRequest.

func (*CloseRequest) Command 

func (c *CloseRequest) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*CloseRequest) Decode 

func (c *CloseRequest) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized CloseRequest stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CloseRequest) Encode 

func (c *CloseRequest) Encode(w io.Writer, pver uint32) error

Encode serializes the target CloseRequest into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*CloseRequest) MaxPayloadLength 

func (c *CloseRequest) MaxPayloadLength(pver uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for this message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CloseRequest) String 

func (c *CloseRequest) String() string

String returns the string representation of the target CloseRequest.

This is part of the lnwire.Message interface.

func (*CloseRequest) Validate 

func (c *CloseRequest) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the CloseRequest are valid.

This is part of the lnwire.Message interface.

type CommitHeight 

type CommitHeight uint64

CommitHeight is an integer which represents the highest HTLCKey seen by either side within their commitment transaction. Any addition to the pending, HTLC lists on either side will increment this height. As a result this value should always be monotonically increasing. Any CommitSignature or CommitRevocation messages will reference a value for the commitment height up to which it covers. HTLC's are only explicltly excluded by sending HTLCReject messages referencing a particular HTLCKey.

type CommitRevocation 

type CommitRevocation struct {
	// ChannelPoint uniquely identifies to which currently active channel this
	// CommitRevocation applies to.
	ChannelPoint *wire.OutPoint

	// Revocation is the pre-image to the revocation hash of the now prior
	// commitment transaction.
	//
	// If the received revocation is the all zeroes hash ('0' * 32), then
	// this CommitRevocation is being sent in order to build up the
	// sender's initial revocation window (IRW). In this case, the
	// CommitRevocation should be added to the receiver's queue of unused
	// revocations to be used to construct future commitment transactions.
	Revocation [32]byte

	// NextRevocationKey is the next revocation key which should be added
	// to the queue of unused revocation keys for the remote peer. This key
	// will be used within the revocation clause for any new commitment
	// transactions created for the remote peer.
	NextRevocationKey *btcec.PublicKey

	// NextRevocationHash is the next revocation hash which should be added
	// to the queue on unused revocation hashes for the remote peer. This
	// revocation hash will be used within any HTLC's included within this
	// next commitment transaction.
	NextRevocationHash [32]byte
}

CommitRevocation is sent by either side once a CommitSignature message has been received, and validated. This message serves to revoke the prior commitment transaction, which was the most up to date version until a CommitSignature message referencing the specified ChannelPoint was received. Additionally, this message also piggyback's the next revocation hash that Alice should use when constructing the Bob's version of the next commitment transaction (which would be done before sending a CommitSignature message). This piggybacking allows Alice to send the next CommitSignature message modifying Bob's commitment transaction without first asking for a revocation hash initially. TODO(roasbeef): update docs everywhere

func NewCommitRevocation 

func NewCommitRevocation() *CommitRevocation

NewCommitRevocation creates a new CommitRevocation message.

func (*CommitRevocation) Command 

func (c *CommitRevocation) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*CommitRevocation) Decode 

func (c *CommitRevocation) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized CommitRevocation message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CommitRevocation) Encode 

func (c *CommitRevocation) Encode(w io.Writer, pver uint32) error

Encode serializes the target CommitRevocation into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*CommitRevocation) MaxPayloadLength 

func (c *CommitRevocation) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a CommitRevocation complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CommitRevocation) String 

func (c *CommitRevocation) String() string

String returns the string representation of the target CommitRevocation.

This is part of the lnwire.Message interface. TODO(roasbeef): remote all String() methods...spew should be used instead.

func (*CommitRevocation) Validate 

func (c *CommitRevocation) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the CommitRevocation are valid.

This is part of the lnwire.Message interface.

type CommitSignature 

type CommitSignature struct {
	// ChannelPoint uniquely identifies to which currently active channel this
	// CommitSignature applies to.
	ChannelPoint *wire.OutPoint

	// LogIndex is the index into the reciever's HTLC log to which this
	// commitment signature covers. In order to properly verify this
	// signature, the receiver should include all the HTLC's within their
	// log with an index less-than-or-equal to the listed log-index.
	LogIndex uint64

	// Fee represents the total miner's fee that was used when constructing
	// the new commitment transaction.
	// TODO(roasbeef): is the above comment correct?
	Fee btcutil.Amount

	// CommitSig is Alice's signature for Bob's new commitment transaction.
	// Alice is able to send this signature without requesting any additional
	// data due to the piggybacking of Bob's next revocation hash in his
	// prior CommitRevocation message, as well as the cannonical ordering
	// used for all inputs/outputs within commitment transactions.
	CommitSig *btcec.Signature
}

CommitSignature is sent by either side to stage any pending HTLC's in the reciever's pending set which has not explcitly been rejected via an HTLCAddReject message. Implictly, the new commitment transaction constructed which has been signed by CommitSig includes all HTLC's in the remote node's pending set. A CommitSignature message may be sent after a series of HTLCAdd messages in order to batch add several HTLC's with a single signature covering all implicitly accepted HTLC's.

func NewCommitSignature 

func NewCommitSignature() *CommitSignature

NewCommitSignature creates a new empty CommitSignature message.

func (*CommitSignature) Command 

func (c *CommitSignature) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*CommitSignature) Decode 

func (c *CommitSignature) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized CommitSignature message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CommitSignature) Encode 

func (c *CommitSignature) Encode(w io.Writer, pver uint32) error

Encode serializes the target CommitSignature into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*CommitSignature) MaxPayloadLength 

func (c *CommitSignature) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a CommitSignature complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*CommitSignature) String 

func (c *CommitSignature) String() string

String returns the string representation of the target CommitSignature.

This is part of the lnwire.Message interface.

func (*CommitSignature) Validate 

func (c *CommitSignature) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the CommitSignature are valid.

This is part of the lnwire.Message interface.

type CreditsAmount 

type CreditsAmount int64

CreditsAmount are the native currency unit used within the Lightning Network. Credits are denominated in sub-satoshi amounts, so micro-satoshis (1/1000). This value is purposefully signed in order to allow the expression of negative fees.

"In any science-fiction movie, anywhere in the galaxy, currency is referred to as 'credits.'" 

--Sam Humphries. Ebert, Roger (1999). Ebert's bigger little movie
glossary. Andrews McMeel. p. 172.

https://en.wikipedia.org/wiki/List_of_fictional_currencies https://en.wikipedia.org/wiki/Fictional_currency#Trends_in_the_use_of_fictional_currencies http://tvtropes.org/pmwiki/pmwiki.php/Main/WeWillSpendCreditsInTheFuture US Display format: 1 BTC = 100,000,000'000 XCB Or in BTC = 1.00000000'000 Credits (XCB, accountants should use XCB :^)

func (CreditsAmount) ToSatoshi 

func (c CreditsAmount) ToSatoshi() int64

ToSatoshi converts an amount in Credits to the coresponding amount expressed in Satoshis.

NOTE: This function rounds down by default (floor).

type ErrorGeneric 

type ErrorGeneric struct {
	// ChannelPoint references the active channel in which the error occured
	// within. A ChannelPoint of zeroHash:0 denotes this error applies to
	// the entire established connection.
	ChannelPoint *wire.OutPoint

	// ErrorID quickly defines the nature of the error according to error
	// type.
	ErrorID uint16

	// Problem is a human-readable string further elaborating upon the
	// nature of the exact error. The maxmium allowed length of this
	// message is 8192 bytes.
	Problem string
}

ErrorGeneric represents a generic error bound to an exact channel. The message format is purposefully general in order to allow expressino of a wide array of possible errors. Each ErrorGeneric message is directed at a particular open channel referenced by ChannelPoint.

func NewErrorGeneric 

func NewErrorGeneric() *ErrorGeneric

NewErrorGeneric creates a new ErrorGeneric message.

func (*ErrorGeneric) Command 

func (c *ErrorGeneric) Command() uint32

Command returns the integer uniquely identifying an ErrorGeneric message on the wire.

This is part of the lnwire.Message interface.

func (*ErrorGeneric) Decode 

func (c *ErrorGeneric) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized ErrorGeneric message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*ErrorGeneric) Encode 

func (c *ErrorGeneric) Encode(w io.Writer, pver uint32) error

Encode serializes the target ErrorGeneric into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*ErrorGeneric) MaxPayloadLength 

func (c *ErrorGeneric) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a ErrorGeneric complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*ErrorGeneric) String 

func (c *ErrorGeneric) String() string

String returns the string representation of the target ErrorGeneric.

This is part of the lnwire.Message interface.

func (*ErrorGeneric) Validate 

func (c *ErrorGeneric) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the ErrorGeneric are valid.

This is part of the lnwire.Message interface.

type HTLCAddReject 

type HTLCAddReject struct {
	// ChannelPoint references the particular active channel to which this
	// HTLCAddReject message is binded to.
	ChannelPoint *wire.OutPoint

	// HTLCKey is used to identify which HTLC previously attempted to be
	// added via an HTLCAddRequest message is being declined.
	HTLCKey HTLCKey
}

HTLCAddReject is sent by Bob when he wishes to reject a particular HTLC that Alice attempted to add via an HTLCAddRequest message. The rejected HTLC is referenced by its unique HTLCKey ID. An HTLCAddReject message is bound to a single active channel, referenced by a unique ChannelPoint. Additionally, the HTLCKey of the rejected HTLC is present

func NewHTLCAddReject 

func NewHTLCAddReject() *HTLCAddReject

NewHTLCAddReject returns a new empty HTLCAddReject message.

func (*HTLCAddReject) Command 

func (c *HTLCAddReject) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*HTLCAddReject) Decode 

func (c *HTLCAddReject) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized HTLCAddReject message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCAddReject) Encode 

func (c *HTLCAddReject) Encode(w io.Writer, pver uint32) error

Encode serializes the target HTLCAddReject into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*HTLCAddReject) MaxPayloadLength 

func (c *HTLCAddReject) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a HTLCAddReject complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCAddReject) String 

func (c *HTLCAddReject) String() string

String returns the string representation of the target HTLCAddReject.

This is part of the lnwire.Message interface.

func (*HTLCAddReject) Validate 

func (c *HTLCAddReject) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the HTLCAddReject are valid.

This is part of the lnwire.Message interface.

type HTLCAddRequest 

type HTLCAddRequest struct {
	// ChannelPoint is the particular active channel that this HTLCAddRequest
	// is binded to.
	ChannelPoint *wire.OutPoint

	// Expiry is the number of blocks after which this HTLC should expire.
	// It is the receiver's duty to ensure that the outgoing HTLC has a
	// sufficient expiry value to allow her to redeem the incmoing HTLC.
	Expiry uint32

	// Amount is the number of credits this HTLC is worth.
	Amount CreditsAmount

	// RefundContext is for payment cancellation
	// TODO(j): not currently in use, add later
	RefundContext HTLCKey

	// ContractType defines the particular output script to be used for
	// this HTLC. This value defaults to zero for regular HTLCs. For
	// multi-sig HTLCs, then first 4 bit represents N, while the second 4
	// bits are M, within the N-of-M multi-sig.
	ContractType uint8

	// RedemptionHashes are the hashes to be used within the HTLC script.
	// An HTLC is only fufilled once Bob is provided with the required
	// number of pre-images for each of the listed hashes. For regular HTLC's
	// this slice only has one hash. However, for "multi-sig" HTLC's, the
	// length of this slice should be N.
	RedemptionHashes [][32]byte

	// OnionBlob is the raw serialized mix header used to route an HTLC in
	// a privacy-preserving manner. The mix header is defined currently to
	// be parsed as a 4-tuple: (groupElement, routingInfo, headerMAC, body).
	// First the receiving node should use the groupElement, and its current
	// onion key to derive a shared secret with the source. Once the shared
	// secret has been derived, the headerMAC should be checked FIRST. Note
	// that the MAC only covers the routingInfo field. If the MAC matches,
	// and the shared secret is fresh, then the node should stip off a layer
	// of encryption, exposing the next hop to be used in the subsequent
	// HTLCAddRequest message.
	OnionBlob []byte
}

HTLCAddRequest is the message sent by Alice to Bob when she wishes to add an HTLC to his remote commitment transaction. In addition to information detailing the value, and contract type of the HTLC, and onion blob is also included which allows Bob to derive the next hop in the route. The HTLC added by this message is to be added to the remote node's "pending" HTLC's. A subsequent CommitSignature message will move the pending HTLC to the newly created commitment transaction, marking them as "staged".

func NewHTLCAddRequest 

func NewHTLCAddRequest() *HTLCAddRequest

NewHTLCAddRequest returns a new empty HTLCAddRequest message.

func (*HTLCAddRequest) Command 

func (c *HTLCAddRequest) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*HTLCAddRequest) Decode 

func (c *HTLCAddRequest) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized HTLCAddRequest message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCAddRequest) Encode 

func (c *HTLCAddRequest) Encode(w io.Writer, pver uint32) error

Encode serializes the target HTLCAddRequest into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*HTLCAddRequest) MaxPayloadLength 

func (c *HTLCAddRequest) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a HTLCAddRequest complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCAddRequest) String 

func (c *HTLCAddRequest) String() string

String returns the string representation of the target HTLCAddRequest.

This is part of the lnwire.Message interface.

func (*HTLCAddRequest) Validate 

func (c *HTLCAddRequest) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the HTLCAddRequest are valid.

This is part of the lnwire.Message interface.

type HTLCKey 

type HTLCKey int64

HTLCKey is an identifier used to uniquely identify any HTLC's transmitted between Alice and Bob. In order to cancel, timeout, or settle HTLC's this identifier should be used to allow either side to easily locate and modify any staged or pending HTLCs. TODO(roasbeef): change to HTLCIdentifier?

type HTLCSettleRequest 

type HTLCSettleRequest struct {
	// ChannelPoint references an active channel which holds the HTLC to be
	// settled.
	ChannelPoint *wire.OutPoint

	// HTLCKey denotes the exact HTLC stage within the receiving node's
	// commitment transaction to be removed.
	// TODO(roasbeef): rename to LogIndex
	HTLCKey HTLCKey

	// RedemptionProofs are the R-value preimages required to fully settle
	// an HTLC. The number of preimages in the slice will depend on the
	// specific ContractType of the referenced HTLC.
	RedemptionProofs [][32]byte
}

HTLCSettleRequest is sent by Alice to Bob when she wishes to settle a particular HTLC referenced by its HTLCKey within a specific active channel referenced by ChannelPoint. The message allows multiple hash preimages to be presented in order to support N-of-M HTLC contracts. A subsequent CommitSignature message will be sent by Alice to "lock-in" the removal of the specified HTLC, possible containing a batch signature covering several settled HTLC's.

func NewHTLCSettleRequest 

func NewHTLCSettleRequest(chanPoint *wire.OutPoint, key HTLCKey,
	redemptionProofs [][32]byte) *HTLCSettleRequest

NewHTLCSettleRequest returns a new empty HTLCSettleRequest.

func (*HTLCSettleRequest) Command 

func (c *HTLCSettleRequest) Command() uint32

Command returns the integer uniquely identifying this message type on the wire.

This is part of the lnwire.Message interface.

func (*HTLCSettleRequest) Decode 

func (c *HTLCSettleRequest) Decode(r io.Reader, pver uint32) error

Decode deserializes a serialized HTLCSettleRequest message stored in the passed io.Reader observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCSettleRequest) Encode 

func (c *HTLCSettleRequest) Encode(w io.Writer, pver uint32) error

Encode serializes the target HTLCSettleRequest into the passed io.Writer observing the protocol version specified.

This is part of the lnwire.Message interface.

func (*HTLCSettleRequest) MaxPayloadLength 

func (c *HTLCSettleRequest) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload size for a HTLCSettleRequest complete message observing the specified protocol version.

This is part of the lnwire.Message interface.

func (*HTLCSettleRequest) String 

func (c *HTLCSettleRequest) String() string

String returns the string representation of the target HTLCSettleRequest.

This is part of the lnwire.Message interface.

func (*HTLCSettleRequest) Validate 

func (c *HTLCSettleRequest) Validate() error

Validate performs any necessary sanity checks to ensure all fields present on the HTLCSettleRequest are valid.

This is part of the lnwire.Message interface.

type Message 

type Message interface {
	Decode(io.Reader, uint32) error
	Encode(io.Writer, uint32) error
	Command() uint32
	MaxPayloadLength(uint32) uint32
	Validate() error
	String() string
}

Message is an interface that defines a lightning wire protocol message. The interface is general in order to allow implementing types full control over the representation of its data.

func ReadMessage 

func ReadMessage(r io.Reader, pver uint32, btcnet wire.BitcoinNet) (int, Message, []byte, error)

ReadMessageN reads, validates, and parses the next bitcoin Message from r for the provided protocol version and bitcoin network. It returns the number of bytes read in addition to the parsed Message and raw bytes which comprise the message. This function is the same as ReadMessage except it also returns the number of bytes read.

type NeighborAckMessage 

type NeighborAckMessage struct {
}

func (*NeighborAckMessage) Command 

func (msg *NeighborAckMessage) Command() uint32

func (*NeighborAckMessage) Decode 

func (msg *NeighborAckMessage) Decode(r io.Reader, pver uint32) error

func (*NeighborAckMessage) Encode 

func (msg *NeighborAckMessage) Encode(w io.Writer, pver uint32) error

func (*NeighborAckMessage) MaxPayloadLength 

func (msg *NeighborAckMessage) MaxPayloadLength(uint32) uint32

func (*NeighborAckMessage) String 

func (msg *NeighborAckMessage) String() string

func (*NeighborAckMessage) Validate 

func (msg *NeighborAckMessage) Validate() error

type NeighborHelloMessage 

type NeighborHelloMessage struct {
	RT *rt.RoutingTable
}

func (*NeighborHelloMessage) Command 

func (msg *NeighborHelloMessage) Command() uint32

func (*NeighborHelloMessage) Decode 

func (msg *NeighborHelloMessage) Decode(r io.Reader, pver uint32) error

func (*NeighborHelloMessage) Encode 

func (msg *NeighborHelloMessage) Encode(w io.Writer, pver uint32) error

func (*NeighborHelloMessage) MaxPayloadLength 

func (msg *NeighborHelloMessage) MaxPayloadLength(uint32) uint32

func (*NeighborHelloMessage) String 

func (msg *NeighborHelloMessage) String() string

func (*NeighborHelloMessage) Validate 

func (msg *NeighborHelloMessage) Validate() error

type NeighborRstMessage 

type NeighborRstMessage struct {
}

func (*NeighborRstMessage) Command 

func (msg *NeighborRstMessage) Command() uint32

func (*NeighborRstMessage) Decode 

func (msg *NeighborRstMessage) Decode(r io.Reader, pver uint32) error

func (*NeighborRstMessage) Encode 

func (msg *NeighborRstMessage) Encode(w io.Writer, pver uint32) error

func (*NeighborRstMessage) MaxPayloadLength 

func (msg *NeighborRstMessage) MaxPayloadLength(uint32) uint32

func (*NeighborRstMessage) String 

func (msg *NeighborRstMessage) String() string

func (*NeighborRstMessage) Validate 

func (msg *NeighborRstMessage) Validate() error

type NeighborUpdMessage 

type NeighborUpdMessage struct {
	DiffBuff *rt.DifferenceBuffer
}

func (*NeighborUpdMessage) Command 

func (msg *NeighborUpdMessage) Command() uint32

func (*NeighborUpdMessage) Decode 

func (msg *NeighborUpdMessage) Decode(r io.Reader, pver uint32) error

func (*NeighborUpdMessage) Encode 

func (msg *NeighborUpdMessage) Encode(w io.Writer, pver uint32) error

func (*NeighborUpdMessage) MaxPayloadLength 

func (msg *NeighborUpdMessage) MaxPayloadLength(uint32) uint32

func (*NeighborUpdMessage) String 

func (msg *NeighborUpdMessage) String() string

func (*NeighborUpdMessage) Validate 

func (msg *NeighborUpdMessage) Validate() error

type PkScript 

type PkScript []byte

PkScript is simple type definition which represents a raw serialized public key script.

type RoutingTableRequestMessage 

type RoutingTableRequestMessage struct {
}

func (*RoutingTableRequestMessage) Command 

func (msg *RoutingTableRequestMessage) Command() uint32

func (*RoutingTableRequestMessage) Decode 

func (msg *RoutingTableRequestMessage) Decode(r io.Reader, pver uint32) error

func (*RoutingTableRequestMessage) Encode 

func (msg *RoutingTableRequestMessage) Encode(w io.Writer, pver uint32) error

func (*RoutingTableRequestMessage) MaxPayloadLength 

func (msg *RoutingTableRequestMessage) MaxPayloadLength(uint32) uint32

func (*RoutingTableRequestMessage) String 

func (msg *RoutingTableRequestMessage) String() string

func (*RoutingTableRequestMessage) Validate 

func (msg *RoutingTableRequestMessage) Validate() error

type RoutingTableTransferMessage 

type RoutingTableTransferMessage struct {
	RT *rt.RoutingTable
}

func (*RoutingTableTransferMessage) Command 

func (msg *RoutingTableTransferMessage) Command() uint32

func (*RoutingTableTransferMessage) Decode 

func (msg *RoutingTableTransferMessage) Decode(r io.Reader, pver uint32) error

func (*RoutingTableTransferMessage) Encode 

func (msg *RoutingTableTransferMessage) Encode(w io.Writer, pver uint32) error

func (*RoutingTableTransferMessage) MaxPayloadLength 

func (msg *RoutingTableTransferMessage) MaxPayloadLength(uint32) uint32

func (*RoutingTableTransferMessage) String 

func (msg *RoutingTableTransferMessage) String() string

func (*RoutingTableTransferMessage) Validate 

func (msg *RoutingTableTransferMessage) Validate() error

type SingleFundingComplete 

type SingleFundingComplete struct {
	// ChannelID serves to uniquely identify the future channel created by
	// the initiated single funder workflow.
	// TODO(roasbeef): change all to PendingChannelID, document schema
	ChannelID uint64

	// FundingOutPoint is the outpoint (txid:index) of the funding
	// transaction. With this value, Bob will be able to generate a
	// signature for Alice's version of the commitment transaction.
	FundingOutPoint *wire.OutPoint

	// CommitSignature is Alice's signature for Bob's version of the
	// commitment transaction.
	CommitSignature *btcec.Signature

	// RevocationKey is the initial key to be used for the revocation
	// clause within the self-output of the initiators's commitment
	// transaction. Once an initial new state is created, the initiator
	// will send a pre-image which will allow the initiator to sweep the
	// initiator's funds if the violate the contract.
	RevocationKey *btcec.PublicKey
}

SingleFundingComplete is the message Alice sends to Bob once she is able to fully assemble the funding transaction, and both versions of the commitment transaction. The purpose of this message is to present Bob with the items required for him to generate a signature for Alice's version of the commitment transaction.

func NewSingleFundingComplete 

func NewSingleFundingComplete(chanID uint64, fundingPoint *wire.OutPoint,
	commitSig *btcec.Signature, revokeKey *btcec.PublicKey) *SingleFundingComplete

NewSingleFundingComplete creates, and returns a new empty SingleFundingResponse.

func (*SingleFundingComplete) Command 

func (s *SingleFundingComplete) Command() uint32

Command returns the uint32 code which uniquely identifies this message as a SingleFundingRequest on the wire.

This is part of the lnwire.Message interface.

func (*SingleFundingComplete) Decode 

func (s *SingleFundingComplete) Decode(r io.Reader, pver uint32) error

Decode deserializes the serialized SingleFundingComplete stored in the passed io.Reader into the target SingleFundingComplete using the deserialization rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingComplete) Encode 

func (s *SingleFundingComplete) Encode(w io.Writer, pver uint32) error

Encode serializes the target SingleFundingComplete into the passed io.Writer implementation. Serialization will observe the rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingComplete) MaxPayloadLength 

func (s *SingleFundingComplete) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload length for a SingleFundingComplete. This is calculated by summing the max length of all the fields within a SingleFundingResponse. Therefore, the final breakdown is: 8 + 36 + 73 = 150

This is part of the lnwire.Message interface.

func (*SingleFundingComplete) String 

func (s *SingleFundingComplete) String() string

String returns the string representation of the SingleFundingResponse.

This is part of the lnwire.Message interface.

func (*SingleFundingComplete) Validate 

func (s *SingleFundingComplete) Validate() error

Validate examines each populated field within the SingleFundingComplete for field sanity.

This is part of the lnwire.Message interface.

type SingleFundingOpenProof 

type SingleFundingOpenProof struct {
	// ChannelID serves to uniquely identify the future channel created by
	// the initiated single funder workflow.
	ChannelID uint64

	// SpvProof is an merkle proof of the inclusion of the funding
	// transaction within a block.
	// TODO(roasbeef): spec out format for SPV proof, only of single tx so
	// can be compact
	SpvProof []byte
}

SingleFundingOpenProof is the message sent by the channel initiator to the responder after the previously constructed funding transaction has achieved a sufficient number of confirmations. It is the initiator's duty to present a proof of an open channel to the responder. Otherwise, responding node may be vulernable to a resource exhasution attack wherein the a requesting node repeatedly negotiates funding transactions which are never broadcast. If the responding node commits resources to watch the chain for each funding transaction, then this attack is very cheap for the initiator.

func NewSingleFundingOpenProof 

func NewSingleFundingOpenProof(chanID uint64, spvProof []byte) *SingleFundingOpenProof

NewSingleFundingSignComplete creates a new empty SingleFundingOpenProof message.

func (*SingleFundingOpenProof) Command 

func (s *SingleFundingOpenProof) Command() uint32

Command returns the uint32 code which uniquely identifies this message as a SingleFundingSignComplete on the wire.

This is part of the lnwire.Message interface.

func (*SingleFundingOpenProof) Decode 

func (s *SingleFundingOpenProof) Decode(r io.Reader, pver uint32) error

Decode deserializes the serialized SingleFundingOpenProof stored in the passed io.Reader into the target SingleFundingOpenProof using the deserialization rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingOpenProof) Encode 

func (s *SingleFundingOpenProof) Encode(w io.Writer, pver uint32) error

Encode serializes the target SingleFundingOpenProof into the passed io.Writer implementation. Serialization will observe the rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingOpenProof) MaxPayloadLength 

func (s *SingleFundingOpenProof) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload length for a SingleFundingComplete. This is calculated by summing the max length of all the fields within a SingleFundingOpenProof.

This is part of the lnwire.Message interface.

func (*SingleFundingOpenProof) String 

func (s *SingleFundingOpenProof) String() string

String returns the string representation of the SingleFundingOpenProof.

This is part of the lnwire.Message interface.

func (*SingleFundingOpenProof) Validate 

func (s *SingleFundingOpenProof) Validate() error

Validate examines each populated field within the SingleFundingOpenProof for field sanity.

This is part of the lnwire.Message interface.

type SingleFundingRequest 

type SingleFundingRequest struct {
	// ChannelID serves to uniquely identify the future channel created by
	// the initiated single funder workflow.
	ChannelID uint64

	// ChannelType represents the type of channel this request would like
	// to open. At this point, the only supported channels are type 0
	// channels, which are channels with regular commitment transactions
	// utilizing HTLC's for payments.
	ChannelType uint8

	// CoinType represents which blockchain the channel will be opened
	// using. By default, this field should be set to 0, indicating usage
	// of the Bitcoin blockchain.
	CoinType uint64

	// FeePerKb is the required number of satoshis per KB that the
	// requester will pay at all timers, for both the funding transaction
	// and commitment transaction. This value can later be updated once the
	// channel is open.
	FeePerKb btcutil.Amount

	// FundingAmount is the number of satoshis the the initiator would like
	// to commit to the channel.
	FundingAmount btcutil.Amount

	// CsvDelay is the number of blocks to use for the relative time lock
	// in the pay-to-self output of both commitment transactions.
	CsvDelay uint32

	// CommitmentKey is key the initiator of the funding workflow wishes to
	// use within their versino of the commitment transaction for any
	// delayed (CSV) or immediate outputs to them.
	CommitmentKey *btcec.PublicKey

	// ChannelDerivationPoint is an secp256k1 point which will be used to
	// derive the public key the initiator will use for the half of the
	// 2-of-2 multi-sig. Using the channel derivation point (CDP), and the
	// initiators identity public key (A), the channel public key is
	// computed as: C = A + CDP. In order to be valid all CDP's MUST have
	// an odd y-coordinate.
	ChannelDerivationPoint *btcec.PublicKey

	// DeliveryPkScript defines the public key script that the initiator
	// would like to use to receive their balance in the case of a
	// cooperative close. Only the following script templates are
	// supported: P2PKH, P2WKH, P2SH, and P2WSH.
	DeliveryPkScript PkScript
}

SingleFundingRequest is the message Alice sends to Bob if we should like to create a channel with Bob where she's the sole provider of funds to the channel. Single funder channels simplify the initial funding workflow, are supported by nodes backed by SPV Bitcoin clients, and have a simpler security models than dual funded channels.

NOTE: In order to avoid a slow loris like resource exhaustion attack, the responder of a single funding channel workflow *should not* watch the blockchain for the funding transaction. Instead, it is the initiator's job to provide the responder with an SPV proof of funding transaction inclusion after a sufficient number of confirmations.

func NewSingleFundingRequest 

func NewSingleFundingRequest(chanID uint64, chanType uint8, coinType uint64,
	fee btcutil.Amount, amt btcutil.Amount, delay uint32, ck,
	cdp *btcec.PublicKey, deliveryScript PkScript) *SingleFundingRequest

NewSingleFundingRequest creates, and returns a new empty SingleFundingRequest.

func (*SingleFundingRequest) Command 

func (c *SingleFundingRequest) Command() uint32

Command returns the uint32 code which uniquely identifies this message as a SingleFundingRequest on the wire.

This is part of the lnwire.Message interface.

func (*SingleFundingRequest) Decode 

func (c *SingleFundingRequest) Decode(r io.Reader, pver uint32) error

Decode deserializes the serialized SingleFundingRequest stored in the passed io.Reader into the target SingleFundingRequest using the deserialization rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingRequest) Encode 

func (c *SingleFundingRequest) Encode(w io.Writer, pver uint32) error

Encode serializes the target SingleFundingRequest into the passed io.Writer implementation. Serialization will observe the rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingRequest) MaxPayloadLength 

func (c *SingleFundingRequest) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload length for a SingleFundingRequest. This is calculated by summing the max length of all the fields within a SingleFundingRequest. To enforce a maximum DeliveryPkScript size, the size of a P2PKH public key script is used. Therefore, the final breakdown is: 8 + 1 + 8 + 8 + 8 + 4 + 33 + 33 + 25 = 158.

This is part of the lnwire.Message interface.

func (*SingleFundingRequest) String 

func (c *SingleFundingRequest) String() string

String returns the string representation of the SingleFundingRequest.

This is part of the lnwire.Message interface.

func (*SingleFundingRequest) Validate 

func (c *SingleFundingRequest) Validate() error

Validate examines each populated field within the SingleFundingRequest for field sanity. For example, all fields MUST NOT be negative, and all pkScripts must belong to the allowed set of public key scripts.

This is part of the lnwire.Message interface.

type SingleFundingResponse 

type SingleFundingResponse struct {
	// ChannelID serves to uniquely identify the future channel created by
	// the initiated single funder workflow.
	ChannelID uint64

	// ChannelDerivationPoint is an secp256k1 point which will be used to
	// derive the public key the responder will use for the half of the
	// 2-of-2 multi-sig. Using the channel derivation point (CDP), and the
	// responder's identity public key (A), the channel public key is
	// computed as: C = A + CDP. In order to be valid all CDP's MUST have
	// an odd y-coordinate.
	ChannelDerivationPoint *btcec.PublicKey

	// CommitmentKey is key the responder to the funding workflow wishes to
	// use within their versino of the commitment transaction for any
	// delayed (CSV) or immediate outputs to them.
	CommitmentKey *btcec.PublicKey

	// RevocationKey is the initial key to be used for the revocation
	// clause within the self-output of the responder's commitment
	// transaction. Once an initial new state is created, the responder
	// will send a pre-image which will allow the initiator to sweep the
	// responder's funds if the violate the contract.
	RevocationKey *btcec.PublicKey

	// CsvDelay is the number of blocks to use for the relative time lock
	// in the pay-to-self output of both commitment transactions.
	CsvDelay uint32

	// DeliveryPkScript defines the public key script that the initiator
	// would like to use to receive their balance in the case of a
	// cooperative close. Only the following script templates are
	// supported: P2PKH, P2WKH, P2SH, and P2WSH.
	DeliveryPkScript PkScript
}

SingleFundingResponse is the message Bob sends to Alice after she initiates the single funder channel workflow via a SingleFundingRequest message. Once Alice receives Bob's reponse, then she has all the items neccessary to construct the funding transaction, and both commitment transactions.

func NewSingleFundingResponse 

func NewSingleFundingResponse(chanID uint64, rk, ck, cdp *btcec.PublicKey,
	delay uint32, deliveryScript PkScript) *SingleFundingResponse

NewSingleFundingResponse creates, and returns a new empty SingleFundingResponse.

func (*SingleFundingResponse) Command 

func (c *SingleFundingResponse) Command() uint32

Command returns the uint32 code which uniquely identifies this message as a SingleFundingRequest on the wire.

This is part of the lnwire.Message interface.

func (*SingleFundingResponse) Decode 

func (c *SingleFundingResponse) Decode(r io.Reader, pver uint32) error

Decode deserializes the serialized SingleFundingResponse stored in the passed io.Reader into the target SingleFundingResponse using the deserialization rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingResponse) Encode 

func (c *SingleFundingResponse) Encode(w io.Writer, pver uint32) error

Encode serializes the target SingleFundingResponse into the passed io.Writer implementation. Serialization will observe the rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingResponse) MaxPayloadLength 

func (c *SingleFundingResponse) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload length for a SingleFundingResponse. This is calculated by summing the max length of all the fields within a SingleFundingResponse. To enforce a maximum DeliveryPkScript size, the size of a P2PKH public key script is used. Therefore, the final breakdown is: 8 + (33 * 3) + 8 + 25

This is part of the lnwire.Message interface.

func (*SingleFundingResponse) String 

func (c *SingleFundingResponse) String() string

String returns the string representation of the SingleFundingResponse.

This is part of the lnwire.Message interface.

func (*SingleFundingResponse) Validate 

func (c *SingleFundingResponse) Validate() error

Validate examines each populated field within the SingleFundingResponse for field sanity. For example, all fields MUST NOT be negative, and all pkScripts must belong to the allowed set of public key scripts.

This is part of the lnwire.Message interface.

type SingleFundingSignComplete 

type SingleFundingSignComplete struct {
	// ChannelID serves to uniquely identify the future channel created by
	// the initiated single funder workflow.
	ChannelID uint64

	// CommitSignature is Bobs's signature for Alice's version of the
	// commitment transaction.
	CommitSignature *btcec.Signature
}

SingleFundingSignComplete is the message Bob sends to Alice which delivers a signature for Alice's version of the commitment transaction. After thie message is received and processed by Alice, she is free to broadcast the funding transaction.

func NewSingleFundingSignComplete 

func NewSingleFundingSignComplete(chanID uint64,
	sig *btcec.Signature) *SingleFundingSignComplete

NewSingleFundingSignComplete creates a new empty SingleFundingSignComplete message.

func (*SingleFundingSignComplete) Command 

func (c *SingleFundingSignComplete) Command() uint32

Command returns the uint32 code which uniquely identifies this message as a SingleFundingSignComplete on the wire.

This is part of the lnwire.Message interface.

func (*SingleFundingSignComplete) Decode 

func (c *SingleFundingSignComplete) Decode(r io.Reader, pver uint32) error

Decode deserializes the serialized SingleFundingSignComplete stored in the passed io.Reader into the target SingleFundingComplete using the deserialization rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingSignComplete) Encode 

func (c *SingleFundingSignComplete) Encode(w io.Writer, pver uint32) error

Encode serializes the target SingleFundingSignComplete into the passed io.Writer implementation. Serialization will observe the rules defined by the passed protocol version.

This is part of the lnwire.Message interface.

func (*SingleFundingSignComplete) MaxPayloadLength 

func (c *SingleFundingSignComplete) MaxPayloadLength(uint32) uint32

MaxPayloadLength returns the maximum allowed payload length for a SingleFundingComplete. This is calculated by summing the max length of all the fields within a SingleFundingResponse. The final breakdown is: 8 + 73 = 81

This is part of the lnwire.Message interface.

func (*SingleFundingSignComplete) String 

func (c *SingleFundingSignComplete) String() string

String returns the string representation of the SingleFundingSignComplete.

This is part of the lnwire.Message interface.

func (*SingleFundingSignComplete) Validate 

func (s *SingleFundingSignComplete) Validate() error

Validate examines each populated field within the SingleFundingComplete for field sanity.

This is part of the lnwire.Message interface.

Source Files

View all Source files

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.