Disagree with yoh. There’s no way Kamala doesn’t take the presidency ticket. DNC *could* say they want someone else but I highly doubt that.

I doubt Mrs Clinton will like that scenario.

Joe Biden will “gracefully bow out” of the election for “family reasons.”

He will “step aside to give another candidate the best chance at defeating Trump and preserving Democracy.”

Kamala will “step aside with Joe in solidarity.”

Michelle Obama will become the Democratic Party’s Presidential candidate and Gavin Newsom will be her VP.

The Obama-Newsom ticket will be hailed by the corporate media as “historic” and “our best chance at preserving Democracy.”

It would be cool if users could also advertise a list of trusted mints they are willing to accept funds from.

I have a Zeus wallet connected via tor to my LND node that has plenty of outbound liquidity. When I try to send 500k sats Zeus says it has a 100% success, probability, but it fails with “error: the request timed out “

100k sats works about 90% of the time. Why are the larger transactions failing due to timeout?

Ecash has different scaling properties than normal ledger-based payment systems. Let me explain how a single mint can support peak volumes of millions of transactions per second.

Imagine a VPN service where users mint ecash and pay-per-use instead of pay-by-account (privacy!).

User pays 10k sats to a mint and acquires 10,000 x 1 sat tokens locked to the VPN provider's pubkey. This might take a second or two.

Once locked, the user could stream these tokens to the VPN provider for every kb of data they use.

Once the the provider checks the incoming token's signature, they can be sure that it can't be double-spent! They can remain offline (no round trip with the mint) and do this thousands of times per second (CPU-bound).

End of week, the VPN provider unlocks the ecash and redeems.

Now, this was one user with one provider. The mint didn't even notice the payments. In theory, the same mint could do this for 100s of providers with 1000s of users.

All it does is sign tokens (lock) and redeem them later (unlock). It's not involved in the payments themselves.

Note that this works because the burden of validation is shifted from the server (mint) to the user (VPN provider) at time of payment.

Also, since eventually all tokens need to be minted and redeemed at some point, the above only holds for peak volumes and not for average tx/s.

I listened to the What Bitcoin Did Saylor podcast, and I really want to respond, though that may be unwise. But I want thoughtful, fearless content in my feed, so I should start making some, right?

Firstly, while analogies can provide useful guide rails for understanding, listening to people *arguing* using analogies makes you stupider. Debate the thing itself, not the words about the thing: it hurts my head to even think about doing this, so I won't.

Let's set my priors first: I assume we're talking about technically solid, well-vetted, backward compatible protocol changes: this is the minimum bar.

I don't wholesale agree with Saylor's "don't threaten anyone's investment" hard limit. This has happened multiple times in the past, from the dust limit breaking SatoshiDice, enabling Lightning threatening miner fees (real or not), and segwit breaking stealth ASICBoost. These interests can, and will, stand up for themselves and will compete against other benefits of changes.

To be explicit: I consider any protocol change which makes block space usage more efficient to be a win!

Obviously Saylor is invested in Bitcoin the asset, and can afford to do all his business onchain in any conceivable scenario. His projection of a Bitcoin world in which there are 100,000 companies and governments who use Bitcoin as the base layer is interesting:

1. This does not need "smart contracts", just signatures. By this model, Bitcoin Script was a mistake.

2. It can work if Bitcoin does not scale and is incredibly expensive to spend and hold. By this model, the consumer hardware wallet industry is a dead-end and needs to pivot to something else (nostr keys, ecash?)

3. You could do this with gold, today? Bitcoin here is simply an incremental, not fundamental, improvement. I think this is suggestive, though: that such a network would not be long-term stable, and very much subject to capture.

4. In this view, Saylor is simply a gold bug with first mover advantage, shilling his bags. That's fine, but it's important to understand people's motivations.

5. This vision does not excite me. I wouldn't have left Linux development to work on making B2B commerce more efficient. I wouldn't get up at 5:30am for spec calls, and I sure as hell wouldn't be working this cheap.

I believe we can make people's UTXOs more powerful, and thus feel a moral responsibility to do so. This gives them more control over their own money, and allows more people to share that control. I assume that more people will do good things than stupid things, because assuming the other way implies that someone should be able to stop them, and that's usually worse.

I believe the result will be a more stable, thus useful, Bitcoin network. I am aware that this will certainly benefit people with very different motivations than me (Saylor).

Thanks for reading, and sorry for the length!

A database account can just as easily be a random set of numbers, that transacts atomically disassociated from other random numbers, logless, encrypted, and so on

There's no difference except that the database is reliable, performant, and doesn't lie to lull users into a false sense of privacy whilest slipstreaming edollars into the bitcoin ecosystem

You are 100% trusting the operator in both scenarios, and you should never trust an ECasher

Hello world! #introductions I'm just today learning about Nostr and think it's got potential so that's why I joined. Let's see where this goes.

A mint can simply not redeem a token, based on any number of heuristics

And if you're worried about your account getting nuked maybe you shouldn't be using that custodian

ECash is nothing a database account isn't, it's not any more permission-less, or private, or asynchronous, it's literally a server authentication scheme. Transferring it offline is effectively writing down your password for someone.

... claiming it's more than that is being done intentionally by the central influencer agency to astroturf new banknotes being pushed by the government

Since there are no accounts and no place that holds your crash other than the device in your hands, it would literally require synchronizing the ecash between your devices. There isn't a Cashu wallet that does this yet. The mutiny guys are very good at this, maybe they're already doing it for Fedimint.

I recently learned that legislation has been drafted on Capitol Hill to classify *not re-using Bitcoin addresses* as "mixing"

There are also efforts to force "unhosted wallet providers" to collect user info for taxes

As well as to give power to Treasury to sanction any address (even Americans)

And a whole lot more bad stuff

IMO Coin Center does vital work to fight this and to protect privacy tech

They are a compact team and do a lot with the resources they have

They sue the OFAC and Treasury

They consider the Bank Secrecy Act unconstitutional and act accordingly

I just spent some time with their leadership team, asking questions, and came away impressed, I would strongly suggest a donation today

coincenter.org

If you know your secp256k1, you can build a Cashu wallet in one day.

Regular reminder that ecash is not going to fix all of our problems. Part of the reason I'm working on Cashu is because I think every custodian in this world should be an Ecash mint. And every credit card on this planet should be replaced by an ecash wallet. That's already enough to fix.

So let’s look at the docker-compose.yml file.

There are 3 sections:

Version, services, and volumes.

Version is 3.8. I’ll leave that until I see something different.

In Services, the guide installs nginxproxymanager, but I already have that running, so I’ll skip that.

In that section there’s also blossom-drive and blossom-server.

I will be installing blossom-drive, and for this section it looks like I just need to switch the ports from 80:80 to something else, like 2080:80, since port 80 on the server is already used.

Under blossom-server I’ll change ports from 3000:3000 to 3200:3000 since 3000 is also used on the server.

For volumes, I think this maps server volumes from:to volumes inside the docker.

There are two volumes mapped in the guide:

1. './blossom-server/config.yml:/app/config.yml'

2. 'blossom_data:/app/data'

Both are mapped to the “app” directory inside the docker, so I think both should be /mnt/user/appdata in my setup.

In that case, I should create config.yml in the appdata/blossom directory.

But “blossom_data” sounds like the actual images/files maybe? If so I don’t want them in appdata. So I’ll need to look into that.

First I should get the docker running, save an image and see where it puts things, then I can make changes and run it again.

Last section in the docker-compose is Volumes.

This says: blossom_data:

Which doesn’t seem to map this to anything inside the docker. Not sure what to do here.

#grownostr #blossom #asknostr