Wrong Amount of Sats in Split Payments When Using LN Address Identifier

[DoktorShift]

Description

When performing a split payment using the Split Payments extension in LNbits (version 0.12.12) with the LN address as the identifier, the total distributed amount does not equal the original input. This discrepancy is not observed when using wallet IDs for split payments.

Steps to Reproduce

Environment Setup

• Ensure LNbits version 0.12.12 and Split Payments extension version 0.2.0 are installed and configured.

Test with LN Address Identifier

1. Initiate a split payment with an input of 3000 sats.
2. Configure splits as follows:
   • Split1: 40%
   • Split2: 20%
   • Split3: 20%
   • Split4: 20%
3. Use LN addresses as identifiers for the recipients.

Expected Outcome

• The amounts should ideally round in a way that the sum equals the original input (3000 sats) since its only a internal database task.

Observed Outcome

• The split amounts calculated are:
  • Split1: 1182 sats
  • Split2: 591 sats
  • Split3: 591 sats
  • Split4: 591 sats
• Total distributed: 2955 sats
• Discrepancy: 45 sats less than the original input (3000 sats).

Test with Wallet ID

1. Repeat the same setup using wallet IDs instead of LN addresses.
2. Configure splits with the same percentages.

Observed Outcome

• The split amounts calculated are:
  • Split1: 1200 sats
  • Split2: 600 sats
  • Split3: 600 sats
  • Split4: 600 sats
• Total distributed: 3000 sats
• This matches the original input with no discrepancies.

Additional Observations

• The same rounding error occurs when using split payments to external LN addresses.
• This suggests a potential rounding error issue specifically when using LN addresses as identifiers in the split payment process.

Environment

• LNbits Version: 0.12.12
• Split Payments Extension Version: 0.2.0
• Tested on both internal and external LN addresses.

Note

I have not enabled some service fee etc.