lnwire

package
v0.0.0-...-2cbe605 Latest Latest
Warning

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

 Go to latest Published: Feb 8, 2016 License: MIT Imports: 8 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 (
	MSGID_FUNDREQUEST  = 0x30
	MSGID_FUNDRESPONSE = 0x31

	MSGID_CLOSEREQUEST  = 0x40
	MSGID_CLOSERESPONSE = 0x41

	MSGID_TEXTCHAT = 0x70

	MSGID_FWDMSG     = 0x20
	MSGID_FWDAUTHREQ = 0x21
)

message type identifyer bytes

View Source 
const (
	// Funding channel open
	CmdFundingRequest      = uint32(200)
	CmdFundingResponse     = uint32(210)
	CmdFundingSignAccept   = uint32(220)
	CmdFundingSignComplete = uint32(230)

	// Close channel
	CmdCloseRequest  = uint32(300)
	CmdCloseComplete = uint32(310)

	// TODO Renumber to 1100
	// HTLC payment
	CmdHTLCAddRequest = uint32(1000)
	CmdHTLCAddAccept  = uint32(1010)
	CmdHTLCAddReject  = uint32(1020)

	// TODO Renumber to 1200
	// HTLC settlement
	CmdHTLCSettleRequest = uint32(1100)
	CmdHTLCSettleAccept  = uint32(1110)

	// HTLC timeout
	CmdHTLCTimeoutRequest = uint32(1300)
	CmdHTLCTimeoutAccept  = uint32(1310)

	// Commitments
	CmdCommitSignature  = uint32(2000)
	CmdCommitRevocation = uint32(2010)

	// Error
	CmdErrorGeneric = uint32(4000)
)
View Source 
const MaxMessagePayload = 1024 * 1024 * 32 //  32MB
View Source 
const MessageHeaderSize = 12

4-byte network + 4-byte message id + payload-length 4-byte

Variables

View Source 
var MAX_SLICE_LENGTH = 65535

Functions

func ValidatePkScript 

func ValidatePkScript(pkScript PkScript) error

Validates whether a PkScript byte array is P2SH or P2PKH

func WriteMessage 

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

Types

type CloseComplete 

type CloseComplete struct {
	ReservationID uint64

	ResponderCloseSig *btcec.Signature // Requester's Commitment
	CloseShaHash      *wire.ShaHash    // TxID of the Close Tx
}

func NewCloseComplete 

func NewCloseComplete() *CloseComplete

Creates a new CloseComplete

func (*CloseComplete) Command 

func (c *CloseComplete) Command() uint32

func (*CloseComplete) Decode 

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

func (*CloseComplete) Encode 

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

Serializes the item from the CloseComplete struct Writes the data to w

func (*CloseComplete) MaxPayloadLength 

func (c *CloseComplete) MaxPayloadLength(uint32) uint32

func (*CloseComplete) String 

func (c *CloseComplete) String() string

func (*CloseComplete) Validate 

func (c *CloseComplete) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type CloseRequest 

type CloseRequest struct {
	ReservationID uint64

	RequesterCloseSig *btcec.Signature // Requester's Commitment
	Fee               btcutil.Amount
}

func NewCloseRequest 

func NewCloseRequest() *CloseRequest

Creates a new CloseRequest

func (*CloseRequest) Command 

func (c *CloseRequest) Command() uint32

func (*CloseRequest) Decode 

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

func (*CloseRequest) Encode 

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

Serializes the item from the CloseRequest struct Writes the data to w

func (*CloseRequest) MaxPayloadLength 

func (c *CloseRequest) MaxPayloadLength(uint32) uint32

func (*CloseRequest) String 

func (c *CloseRequest) String() string

func (*CloseRequest) Validate 

func (c *CloseRequest) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type CommitHeight 

type CommitHeight uint64

type CommitRevocation 

type CommitRevocation struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// Height of the commitment
	// You should have the most recent commitment height stored locally
	// This should be validated!
	// This is used for shachain.
	// Each party increments their own CommitmentHeight, they can differ for
	// each part of the Commitment.
	CommitmentHeight uint64

	// Revocation to use
	RevocationProof [20]byte
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewCommitRevocation 

func NewCommitRevocation() *CommitRevocation

Creates a new CommitRevocation

func (*CommitRevocation) Command 

func (c *CommitRevocation) Command() uint32

func (*CommitRevocation) Decode 

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

func (*CommitRevocation) Encode 

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

Serializes the item from the CommitRevocation struct Writes the data to w

func (*CommitRevocation) MaxPayloadLength 

func (c *CommitRevocation) MaxPayloadLength(uint32) uint32

func (*CommitRevocation) String 

func (c *CommitRevocation) String() string

func (*CommitRevocation) Validate 

func (c *CommitRevocation) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type CommitSignature 

type CommitSignature struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// Height of the commitment
	// You should have the most recent commitment height stored locally
	// This should be validated!
	// This is used for shachain.
	// Each party increments their own CommitmentHeight, they can differ for
	// each part of the Commitment.
	CommitmentHeight uint64

	// List of HTLC Keys which are updated from all parties
	UpdatedHTLCKeys []uint64

	// Hash of the revocation to use
	RevocationHash [20]byte

	// Total miners' fee that was used
	Fee btcutil.Amount

	// Signature for the new Commitment
	CommitSig *btcec.Signature // Requester's Commitment
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewCommitSignature 

func NewCommitSignature() *CommitSignature

Creates a new CommitSignature

func (*CommitSignature) Command 

func (c *CommitSignature) Command() uint32

func (*CommitSignature) Decode 

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

func (*CommitSignature) Encode 

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

Serializes the item from the CommitSignature struct Writes the data to w

func (*CommitSignature) MaxPayloadLength 

func (c *CommitSignature) MaxPayloadLength(uint32) uint32

func (*CommitSignature) String 

func (c *CommitSignature) String() string

func (*CommitSignature) Validate 

func (c *CommitSignature) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type CreditsAmount 

type CreditsAmount int32 // Credits (XCB, accountants should use XCB :^)

Subsatoshi amount (Micro-Satoshi, 1/1000th) Should be a signed int to account for 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

type ErrorGeneric 

type ErrorGeneric struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64
	// Some kind of message
	// Max length 8192
	Problem string
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewErrorGeneric 

func NewErrorGeneric() *ErrorGeneric

Creates a new ErrorGeneric

func (*ErrorGeneric) Command 

func (c *ErrorGeneric) Command() uint32

func (*ErrorGeneric) Decode 

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

func (*ErrorGeneric) Encode 

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

Serializes the item from the ErrorGeneric struct Writes the data to w

func (*ErrorGeneric) MaxPayloadLength 

func (c *ErrorGeneric) MaxPayloadLength(uint32) uint32

func (*ErrorGeneric) String 

func (c *ErrorGeneric) String() string

func (*ErrorGeneric) Validate 

func (c *ErrorGeneric) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type FundingRequest 

type FundingRequest struct {
	ReservationID uint64

	ChannelType uint8

	RequesterFundingAmount btcutil.Amount
	RequesterReserveAmount btcutil.Amount
	MinFeePerKb            btcutil.Amount

	// The funding requester can request payment
	// This wallet only allows positive values,
	// which is a payment to the responder
	// (This can be used to fund the Reserve)
	// If the responder disagrees, then the funding request fails
	// THIS VALUE GOES INTO THE RESPONDER'S FUNDING AMOUNT
	// total requester input value = RequesterFundingAmount + PaymentAmount + "Total Change" + Fees(?)
	// RequesterFundingAmount = "Available Balance" + RequesterReserveAmount
	// Payment SHOULD NOT be acknowledged until the minimum confirmation has elapsed
	// (Due to double-spend risks the recipient will not want to acknolwedge confirmation until later)
	// This is to make a payment as part of opening the channel
	PaymentAmount btcutil.Amount

	// Minimum number of confirmations to validate transaction
	MinDepth uint32

	// Should double-check the total funding later
	MinTotalFundingAmount btcutil.Amount

	// CLTV/CSV lock-time to use
	LockTime uint32

	// Who pays the fees
	// 0: (default) channel initiator
	// 1: split
	// 2: channel responder
	FeePayer uint8

	RevocationHash   [20]byte
	Pubkey           *btcec.PublicKey
	DeliveryPkScript PkScript // *MUST* be either P2PKH or P2SH
	ChangePkScript   PkScript // *MUST* be either P2PKH or P2SH

	Inputs []*wire.TxIn
}

func NewFundingRequest 

func NewFundingRequest() *FundingRequest

Creates a new FundingRequest

func (*FundingRequest) Command 

func (c *FundingRequest) Command() uint32

func (*FundingRequest) Decode 

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

func (*FundingRequest) Encode 

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

Serializes the item from the FundingRequest struct Writes the data to w

func (*FundingRequest) MaxPayloadLength 

func (c *FundingRequest) MaxPayloadLength(uint32) uint32

func (*FundingRequest) String 

func (c *FundingRequest) String() string

func (*FundingRequest) Validate 

func (c *FundingRequest) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type FundingResponse 

type FundingResponse struct {
	ChannelType uint8

	ReservationID uint64

	ResponderFundingAmount btcutil.Amount // Responder's funding amount
	ResponderReserveAmount btcutil.Amount // Responder's reserve amount
	MinFeePerKb            btcutil.Amount // Lock-in min fee

	// Minimum depth
	MinDepth uint32

	// CLTV/CSV lock-time to use
	LockTime uint32

	// Who pays the fees
	// 0: (default) channel initiator
	// 1: split
	// 2: channel responder
	FeePayer uint8

	RevocationHash   [20]byte
	Pubkey           *btcec.PublicKey
	CommitSig        *btcec.Signature // Requester's Commitment
	DeliveryPkScript PkScript         // *MUST* be either P2PKH or P2SH
	ChangePkScript   PkScript         // *MUST* be either P2PKH or P2SH

	Inputs []*wire.TxIn
}

func NewFundingResponse 

func NewFundingResponse() *FundingResponse

Creates a new FundingResponse

func (*FundingResponse) Command 

func (c *FundingResponse) Command() uint32

func (*FundingResponse) Decode 

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

func (*FundingResponse) Encode 

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

Serializes the item from the FundingResponse struct Writes the data to w

func (*FundingResponse) MaxPayloadLength 

func (c *FundingResponse) MaxPayloadLength(uint32) uint32

func (*FundingResponse) String 

func (c *FundingResponse) String() string

func (*FundingResponse) Validate 

func (c *FundingResponse) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type FundingSignAccept 

type FundingSignAccept struct {
	ReservationID uint64

	CommitSig     *btcec.Signature // Requester's Commitment
	FundingTXSigs []*btcec.Signature
}

func NewFundingSignAccept 

func NewFundingSignAccept() *FundingSignAccept

Creates a new FundingSignAccept

func (*FundingSignAccept) Command 

func (c *FundingSignAccept) Command() uint32

func (*FundingSignAccept) Decode 

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

func (*FundingSignAccept) Encode 

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

Serializes the item from the FundingSignAccept struct Writes the data to w

func (*FundingSignAccept) MaxPayloadLength 

func (c *FundingSignAccept) MaxPayloadLength(uint32) uint32

func (*FundingSignAccept) String 

func (c *FundingSignAccept) String() string

func (*FundingSignAccept) Validate 

func (c *FundingSignAccept) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type FundingSignComplete 

type FundingSignComplete struct {
	ReservationID uint64

	TxID          *wire.ShaHash
	FundingTXSigs []*btcec.Signature
}

func NewFundingSignComplete 

func NewFundingSignComplete() *FundingSignComplete

Creates a new FundingSignComplete

func (*FundingSignComplete) Command 

func (c *FundingSignComplete) Command() uint32

func (*FundingSignComplete) Decode 

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

func (*FundingSignComplete) Encode 

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

Serializes the item from the FundingSignComplete struct Writes the data to w

func (*FundingSignComplete) MaxPayloadLength 

func (c *FundingSignComplete) MaxPayloadLength(uint32) uint32

func (*FundingSignComplete) String 

func (c *FundingSignComplete) String() string

func (*FundingSignComplete) Validate 

func (c *FundingSignComplete) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCAddAccept 

type HTLCAddAccept struct {
	ChannelID uint64
	HTLCKey   HTLCKey
}

func NewHTLCAddAccept 

func NewHTLCAddAccept() *HTLCAddAccept

Creates a new HTLCAddAccept

func (*HTLCAddAccept) Command 

func (c *HTLCAddAccept) Command() uint32

func (*HTLCAddAccept) Decode 

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

func (*HTLCAddAccept) Encode 

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

Serializes the item from the HTLCAddAccept struct Writes the data to w

func (*HTLCAddAccept) MaxPayloadLength 

func (c *HTLCAddAccept) MaxPayloadLength(uint32) uint32

func (*HTLCAddAccept) String 

func (c *HTLCAddAccept) String() string

func (*HTLCAddAccept) Validate 

func (c *HTLCAddAccept) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCAddReject 

type HTLCAddReject struct {
	ChannelID uint64
	HTLCKey   HTLCKey
}

func NewHTLCAddReject 

func NewHTLCAddReject() *HTLCAddReject

Creates a new HTLCAddReject

func (*HTLCAddReject) Command 

func (c *HTLCAddReject) Command() uint32

func (*HTLCAddReject) Decode 

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

func (*HTLCAddReject) Encode 

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

Serializes the item from the HTLCAddReject struct Writes the data to w

func (*HTLCAddReject) MaxPayloadLength 

func (c *HTLCAddReject) MaxPayloadLength(uint32) uint32

func (*HTLCAddReject) String 

func (c *HTLCAddReject) String() string

func (*HTLCAddReject) Validate 

func (c *HTLCAddReject) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCAddRequest 

type HTLCAddRequest struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// ID of this request
	HTLCKey HTLCKey

	// When the HTLC expires
	Expiry uint32

	// Amount to pay in the hop
	// Difference between hop and first item in blob is the fee to complete
	Amount CreditsAmount

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

	// Contract Type
	// first 4 bits is n, second for is m, in n-of-m "multisig"
	ContractType uint8

	// Redemption Hashes
	RedemptionHashes []*[20]byte

	// Data to parse&pass on to the next node
	// Eventually, we need to make this into a group of 2 nested structs?
	Blob []byte
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewHTLCAddRequest 

func NewHTLCAddRequest() *HTLCAddRequest

Creates a new HTLCAddRequest

func (*HTLCAddRequest) Command 

func (c *HTLCAddRequest) Command() uint32

func (*HTLCAddRequest) Decode 

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

func (*HTLCAddRequest) Encode 

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

Serializes the item from the HTLCAddRequest struct Writes the data to w

func (*HTLCAddRequest) MaxPayloadLength 

func (c *HTLCAddRequest) MaxPayloadLength(uint32) uint32

func (*HTLCAddRequest) String 

func (c *HTLCAddRequest) String() string

func (*HTLCAddRequest) Validate 

func (c *HTLCAddRequest) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCKey 

type HTLCKey uint64

type HTLCSettleAccept 

type HTLCSettleAccept struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// ID of this request
	HTLCKey HTLCKey
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewHTLCSettleAccept 

func NewHTLCSettleAccept() *HTLCSettleAccept

Creates a new HTLCSettleAccept

func (*HTLCSettleAccept) Command 

func (c *HTLCSettleAccept) Command() uint32

func (*HTLCSettleAccept) Decode 

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

func (*HTLCSettleAccept) Encode 

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

Serializes the item from the HTLCSettleAccept struct Writes the data to w

func (*HTLCSettleAccept) MaxPayloadLength 

func (c *HTLCSettleAccept) MaxPayloadLength(uint32) uint32

func (*HTLCSettleAccept) String 

func (c *HTLCSettleAccept) String() string

func (*HTLCSettleAccept) Validate 

func (c *HTLCSettleAccept) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCSettleRequest 

type HTLCSettleRequest struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// ID of this request
	HTLCKey HTLCKey

	// Redemption Proofs (R-Values)
	RedemptionProofs []*[20]byte
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewHTLCSettleRequest 

func NewHTLCSettleRequest() *HTLCSettleRequest

Creates a new HTLCSettleRequest

func (*HTLCSettleRequest) Command 

func (c *HTLCSettleRequest) Command() uint32

func (*HTLCSettleRequest) Decode 

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

func (*HTLCSettleRequest) Encode 

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

Serializes the item from the HTLCSettleRequest struct Writes the data to w

func (*HTLCSettleRequest) MaxPayloadLength 

func (c *HTLCSettleRequest) MaxPayloadLength(uint32) uint32

func (*HTLCSettleRequest) String 

func (c *HTLCSettleRequest) String() string

func (*HTLCSettleRequest) Validate 

func (c *HTLCSettleRequest) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCTimeoutAccept 

type HTLCTimeoutAccept struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// ID of this request
	HTLCKey HTLCKey
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewHTLCTimeoutAccept 

func NewHTLCTimeoutAccept() *HTLCTimeoutAccept

Creates a new HTLCTimeoutAccept

func (*HTLCTimeoutAccept) Command 

func (c *HTLCTimeoutAccept) Command() uint32

func (*HTLCTimeoutAccept) Decode 

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

func (*HTLCTimeoutAccept) Encode 

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

Serializes the item from the HTLCTimeoutAccept struct Writes the data to w

func (*HTLCTimeoutAccept) MaxPayloadLength 

func (c *HTLCTimeoutAccept) MaxPayloadLength(uint32) uint32

func (*HTLCTimeoutAccept) String 

func (c *HTLCTimeoutAccept) String() string

func (*HTLCTimeoutAccept) Validate 

func (c *HTLCTimeoutAccept) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type HTLCTimeoutRequest 

type HTLCTimeoutRequest struct {
	// We can use a different data type for this if necessary...
	ChannelID uint64

	// ID of this request
	HTLCKey HTLCKey
}

Multiple Clearing Requests are possible by putting this inside an array of clearing requests

func NewHTLCTimeoutRequest 

func NewHTLCTimeoutRequest() *HTLCTimeoutRequest

Creates a new HTLCTimeoutRequest

func (*HTLCTimeoutRequest) Command 

func (c *HTLCTimeoutRequest) Command() uint32

func (*HTLCTimeoutRequest) Decode 

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

func (*HTLCTimeoutRequest) Encode 

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

Serializes the item from the HTLCTimeoutRequest struct Writes the data to w

func (*HTLCTimeoutRequest) MaxPayloadLength 

func (c *HTLCTimeoutRequest) MaxPayloadLength(uint32) uint32

func (*HTLCTimeoutRequest) String 

func (c *HTLCTimeoutRequest) String() string

func (*HTLCTimeoutRequest) Validate 

func (c *HTLCTimeoutRequest) Validate() error

Makes sure the struct data is valid (e.g. no negatives or invalid pkscripts)

type Message 

type Message interface {
	Decode(io.Reader, uint32) error // (io, protocol version)
	Encode(io.Writer, uint32) error // (io, protocol version)
	Command() uint32                // returns ID of the message
	MaxPayloadLength(uint32) uint32 // (version) maxpayloadsize
	Validate() error                // Validates the data struct
	String() string
}

Every message has these functions:

func ReadMessage 

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

type PkScript 

type PkScript []byte

Actual pkScript, not redeemScript

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.