Consider recovering excess LN fee for cross account receives

[gudnuf]

A cross account receive is when we melt a token from mint A and use the melt quote to pay a mint quote from mint B. Mint B is where the user wants to receive the money into.

The way that this is currently done can be seen here. A cashu-receive-quote is created in the Agicash db, but the melt operation happens purely on the client. There is a chance that mint A overestimated the lightning fee which means when the melt completes, the mint will return change. We simply forget the change.

In the case that the user does not have an account for mint A, there's not much we can do here. Sometimes if the fee reserve is large enough, then there would be sufficient funds to go through the cross account receive process again and melt the change, but then we will likely end up with change again. When the change is just a couple of sats, it will usually not be enough to cover all fees, so then there is nothing to be done here.

In the case the the user has an account for mint A, we could add the change proofs to the account.

In my opinion, the fee reserve should just be treated as the total fee and we keep things as they are with simply forgetting any change. It could be worth adding the complexity of trying to recover LN fees if mints are drastically over estimating the LN fee

[gudnuf]

Here's an example of why we would want to improve the handling of ecash change for cross account receives. In this case I was claiming 14 sats from https://mint.westernbtc.com to my Spark wallet. The mint drastically overestimated the fees and ended up returning 8 sats of change that was all lost.

/v1/melt/bolt11 payload

{
  "quote": "FDtliffc1CJmf2gM5YXCyxNWv-k4b7IOUUkROG4Q",
  "inputs": [
    {
      "secret": "8dd053e07046442ca5c01d41b10e7894e40d4c20acaeeaeeb2b071e91001a7ab",
      "C": "02a5d69779411d738477b2a9428410d8c4b1d5531660fb1a837362daceee602f5a",
      "amount": 8,
      "id": "00300181af4cf32d"
    },
    {
      "secret": "9a5f5d49a85b3c098c2686319f508fb097bc771850b18a064cde8b8cd0032dd1",
      "C": "02f775f6bebac1fda09879baacc2247ed6f54c9731a2eda772e5e9f2a64ef18e95",
      "amount": 2,
      "id": "00300181af4cf32d"
    },
    {
      "secret": "b2ae3058f3064aaa290b3ad298d433d8aa4857f94a9035dda96d1db3577e93ff",
      "C": "02521399f9e6976cfd80a0aee61b6e94721c20d5a72ecfb6402bc7e548e9e1c5a0",
      "amount": 4,
      "id": "00300181af4cf32d"
    }
  ],
  "outputs": [
    {
      "amount": 1,
      "B_": "02915a682c4b6d4cbf4f06b94c9f099130d6c7190afabda181be0012e242d8b39e",
      "id": "00300181af4cf32d"
    },
    {
      "amount": 1,
      "B_": "032e682acc03d1ef5edc7386938b337a69bfc35a2ffd8993836ffa273836bf1245",
      "id": "00300181af4cf32d"
    },
    {
      "amount": 1,
      "B_": "02ee1f9d56165f63c7883706b9faab676ed32ae09a9763e759e5b5c6f8f6d55dfb",
      "id": "00300181af4cf32d"
    },
    {
      "amount": 1,
      "B_": "0354292fc4e837a432e67e00cad4d225d243b951f5b9d4e97b65842769ab02fe71",
      "id": "00300181af4cf32d"
    }
  ]
}

/v1/melt/bolt11 response

{
    "quote": "FDtliffc1CJmf2gM5YXCyxNWv-k4b7IOUUkROG4Q",
    "amount": 4,
    "unit": "sat",
    "request": "lnbc40n1p55kvw0pp5m9d07rp63jxh9qntm0l320fdzrjxr2zgfm7gjrn96uhy4w3zu7rssp5axh4pdjt86sdmsuf3n3xddhphr5zdgvzgaz9k3u7nwefrpul9p9qxq9z0rgqnp4qvyndeaqzman7h898jxm98dzkm0mlrsx36s93smrur7h0azyyuxc5rzjq25carzepgd4vqsyn44jrk85ezrpju92xyrk9apw4cdjh6yrwt5jgqqqqrt49lmtcqqqqqqqqqqq86qq9qrzjqwghf7zxvfkxq5a6sr65g0gdkv768p83mhsnt0msszapamzx2qvuxqqqqrt49lmtcqqqqqqqqqqq86qq9qcqzpgdqq9qyyssqgvu4y0zqa6kgnw6ugljwxnrz0kvj88fwrsh60kszxkqer2rghulx5usu66a4gdwrzss780et0wtwpvp8alhsqnwvld3kenl27592g0spkmz5h0",
    "fee_reserve": 10,
    "paid": true,
    "state": "PAID",
    "expiry": 1769127631,
    "payment_preimage": "333f00f22646acd5bbec87935d919fd95606b86b43393e4c6f2a349db735acb8",
    "change": [
        {
            "id": "00300181af4cf32d",
            "amount": 8,
            "C_": "023430f01ff863a2d8b22ea56520fe9739134a13bb41215fe1f0885fd87ea9513e",
            "dleq": {
                "e": "27b02ab0124fbf67ea75fd11ed2aae2994376734cffa7e629789c87424c78b4f",
                "s": "c222d5a3fce53ea81e3387bac6aaab6a44c4984abf208e99c8ac2337d9342030"
            }
        }
    ]
}

[jbojcic1]

The question is what do we do with the change. If the user has the account with the mint that created a token, then it's easy and we just add it to balance there (though we'd probably need to make sure this is somehow possible to correlate in txn history which could be non trivial). If the user doesn't have the account with that mint we have two options:
a) we add an account for that mint and then receive change there automatically
b) we create a new cashu token from the change, store that to our db and present it to the user (probably on txn details page) who can then decide what to do with it