Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[anchors] Pluggable anchor commitments #3798

Closed
wants to merge 18 commits into from

Conversation

halseth
Copy link
Contributor

@halseth halseth commented Dec 5, 2019

No description provided.

We define a new type CommitmentType, that abstracts away how keys
are generated for the different commitment types (currently
tweak(less)).

Intention is that more of the logic that is unique for each commitment
type is behind the type, making the channel state machine oblivious
to the keys and outputs being created on the commitment tx for a given
channel state.
To make the channel state machine less concerned about the type of
commitment, we nil the local tweak when creating the keyring, depending
on the commitment type.
It was incorrectly stated that the commitment balance was before
subctracting the commit fee, which led to some confusion.
Instead of passing delays and dustlimits separately, we pass the correct
channel config to CreateCommitTx from the POV of the local party that
owns the commit tx.

To make it more clear which commitment we are actually creating, we
rename variables to denote local and remote, to prepare for the case
when both outputs might be delayed.
Since both parties are going to have their ouputs delayed, we move way
from the DelayKey naming, and instead use LocalKey and RemoteKey.
Based on the current commitment type, we derive the script used for the
to_remote output.
With this commitment type, we'll add extra achnor outputs to the
commitment transaction.
Based on the commitment type, the commitment weight will be calculated.
@halseth halseth added the anchors label Dec 5, 2019
@@ -747,24 +753,24 @@ func (l *LightningWallet) handleFundingCancelRequest(req *fundingReserveCancelMs
// initial funding workflow as both sides must generate a signature for the
// remote party's commitment transaction, and verify the signature for their
// version of the commitment transaction.
func CreateCommitmentTxns(localBalance, remoteBalance btcutil.Amount,
func CreateCommitmentTxns(localBalance, remoteBalance,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this complete function be moved into the plugin?

// commitment type.
type CommitmentType struct {
chanType channeldb.ChannelType
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually expected an interface here with three implementations?

@@ -331,7 +332,8 @@ func (c *chainWatcher) SubscribeChannelEvents() *ChainEventSubscription {
// based off of only the set of outputs included.
func isOurCommitment(localChanCfg, remoteChanCfg channeldb.ChannelConfig,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be a method on CommitmentType too?

@@ -2375,7 +2304,7 @@ func (lc *LightningChannel) fundingTxIn() wire.TxIn {
// createCommitmentTx generates the unsigned commitment transaction for a
// commitment view and assigns to txn field.
func (lc *LightningChannel) createCommitmentTx(c *commitment,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a method on the plugin?

@halseth
Copy link
Contributor Author

halseth commented Dec 13, 2019

Replaced by #3821

@halseth halseth closed this Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants