-
Notifications
You must be signed in to change notification settings - Fork 272
Extract CommitParams
to individual commitments
#3118
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
Conversation
eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/channel/ChannelData.scala
Outdated
Show resolved
Hide resolved
35d7cd3
to
d9b8b5e
Compare
@sstone this PR is now ready for the taproot work to be rebased on top of it to validate the v5 codecs! |
Rebased to include the |
4c81ec2
to
33cd067
Compare
We refactor our transactions handling and our closing data to match the changes made in `eclair` to support taproot channels and commitment upgrades during splices. The architecture matches the change made in eclair, up to changes from ACINQ/eclair#3118
Before introducing channel codecs v5, we add more test data encoded with the v4 codecs, especially for the fields we intend to change.
We introduce a new channel codec version where: - we extract per-commitment parameters (commitment format and params such as `dust_limit` which we may want to dynamically update in the future) - we clean-up the splice iterations on the `Commitments` structure - we remove the funding transaction from the confirmed local funding status (once confirmed, we don't need it anymore: it is wasting DB space for no good reason, we can get it from the blockchain) - we add a `maxClosingFeerate_opt` to the closing state, to allow limiting the feerate used in RBF attempts for safe transactions
And remove the unused sealed trait, the commitment format contains the information we need so we don't need multiple child classes. We still use a `discriminated` at the codec level though to allow changing the format in the future if needed.
We want to be able to update channel types during splices, which means that channel type features will not be permanent anymore. We decouple permanent channel features (that apply to the lifetime of the channel) from channel type features to allow this.
33cd067
to
f7fb22e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (I feel like I have already reviewed this?)
I suggest adding some temporary code in Setup.scala
that prevents app startup. It would give us time to rebase feature branches and maybe refine codecs, without worrying about backward compat for users that run master.
eclair-core/src/main/scala/fr/acinq/eclair/channel/ChannelFeatures.scala
Outdated
Show resolved
Hide resolved
We add a mechanism to prevent the node from starting-up, unless an override is provided. This provides an opportunity to iterate on codecs while knowing that node operators won't be affected if we make changes that are backwards-incompatible.
Good idea, done in a8bed6f and tested locally. I did this in |
We refactor our transactions handling and our closing data to match the changes made in `eclair` to support taproot channels and commitment upgrades during splices. The architecture matches the change made in eclair, up to changes from ACINQ/eclair#3118
We refactor our transactions handling and our closing data to match the changes made in `eclair` to support taproot channels and commitment upgrades during splices. The architecture matches the change made in eclair, up to changes from ACINQ/eclair#3118
We introduce a new channel codec version where:
dust_limit
which we may want to dynamically update in the future)Commitments
structuremaxClosingFeerate_opt
to the closing state, to allow limiting the feerate used in RBF attempts for safe transactions