What about sending a single large UTXO to multiple Mercury statechain addresses, broken down into denominations, e.g.:

1.2M sat UTXO (or whatever > 1.2 M if also including a change address) sent to multiple addresses with the following amounts (in sats)

 10,000
 20,000
 40,000
 80,000
160,000
320,000
640,000
-------
1.27M sat total

Or some other combination totaling <whatever> Then you have multiple denominations on the statechain to spend in a more retail-like setting that together can add up to any desired amount (within the nearest <smallest denomination>). If enough people have done this, we don't need small UTXOs that exist 1:1 with small UTXOs on main chain.

Question: does the protocol allow for initial injection of a single UTXO on main chain into multiple statecoins?

Many or most -- AFAICT -- big custodians who are likely using actually-physical-hardware-based HSMs use legacy addresses rather than HD wallets. Possibly there exists already battle-tested software that is shared or shopped around in this sphere.

Thanks sensei, I needed to hear all of these today.

What's your conclusion? I am having the same problem. In high fee environments the channel open fees for Phoenix or Zeus are high, understandably.

EASY ANSWER:

Safety razor.

I have two: A Merkur 34C (pictured below), and a vintage Gillette from the 1950s or 60s.

I buy the most-premium-of-blades for just 10 cents each -- perfectly usable blades are even cheaper -- and they last for multiple shaves. My son and I hope oneday grandson will shave with these razors.

Welcome to Stacker News!

I've similarly experienced freezes and crashes with Nunchuk, which I really want to like.

If you are bound to mobile, you can make multisig wallets in BlueWallet, but you'll have to figure out coordination yourself.

As commented by another user, you may just consider using Sparrow on desktop, then sending PSBTs by Signal or some other secure messaging. Certainly less convenient.

Great write-up.

However, gift-cards are the wrong analogy inasmuch as they are generally only good at the issuer, although you may find occasional pockets of gift-card exchange for value outside the merchant/retailer.

A better analogy, although one that is less familar to contemporary audiences, is company scrip. [1]

Company scrip was widely used in Factory towns in the developing US around the time of the industrial revolution. The company issued money replacement was accepted widely throughout a community in exchange for goods and services, but wouldn't be useful in the next town over, for instance.

I should probably write an essay about this given the recent interest in federated Chaumian ecash...

[1] https://en.wikipedia.org/wiki/Scrip#Company_scrip

A federation size of (3n + 1) is resilient to n bad guardians.

Hard disagree. Recent excitement is coming from highly technical builders, and a wave of early adopters.

The entire letter:

Kind of surreal

I'm a new user and by default my zap amount was set at 100 when I signed up

One way this could work is -- with support from your app that interacts with the federations -- the following:

Suppose you have 100 fmBTC in Federation 1 (we'll denote as F1), and your current balance in federation 2 is 0 or very low.

Now imagine that you wish to pay someone in federation 2 50 fmBTC eCash. Clearly you don't have enough balance in this federation, but you do in F1.

A smart wallet could at the time you attempt to pay your friend in F2 (where you have zero balance) perform a multi-mint swap transparently in the background: it would mint a 50 sat eCash token on F1, direct a lightning payment to the F2 gateway with your own F2 account as designated beneficiary, which would materialize a 50 sat eCash token in your F2 account, that can then be sent to your friend.

Although this capability is not present in the Fedi alpha app (AFAICT?), it is present in the eNuts client for Cash (a similar, but non-federated Chaumian eCash system)

Arthur Hayes is always worth the time to read and digest.

Getting closer to launching my bootstrapped solo SaaS startup -- By the week-end I'll be ready to spin up the production environment to match what I've been running in staging. Hello doubled AWS bills...

Nature is healing

It expands the choices for onboarding people to Bitcoin.

There is no one true onboarding onto Bitcoin -- it should be a spectrum. This is common sense as we know that it is mathematically impossible for every human on earth to get a UTXO in less than 25-35 years.

More technically savvy friends will get one course of instruction from me (self-custody), while others might get a lightning wallet. Some are introduced to Phoenix or Zeus with on-phone node; others, a custodial LN wallet.

FediMint to me represents another bit of optionality on the continuum. I'd use this strategy to Uncle Jim my most cautious, conservative, or least tech savvy family members and friends as well as children, some of whom may have mobile device while others not. It will enable me to slowly onboard my reluctant or cautious or young family members and friends in a high-fee environment.

I expect many other friend groups and families have a "technical lead" who will set up a federation for similar purposes.

One question you didn't ask but that I'd take the chance to address in the context of Uncle Jim-ing as above, is the notion of single guardian "federation". The technology behind Chaumian eCash is very excited and shouldn't be limited to Federated models only. However, it could be very confusing to run both e.g. Cashu and FediMint. I anticipate in the beginning I would solely run the mint, but would like to rotate in additional guardians over time as people's knowledge (or my network) grows. It will be crucial in my mind to enable such a use case (initially 1 guardian with expanding M:N with time)