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

Custom channel bug fixes #936

Merged
merged 8 commits into from
Jun 7, 2024
Merged

Custom channel bug fixes #936

merged 8 commits into from
Jun 7, 2024

Conversation

guggero
Copy link
Member

@guggero guggero commented Jun 7, 2024

Fixes the following issues:

  • A panic during co-op close when one side didn't have any balance at all
  • Format custom channel data to JSON in PendingChannels RPC
  • Fix HTLC being rejected due to asset precision rounding issue
  • Allow forwarding an asset-to-asset HTLC (single hop payment with asset channels on both sides)

Copy link
Contributor

@ffranr ffranr left a comment

Choose a reason for hiding this comment

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

LGTM

tapchannel/aux_closer.go Show resolved Hide resolved
guggero added 8 commits June 7, 2024 18:19
This commit fixes an issue with co-op closing channels where one side
has no balance.
This commit returns an empty string if there is no custom data in a
channel. That prevents the lncli output from showing:
  "custom_channel_data": "{\"assets\":null}",
And instead just shows:
  "custom_channel_data: "",

At the same time, we add the previously forgotten pending channels to
the calls of RPC methods that we want to format the response for.
To make sure the lnd forwarding algorithm doesn't reject an incoming
HTLC because due to the asset resolution it appears they aren't paying
enough fees, we always add a single asset unit.
This doesn't actually mean we're sending an additional unit every time,
it just means we might accept an HTLC even if it pays a couple of
milli-satoshis too little fees. This can be remediated by increasing the
asset resolution/precision.
If a payment is coming in through one asset channel and is supposed to
leave through another asset channel, we don't actually have to do any
conversion to BTC but instead to the outgoing asset directly (this would
be a single hop payment with asset channels on both sides).
To allow that forwarding mode, we add a new policy that contains both an
incoming and outgoing channel policy.
@guggero guggero merged commit deba7dd into main Jun 7, 2024
14 checks passed
@guggero guggero deleted the more-fixes branch June 7, 2024 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

2 participants