-
@ da0b9bc3:4e30a4a9
2025-02-13 06:36:12
Hello Stackers!
Welcome on into the ~Music Corner of the Saloon!
A place where we Talk Music. Share Tracks. Zap Sats.
So stay a while and listen.
🚨Don't forget to check out the pinned items in the territory homepage! You can always find the latest weeklies there!🚨
🚨Subscribe to the territory to ensure you never miss a post! 🚨
originally posted at https://stacker.news/items/884478
-
@ e3ba5e1a:5e433365
2025-02-13 06:16:49
My favorite line in any Marvel movie ever is in “Captain America.” After Captain America launches seemingly a hopeless assault on Red Skull’s base and is captured, we get [this line](https://www.youtube.com/shorts/kqsomjpz7ok):
“Arrogance may not be a uniquely American trait, but I must say, you do it better than anyone.”
Yesterday, I came across a comment on the song [Devil Went Down to Georgia](https://youtu.be/ut8UqFlWdDc) that had a very similar feel to it:
America has seemingly always been arrogant, in a uniquely American way. Manifest Destiny, for instance. The rest of the world is aware of this arrogance, and mocks Americans for it. A central point in modern US politics is the deriding of racist, nationalist, supremacist Americans.
That’s not what I see. I see American Arrogance as not only a beautiful statement about what it means to be American. I see it as an ode to the greatness of humanity in its purest form.
For most countries, saying “our nation is the greatest” *is*, in fact, twinged with some level of racism. I still don’t have a problem with it. Every group of people *should* be allowed to feel pride in their accomplishments. The destruction of the human spirit since the end of World War 2, where greatness has become a sin and weakness a virtue, has crushed the ability of people worldwide to strive for excellence.
But I digress. The fears of racism and nationalism at least have a grain of truth when applied to other nations on the planet. But not to America.
That’s because the definition of America, and the prototype of an American, has nothing to do with race. The definition of Americanism is *freedom*. The founding of America is based purely on liberty. On the God-given rights of every person to live life the way they see fit.
American Arrogance is not a statement of racial superiority. It’s barely a statement of national superiority (though it absolutely is). To me, when an American comments on the greatness of America, it’s a statement about freedom. Freedom will always unlock the greatness inherent in any group of people. Americans are *definitionally* better than everyone else, because Americans are freer than everyone else. (Or, at least, that’s how it should be.)
In *Devil Went Down to Georgia*, Johnny is approached by the devil himself. He is challenged to a ridiculously lopsided bet: a golden fiddle versus his immortal soul. He acknowledges the sin in accepting such a proposal. And yet he says, “God, I know you told me not to do this. But I can’t stand the affront to my honor. I am the greatest. The devil has nothing on me. So God, I’m gonna sin, but I’m also gonna win.”
*Libertas magnitudo est*
-
@ 2183e947:f497b975
2025-02-13 04:44:45
# How Coinpools Improve Bitcoin
# Problems with bitcoin
UX problems with base layer payments include:
- Mining fees are sometimes high
- Confirmations usually take several minutes
- Using it privately requires running a coinjoin server
UX problems with lightning payments include:
- Setup fees are sometimes high
- Payments frequently fail
- Payments aren't asynchronous (the recipient has to stand there with their device open waiting to do a revoke_and_ack on their old state -- unless they use a custodian)
- Payments that *do* succeed occasionally take more than 30 seconds (due to stuck payments, automatic retries, and no ability to say "stop retrying" in any existing wallets that I'm aware of)
- Using it privately requires manual channel management
# Solutions
A lot of my recent work focuses on non-interactive coinpools. I figured out a way to do them on bitcoin if we had CTV + CSFS, and then, with a bit more thought, I figured out that my model didn't actually require those things, so I am now working on an implementation. But my model does benefit a lot from CTV (less sure about CSFS at this point) so let me outline how non-interactive coinpools fix the above problems and along the way I will share how CTV specifically improves coinpools.
## "Mining fees are sometimes high"
Coinpools improve the problem of "mining fees are sometimes high" by letting you bypass them in more cases. If you're in a coinpool and pay someone else in the same coinpool, your payment does not show up on the base layer, it just involves modifying some unilateral withdrawal transactions such that the sender can withdraw less and the recipient can withdraw more. The transactions are off-chain, like LN transactions, so you can do that without paying a base layer fee.
## "Confirmations usually take several minutes"
Coinpools improve the problem of "confirmations usually take several minutes" in a similar manner. Payments *inside* a coinpool (i.e. to another pool user) merely involve modifying off-chain data (and revoking an old state), so they can be as fast as lightning. In most cases I expect them to be a bit faster because there's less need for pathfinding or negotiating with a variety of routing nodes. If the sender and the recipient are in the same pool, they only need to talk to each other and, in my model, a coordinator.
## "Using the base layer privately requires running a coinjoin server"
Coinpools improve the problem of "using the base layer privately requires running a coinjoin server" in two ways: first, if you're in a coinpool and you send money to a bitcoin address, the blockchain doesn't know which coinpool user sent that payment. Analysts might be able to trace the payment to the coinpool, but from the blockchain's perspective, that's just a multisig; the actual person *inside* the multisig who sent the money is not revealed. However, my model uses a coordinator, and the coordinator probably knows which user sent the payment. Still, only 1 person knowing is better than having everyone on the blockchain know.
Second, if you send money to someone *inside* the coinpool, in my model, the only people who know about your payment are the sender, the recipient, and the coordinator, and the recipient does not know who the sender is. Moreover, my model allows users to act as bridges from LN to other pool users, so even the coordinator doesn't know if the person who *looks* like the sender was the *real* sender or just a bridge node, with the *real* sender being someone on lightning.
## "Setup fees on lightning are sometimes high"
Coinpools improve the problem of "setup fees are sometimes high" by having multiple users share the setup cost. My model allows a single bitcoin transaction to fund a coinpool with a number of members between 1 and probably about 100. (The max I've actually successfully tested is 11.) If the users share the cost of that transaction, then even in a high fee scenario, where bitcoin transactions cost $50, each user only has to pay a fraction of that, where the fraction is determined by how many users are joining the pool. If 10 people are joining, each user would pay $5 instead of $50. If 50 people are joining, each user would pay $1. If 100 people are joining, each user would pay 50¢.
## Sidebar: how CTV improves my coinpool model
The setup is also where CTV greatly improves my model. For my model to work, the users have to coordinate to create the pool in something I call a "signing ceremony," which is very similar to a coinjoin. The signing ceremony has to be scheduled and each user has to show up for it or they won't get into the pool. With CTV, you could fix this: instead of a signing ceremony, an exchange could autosend your money into a coinpool on e.g. a monthly basis and email you the data you need to perform your unilateral exit. All they need from you is a pubkey, and they can do everything else.
## "Lightning payments frequently fail"
Coinpools improve the problem of "payments frequently fail" by reducing the need for pathfinding, which is a typical cause of failure on lightning. If you are paying someone in the same pool as you, you always know an exact path: it will be you -> coordinator -> recipient. These short paths also reduce the likelihood of routing nodes having insufficient capacity to forward the payment. You've only got one "routing node" to worry about -- the coordinator.
## "Lightning payments aren't asynchronous"
Coinpools *in general* don't improve the problem of "payments aren't asynchronous" but my model in particular *does* improve that problem because I am combining it with my hedgehog protocol from last year, which *does* allow for asynchronous lightning-like payments. Relatedly, my coinpool model technically has a network model, it's just a hub-and-spoke network: the coordinator is connected to every user of the pool and can forward asynchronous hedgehog payments to them. This means you can send money to someone when they are offline; they'll get it whenever they *do* get online, even if *you* went offline in the meantime.
## "Lightning payments sometimes take too long"
Coinpools improve the problem of "stuck" lightning payments by reducing the number of hops along the route. As above, a payment inside the pool (per my model) is always just sender -> coordinator -> recipient. Due to only having 1 hop, there are fewer opportunities for a node to have a network issue and cause a delay.
## "Channel management is a pain"
Coinpools have multiple ways of improving the problem of manual channel management. In particular, not all coinpool models *have* channels, so channel management is not always needed in a coinpool. My model, however, does have channels, so channel management is still a thing.
Nonetheless, my model improves channel management in two ways: first, the setup costs are lower for the reasons given above. Second, payment asynchronicity helps for the following reason:
The worst pain point in channel management *today* occurs when someone sends you a payment but it fails because you didn't have enough inbound capacity. That doesn't happen in my coinpool model because payments are asynchronous. If you don't have enough inbound capacity, the payment doesn't fail, it just remains pending. So all you have to do is open a new channel (i.e. enter a new pool) and *then* finalize the payment.
## Zap me
I hope this essay clarifies why coinpools improve the problems I outlined and why CTV improves coinpools. I also hope this gets you a bit excited for my latest coinpool invention, which I hope to release soon :D (It really is very close to demo-ready.) If you liked this essay, consider zapping me: supertestnet@coinos.io