nostr:note1fgw50yr4npv7lq486kpk05wtjsvk6m3je6a825dstvrg39qfm6vqh3f2g0
nostr:note1m37szazusmfvg4nf9rrqcr55t7tgapp484ehgzft7wespmc74wxsw82nmn
I only see two ways to stop this spam.
1) filter to see only posts from people in your trust graph
2) impose a real cost to post to all
Anything I’m missing?
Bottom line is that new users will be initially treated like spammers.
This attack is probably just a warm up. I would expect that we’ll soon see AI posts that you can’t pattern match, and overwhelming spam against both replies and DMs. I would expect them to initially target the folks with the largest follower count, then attacking new users.
Decentralization, privacy and bitcoin maxi?? Good, I’m in the right place. 😎 nostr:note1nacvq4m4nr9p6p4jplwj6qn9m7wrmtt8x58cd7afq57j4y27k73qs7gzx4
Pretty interesting stuff.
"Liquid is not that different than a fedimint or an ark. All of these solutions are trying to share the cost of a UTXO." - nostr:npub1ey6qdmvzcgcsr883m9nspzz0mm037l26xtardzcskfsvc6gc7jssm9szvp from nostr:npub1jugar2agq6369p0l86razavs9shj2p6pscxecevs8j94ap37hkqsjlfc28 explains some similarities and differences between Liquid, Fedimint and Ark
This makes sense to me. Everything seems to boil down to how many people need to collude to take your bitcoin.
You can compare L2s (and even L1) by comparing the collusion factor and the harm that such collusion might do.
Eventually, perhaps we see interoperable ecash between BTC and LBTC. I would assume there is nothing preventing liquid ecash.
That doesn’t make sense to me because it seems custodial lightning was preferred by plebs even *before* nostr existed and even *now* when there is no need for offline receipt. Like in El Salvador or Costa Rica, for everyday retail payments. Last I saw, WOS and Bitcoin Beach / Blink, were preferred before nostr, and probably still are. For your argument to be correct, I would expect to see widespread and growing self-custodial lightning usage in those communities.
Am I wrong about that?
You might be right that the early nostr adopters were all using self-custodial lightning, but surely you’d agree that is not a representative sample of plebs. As nostr grew, it was probably destined to become mostly custodial because of the existing preference of plebs.
I don’t know what percentage of lightning usage is custodial but I’ll bet that by almost any metric it will be custodial by a large and growing margin.
Maybe this is unpopular, but my current thesis is that self-custodial lightning will become used only by federations, exchanges, and other custodians. We, the plebs, will all migrate to ecash, presumably to large geo-federations when they exist. I’m just guessing here, but that’s the trend I see right now.
Do you really believe that bitcoiners are using custodial nostr apps only because the interactive push payments?
The custodial apps all offer better UX across many aspects: free, no upfront capital cost, better routing, ongoing liquidity management, etc.
If there was a current problem, and we needed non-interactive push payments, we would see many people using Mutiny and using offline receipt and forwarding services. But we don’t because Mutiny was the best non-custodial app I’d seen but still didn’t have product-market fit.
Said another way, if we snapped our fingers and solved the push payments tomorrow, we still would have almost nobody using Mutiny. Lightning’s UX issues are much bigger than that.
I think this was a very productive discussion. Thank you. 🙏
My position is that the rush to solve scaling is premature. Changes to the protocol must be both safe and necessary.
There is a debate over CTV’s safety and many devs acknowledge some risk. But what about its necessity?
Do we have an existential scaling problem today? As I type, the mempool is clearing at 3 sats/vbtye.
I’ve seen no evidence that normies want self-custodial bitcoin right now. It’s funny because @utxo just shared a meme on how normies want centralized apps where they can sign in with Google:
nostr:note1ejc68g2p2cdq32vlw52de9dcfqfzvy28m4ywnhqffxt7e5rg6hjs3ycj2p
You want self-custodial bitcoin, I do too. But I’ve seen NO evidence that bitcoin is failing to grow because of an inability to scale or that CTV, CAT or anything else will “fix” whatever future problem we might have.
We can’t “solve” problems that don’t yet exist. Especially if we’re taking a risk to the bitcoin network in doing so.
Maybe you’ll be right and there will be an existential scaling problem someday. If there is, the best minds can solve it then. Isn’t premature optimization one of the worst “crimes” in computer science? In the meantime, we should continue to do research and test out options on other layers so we’re ready for what the future brings.
There is no ossification “now or never” line in the sand unless you believe C++ coding will somehow be lost to antiquity.
Devs arguing that they need to push this through quickly while they can is just an indictment that they believe that they have some power now that they won’t have later. Those devs believe they should have the governance power and not the nodes. This is a power grab, and an attack on the network.
Yes, and arguably any forced whitelisting makes non-whitelisted bitcoin more valuable. It’s terrible for people in those jurisdictions but doesn’t affect the bitcoin network as a whole.
I believe devs should follow the principle of, “first, do no harm”.
If there is potential risk, then we need to find a different way. Nobody can assess the magnitude of the risk.
We need to think long term and protect bitcoin for future generations.
💯🎯
I don’t understand why devs are in such a rush and willing to skip proper risk assessment. It’s clear CTV and CAT adds risk to bitcoin. Peter admits this. The problem is that none of us know for sure how big a risk.
FIRST, DO NO HARM
It’s doesn’t matter that you can’t think of another way right now to add the features we want. Think harder. Take your time and get it right. Think long term. You don’t have the right to add any risk to the bitcoin network and gamble with our hope for the future.
#Bitcoin scaling, Trustless L2s, covenants, future soft forks.
Some clarity about many controversial topics by nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm, courtesy of Fulgur Ventures!
nostr:note1num4zp4qefrxtehc6gn8e7p0n43pcaawmkd0cctslvjz58lcvdqs5euxr9
nostr:note19duwtxsgfmlhx70wspenk7m2gjvv4v6565tgcg43zs0w09nnc0asle4kkr
https://petertodd.org/2024/covenant-dependent-layer-2-review
“Soft-Fork/Covenant Dependent Layer 2 Review”
I've finally published my big article sponsored by Fulgur Ventures, analyzing all the main covenant proposals, and the L2 proposals that would use them.
tl;dr: Ark is pretty cool, and CTV is a good way to get it.
Peter, you admit that it ADDS RISK:
“Unlike OP_CAT, CTV doesn’t appear to raise much risk of unintended consequences beyond encouraging out-of-band fee payments in certain cases. This isn’t ideal. But no-one has come up with a widely supported alternative.
My personal recommendation: do a consensus cleanup soft-fork, followed by CTV.”
YOU HAVE NO BASIS TO ASSESS FUTURE RISK. YOU CANT KNOW THE FUTURE AND HOW IT MIGHT BE ABUSED.
ADD NO RISK TO BITCOIN.
DEVS MUST FIRST DO NO HARM.
You have no right to gamble with the world’s money, and our hope for the future.
nostr:note1w0l22lnspmz86a6un0w52mssv22skgltyhhwmuuqf0ph0qwmd4cqjwrvd9
Peter says:
“Unlike OP_CAT, CTV doesn’t appear to raise much risk of unintended consequences beyond encouraging out-of-band fee payments in certain cases. This isn’t ideal. But no-one has come up with a widely supported alternative.
My personal recommendation: do a consensus cleanup soft-fork, followed by CTV.”
Peter admits it creates risk, but then claims omniscience to state that the risk is minimal.
Activate OP_GFY instead!!
ADD NO RISK TO BITCOIN. You have no right to gamble with the world’s money, and our hope for the future.
nostr:npub1h8nk2346qezka5cpm8jjh3yl5j88pf4ly2ptu7s6uu55wcfqy0wq36rpev … another dev admitting that it adds risk. nostr:note1nwvrh2eqf902vjel2t0hr2hftftrz8rxe4pmlp0m2rlef8dzh8mq54fuqp
Thank you for the response!
I can see our conversation is misaligned. Might be helpful to clarify my position. I’m not pushing back on particular functionality, per se. I’m only pushing back on how particular functionality interacts with the base chain — if that interaction might create centralizing incentives.
For example, I don’t reject smart contracts, arbitrary code execution, or the like, if done via multisig, lightning pools, or even BitVM (as I understand it today). I push back when it is done in a way that could harm bitcoin decentralization (eg OP_CTV).
What’s the difference? On-chain vs off-chain logic.
CTV’s logic is on-chain so I’m concerned about CTV creating centralizing MEV and therefore potentially creating incentives that promote miner centralization.
Let’s imagine that there was a trading marketplace on bitcoin where speculators were buying and selling securities, like how Uniswap enables trading on Ethereum.
If bids, offers, and pending transactions were visible and transactable on-chain, there would be an incentive for traders to bribe miners to help them jump the queue to transact before other traders. These bribes would flow as out-of-band payments through private APIs to the largest miners, creating an advantage for larger miners (hence promoting centralization).
There seems to be much less risk if the bids, offers, and pending transactions are off-chain and where the chain is only used for final settlement. For example, I don’t see any risk of people trading stocks on Nasdaq and settling with bitcoin. That’s just using bitcoin as money. No problems there! I DO see a big risk if people are trading stocks on a “bitcoin Uniswap” if there is any possibility that people may want to pay miners privately to jump the queue.
This is why lightning pools and BitVM don’t concern me — the logic is off-chain and the chain is only used for final settlement.
This is why I perceive a difference with CTV / Sapio. Everything seems to be on-chain. If someone could use it to create something like Uniswap then it poses a centralization risk to miners.
You can also think about this another way, specifically that types of transactions classified as safe or unsafe.
For example, the safest transactions are using the chain for final settlement, and are publicly broadcast so that no miner can have an advantage.
Unsafe transactions are those using the chain for some other purpose where there is some incentive to connect privately to a large miner. (That’s why inscriptions were so bad. Promoting node centralization by filling the chain with spam, while promoting miner centralization through private transaction APIs. Double whammy!)
Eg, MARA’s Slipstream API:
https://x.com/JStefanop1/status/1760764664651133162
Jeremy was clear that OP_CTV could be used for anything. He even demo’ed playing tic tac toe on chain. This is why I put CTV in the unsafe category.
I’m also not trying to quantify the risk. I’m in no position to assess whether it’s likely or not that someone will abuse CTV, CAT, etc, or how they might try. (And, nobody can really know.) My position is that these changes to the protocol should be rejected solely based on their architecture and potential for abuse.
Do you love a good conspiracy 🐇 🕳️ ?
Here ya go…
https://m.facebook.com/watch/?v=1199048941148695&vanity=61551094531099


