Abstract: In this document, I will outline a proof-of-liabilities (PoL) scheme for ecash systems and Cashu specifically, which is a Chaumian ecash system for Bitcoin. The PoL scheme consists of three parts. First, a publicly auditable list of all issued ecash tokens in the form of mint proofs, and second, a publicly auditable list of all redeemed ecash tokens in the form of burn proofs, which are both regularly published by the mint operator. Third, a mint publicly commits to rotate its keys regularly once each epoch and allows all ecash in circulation to recycle from old epochs to the newest one. If clients remain vigilant and mints agree on a certain set of rules of operation which are publicly verifiable, users of a mint can detect whether a cheating mint has printed unbacked ecash during a past epoch, and, in many cases, provide public proofs of the mint engaging in this adversary behavior. Users achieve this by regularly checking t
| use bitcoin_hashes::{sha256, Hash, HashEngine}; | |
| use bls12_381::{G1Affine, G1Projective, Scalar}; | |
| use core::array; | |
| use ff::Field; | |
| use group::Curve; | |
| use rand::{thread_rng, SeedableRng}; | |
| use rand_chacha::ChaChaRng; | |
| use std::io::Write; | |
| fn prove<const N: usize, const M: usize, const S: usize>( |
| import asyncio | |
| from cashu.wallet.wallet import Wallet | |
| from cashu.core.settings import settings | |
| async def main(): | |
| settings.tor = False | |
| wallet = await Wallet.with_db( | |
| url="http://mint.url:3338", | |
| db="wallet_db_path", |
This gist very briefly describes how to redeem a Cashu token to a Lightning wallet. It uses no Cashu libraries as dependencies. JavaScript code is provided as an example.
- Base64-urlsafe decode the part of the token after
cashuA... - You will get a JSON, let's call it
cashu. - Notice the proofs in
cashu.token[0].proofs - Get the Mint URL in
cashu.token[0].mint
In this document, we describe how we can optimize (i.e., minimize) the fees a Cashu wallet has to pay the mint for making a Lightinig payment with an unpredictable network fee. We do this with the introduction of so-called blank outputs which are blinded messages with an undetermined value.
In Lightning, we usually don't know the network fees required for paying an invoice in advance. In many Lightning node implementations and user-facing applications, a maxium fee reserve is defined before an invoice payment is attempted to limit the maximum fee risk of a payment.
This makes it challenging to design an ecash protocol that can handle Lightning payments with variable (and thus unpredictable) fees since the ecash for a payment plus potential Lightning network fees need to be provided upfront before the payment is attempted. Since ecash is not divisible, returning ecash for overpaid fees is impractical. Therefore, in Cashu, what we do right now is to simply provide the fee reserve in a
Starting from commit b99b413, LNbits bundling has transitioned into a new model where all the extensions are not part of the main repository anymore. We made this step to improve the security of instances, enabling them to run only the extensions they choose, and to improve code maintainability over the long run.
This means that the default LNbits install doesn't come with extensions anymore as they all have been moved to external repositories. When you do a git pull on your LNbits (on the main branch), you might notice that all extensions are suddenly gone. This gist is here to help.
If you run your own instance, I recommend installing extensions one by one, depending on what you actually need to keep the attack surface of your instance as small as possible. We will have a list of vetted extensions that we have checked and we'll maintain.
This PostgreSQL query compactifies the LNbits apipayments table. It collects all transactions older than a certain date (30 DAYS here) and aggregates them in one single transaction (for each, incoming and outgoing payments, separately).
The balances of all users remain unaffected. However, the transaction table can shrink significantly, which should speed up everything that LNbits does (especially the balance view).
Thank you @einzie for helping with this.
-- ******************************