diff --git a/lnwallet/reservation.go b/lnwallet/reservation.go index 08e4e6c3..5f988f6d 100644 --- a/lnwallet/reservation.go +++ b/lnwallet/reservation.go @@ -79,9 +79,6 @@ type ChannelContribution struct { // * We then verify the validity of all signatures before considering the // channel "open". type ChannelReservation struct { - // TODO(roasbeef): remove this? we're only implementing the golden... - fundingType FundingType - // This mutex MUST be held when either reading or modifying any of the // fields below. sync.RWMutex @@ -120,11 +117,10 @@ type ChannelReservation struct { // used only internally by lnwallet. In order to concurrent safety, the creation // of all channel reservations should be carried out via the // lnwallet.InitChannelReservation interface. -func newChannelReservation(t FundingType, fundingAmt btcutil.Amount, - minFeeRate btcutil.Amount, wallet *LightningWallet, id uint64) *ChannelReservation { +func newChannelReservation(fundingAmt btcutil.Amount, minFeeRate btcutil.Amount, + wallet *LightningWallet, id uint64) *ChannelReservation { // TODO(roasbeef): CSV here, or on delay? return &ChannelReservation{ - fundingType: t, ourContribution: &ChannelContribution{ FundingAmount: fundingAmt, }, diff --git a/lnwallet/wallet.go b/lnwallet/wallet.go index 414c4eb9..8bf1dc99 100644 --- a/lnwallet/wallet.go +++ b/lnwallet/wallet.go @@ -42,34 +42,6 @@ var ( wtxmgrNamespaceKey = []byte("wtxmgr") ) -// FundingType represents the type of the funding transaction. The type of -// funding transaction available depends entirely on the level of upgrades to -// Script on the current network. Across the network it's possible for asymmetric -// funding types to exist across hop. However, for direct links, the funding type -// supported by both parties must be identical. The most 'powerful' funding type -// is SEGWIT. This funding type also assumes that both CSV+CLTV are available on -// the network. -// NOTE: Ultimately, this will most likely be deprecated... -type FundingType uint16 - -const ( - // Use SegWit, assumes CSV+CLTV - SEGWIT FundingType = iota - - // Use SIGHASH_NOINPUT, assumes CSV+CLTV - SIGHASH - - // Use CSV without reserve - CSV - - // Use CSV with reserve - // Reserve is a permanent amount of funds locked and the capacity. - CSV_RESERVE - - // CLTV with reserve. - CLTV_RESERVE -) - // initFundingReserveReq is the first message sent to initiate the workflow // required to open a payment channel with a remote peer. The initial required // paramters are configurable accross channels. These paramters are to be chosen @@ -83,9 +55,6 @@ const ( // Meaning both parties must encumber the same amount of funds. // TODO(roasbeef): zombie reservation sweeper goroutine. type initFundingReserveMsg struct { - // The type of the funding transaction. See above for further details. - fundingType FundingType - // The amount of funds requested for this channel. fundingAmount btcutil.Amount @@ -443,7 +412,7 @@ out: // contribution. The third, and final step verifies all signatures for the inputs // of the funding transaction, and that the signature we records for our version // of the commitment transaction is valid. -func (l *LightningWallet) InitChannelReservation(a btcutil.Amount, t FundingType, +func (l *LightningWallet) InitChannelReservation(a btcutil.Amount, theirID [32]byte, csvDelay uint32) (*ChannelReservation, error) { errChan := make(chan error, 1) @@ -451,7 +420,6 @@ func (l *LightningWallet) InitChannelReservation(a btcutil.Amount, t FundingType l.msgChan <- &initFundingReserveMsg{ fundingAmount: a, - fundingType: t, csvDelay: csvDelay, nodeID: theirID, err: errChan, @@ -468,7 +436,7 @@ func (l *LightningWallet) handleFundingReserveRequest(req *initFundingReserveMsg l.limboMtx.Lock() id := l.nextFundingID - reservation := newChannelReservation(req.fundingType, req.fundingAmount, req.minFeeRate, l, id) + reservation := newChannelReservation(req.fundingAmount, req.minFeeRate, l, id) l.nextFundingID++ l.fundingLimbo[id] = reservation @@ -486,7 +454,7 @@ func (l *LightningWallet) handleFundingReserveRequest(req *initFundingReserveMsg // We hold the coin select mutex while querying for outputs, and // performing coin selection in order to avoid inadvertent double spends // accross funding transactions. - // NOTE: we don't use defer her so we can properly release the lock + // NOTE: We don't use defer her so we can properly release the lock // when we encounter an error condition. l.coinSelectMtx.Lock()