hoppe2

I see that spam filtering is being handled, but simply blocking known spammers every time isn't a real solution. Eventually, is WOT (Web of Trust) the only answer? Or perhaps a PageRank-like scoring system based on extensive collection of kind 3 events? I'm also curious how your relay operates. I've considered attaching tiny amounts of e-cash as economic incentive for relay operators, which could contribute to a healthier ecosystem. But since events are commonly pooled and broadcast simultaneously to multiple relays (especially since there are usually several tagged recipients in a p-tag, and each user likely has at least two or three inbox relays), I'm not sure users would accept the added complexity. Plus, managing different policies(price) across relays would make implementation quite cumbersome.

Oh, I see. thk

You mean this is a non custodial wallet? But how is that possible if I'm not running my own Lightning node and opening channels myself? Given how quickly the setup was completed, it doesn't seem like an embedded LN node is being used either.

I'm currently using @Minibits mint through @Keychat , and I'm reaching out with a question. I'm personally developing a service that requires payment via hold invoice, and during development, I was testing the expiration/cancellation behavior by paying a hold invoice using the Keychat Cashu wallet. The payment attempt initially seemed to fail—although the payment did reach the recipient side, it remained in a "pending" state since it wasn't settled, which is expected. I didn't mind the unclear UI indication, since most wallets don't clearly display pending states anyway. However, the next day, after the invoice expired as intended and the payment properly failed, I noticed that the deducted balance in my Keychat wallet wasn't restored. Normally, when a hold invoice is canceled, the mint's Lightning node should recover the funds and reflect that credit back to the user's balance. If this were my own Lightning node, the balance recovery would have happened automatically. But with the Cashu wallet, since I had already paid ecash to the mint to initiate the payment, my balance was deducted up front. From the mint’s perspective, once the ecash was spent, the balance was marked as spent—even though settlement never occurred. And since the control had already been effectively transferred, the mint likely considered the payment as completed on its end. It doesn’t appear to track the subsequent cancellation status. Moreover, due to the anonymous nature of ecash, the mint likely can't identify who made the payment—even if they wanted to issue a refund, it might not be possible. I can provide proof of the hold invoice and confirmation that it was ultimately canceled (via DM). Surely a refund shouldn’t be impossible? I understand it might not be easy to verify, and while I understand if no refund can be issued (it's only 5,028 sats, not a large amount), this highlights a bigger issue: going forward, such payments need to be properly handled. Otherwise, it effectively means users permanently lose funds to the mint even when payments fail. This isn't just an issue with Minibits, but likely all #cashu mints. A proper mechanism needs to be developed to handle these cases.

Even if it's possible to make the exact amount with the current token combinations, it still ends up using just the tokens I have on hand, which can result in multiple inputs—like sending 256 using two 128s, for example. Swapping to send a single 256 token looks cleaner. But would making that the default behavior be wasteful due to the extra network round trip?

It would be great if, when issuing tokens, it could automatically send the exact amount using the minimum number of tokens—like finding the optimal combination. If the available tokens can't form the precise amount, it could fetch suitable denominations from the mint to make up the difference. It would be convenient if this were handled automatically at the library level. Do you know if such a feature already exists? @calle @Egge