Subnostr

One could argue that custodial wallet providers should be using blinded ledgers aka eCash in their very own interest.

If they don't phsically record who owns what, they can't really be compelled by agencies to hand over that data.

[They may still be forced to shut down their service altogether for all kinds of regulatory reasons, e.g. being classified as Payment Service Provider, which doesn't have a license. But that's a different discussion, and the very same risk exists today - where they still record very user transaction unblinded]

steepdawn974 2y ago

Speaking of which: Why not switch LNBits' accounting method to blinded eCash? 😉

legend.lnbits.com for instance is probably one of the bigger custodians out there, but it would also encourage other people to host public instances

Reply to this note

Please Login to reply.

Discussion

calle 2y ago

In ecash, there are no accounting methods :)

You can run a chaumian mint in LNbits with the Cashu plugin!

steepdawn974 2y ago

I know. I'm talking about replacing the entries/invoice data in the LNbit Postgres/SQLite db somehow with blinded entries.

That said, I haven't looked into the Internals of the LNbits backend yet and might be talking out of my depth here. I seem to recall that all invoices are recorded in backend SQL, so the operator can supposedly see the user_id, wallet_id and LN invoice data of all users.

My comment was more meant as a general remark/design question:

"Could LNBits be made such that the above mentioned User data is shielded from the instance operator?"

steepdawn974 2y ago

But when I think about it, all you'd really need is column encryption `pgcrypto` (client needs to provide a decryption key though.. maby a password?) at the database level. not 100% bullet-proof against a malicious server admin, but at least would guard you against database breaches from outside.

And if PG evere adds Transparent Data Encrpytion, than that would be a good option too.