Avatar
techfeudalist
98a386c766ac9250f4ce1b500662fd08e4d464a1915743eedc83bd50521decac
Blessed by tech; working to bring the benefits to everyone. Freedom, incorruptible money, privacy.
Replying to Avatar Carsten Keutmann

Reputation

Solving the Tragedy of the Commons problem in a decentralized system is challenging, especially when there’s no central authority to enforce rules, restrict usage, or punish individuals who misuse resources. In traditional environments, people usually need to provide something of value—whether it's money, time, or effort—in exchange for access to shared resources. This creates a natural check on overuse. However, in decentralized systems like Nostr, where there’s a desire to keep things open and accessible to all, implementing a payment-based solution can be problematic. Such solutions are often unpopular because they exclude those without the means to pay, which runs counter to the ethos of inclusivity.

But there's one resource everyone possesses that could be used as a stake: reputation. The idea is that access to resources can be tied to the reputation of the user. A good reputation allows greater access to shared resources, while a low reputation might limit one's ability to access these resources freely. Reputation acts as a form of currency within the system, but with a key difference—it’s earned through consistent, positive behavior over time, and can be lost quickly if one abuses the system. This asymmetry—where building reputation takes time and effort, but losing it can happen swiftly—creates a strong incentive for users to act responsibly. By linking resource access to reputation, the system can encourage sustainable usage without needing a central authority to enforce rules.

In essence, this approach leverages the natural human desire to maintain a good standing within a community. When users know that their actions directly impact their reputation, and by extension, their ability to access resources, they’re more likely to avoid behavior that would harm the network as a whole. This could be a powerful way to address the Tragedy of the Commons in decentralized systems, ensuring that the community self-regulates and preserves the integrity of shared resources.

nostr:note138a97epurfkt7kau3sffr3xu4fatt2529pu7pwjhs69hzjjud3yscdfu85

#WoT #WebOfTrust

New users have no reputation and it’s not clear how they can earn it in a decentralized system.

Replying to Avatar Leo Fernevak

Central planning ideas may sound bizarre (and they are) but they are not random musings without a history.

In Plato's Republic, Socrates proposed that in his idea of a utopian city state, children of the Guardian class should not know who their parents are and they should be brought up collectively. The goal was an attempt at eugenics; to produce the perfect citizens.

Let's dive into Plato's Republic.

"It follows from what we have said, and from our whole previous argument - that our men and women Guardians should be forbidden by law to live together in separate households, and all the women should be common to all the men; similarly, children should be held in common, and no parent should know its child, or child its parent."

// Plato - The Republic, Book 5, part 6, 457.d

"... our Rulers will have to employ a great deal of fiction and deceit for the benefit of their subjects" // 459.d

"We must, if we are to be consistent, and if we're not to have a real pedigree herd, mate the best of our men with the best of our women as often as possible, and the inferior men with the inferior women as seldom as possible, and bring up only the offspring of the best.

And no one but the Rulers must know what is happening, if we are to avoid dissension in our Guardian herd." // 459.e

"And we shall have to devise an ingenious system of drawing lots, so that our inferior Guardians can, at each mating festival, blame the lot and not the Rulers." // 460.a

"These officers will take the children of the better Guardians to a nursery and put them in charge of nurses living in a separate part of the city; the children of the inferior Guardians, and any defective offspring of the others, will be quietly and secretly disposed of." // 460.c

As we can observe from the above reasoning, Plato laid the philosophical groundwork for authoritarian central planning based on eugenics, secrecy and deception, for the assumed "common good". The road to hell is paved with a lot of well-sounding justifications.

While Aristotle opposed this idea of having wives and children in common, he made the observation that *if* this were to be done, and since slavery was the standard at this time, it would be better that the husbandmen class had this arrangement:

"This community of wives and children seems better suited to the husbandmen than to the Guardians, for if they have wives and children in common, they will be bound to one another by weaker ties, as a subject class should be, and they will remain obedient and not rebel."

// Politics, Book 2, Chapter 3, 1262.a.40

It is important to mention here that Aristotle argues several pages against Plato's idea of shared wives, children and also against shared property. This is not a scenario that Aristotle wants to see. He just considers that *if* it were to be done in theory, it would result in a weakened subject class that cannot rebel.

From here it is not hard to see the trailing impact of Plato's ideas on Fabian socialism and the general eugenics movement in the early 20th century.

When we are confronted with ideas of abolishing the family, or the gradual introduction of the State in handling family matters of education, we are tracing the roots of authoritarian central planning back to Plato.

Below, Katherine Timpf's article from 2015:

https://www.nationalreview.com/2015/05/professor-if-you-read-your-kids-youre-unfairly-disadvantaging-others-katherine-timpf/

#Plato #Republic #Aristotle #Eugenics #Family #Central #Planning

Yikes 😬

nostr:note1fgw50yr4npv7lq486kpk05wtjsvk6m3je6a825dstvrg39qfm6vqh3f2g0

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.

Replying to Avatar Susiebdds

In light of the information coming out about the GA school shooter I’m more fired up than ever about a situation my son is involved in at school. A boy in my son’s grade has accused my son of bullying him half a dozen times. Half the incidents have been proven false via video footage -my son was not even present 2 of the three times. Two incidents involved locker room jokes about deer testicles and “your mama so fat” between his friends that this kid wasn’t a part of but he overheard them and found it offensive. The last incident involved my son breaking up a fight with this student and an even smaller student. A week later this boy pulled a knife on my son at school and threatened to kill him because his dad is military and has trained him to kill. The threats of physical violence have continued this year and this kid has a strong infatuation with guns (presentations on guns, projects about guns and talks about guns constantly) The school’s position is “Your son is so big, there is no threat,” “Your son is literally a foot taller than this kid,” “This boy is on the spectrum and doesn’t always know what he is saying,” “I’m pretty sure your son could handle himself if he felt threatened.”

I am livid and today threatened involving law enforcement if it continues. I’d rather be wrong and considered an overzealous mom than right and students including my son get hurt.

What do you think and how would you handle this if it were your child?

“A week later this boy pulled a knife on my son at school and threatened to kill him …”

Enough said. Sounds like a future school shooter.

Decentralization, privacy and bitcoin maxi?? Good, I’m in the right place. 😎 nostr:note1nacvq4m4nr9p6p4jplwj6qn9m7wrmtt8x58cd7afq57j4y27k73qs7gzx4

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.

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.

Replying to Avatar Leo Fernevak

Agreed.

While I think that Bitcoin will survive the potential risks of CTV, I never liked the idea of increasing unknown factors.

Perhaps I am wrong in my opposition to CTV and perhaps CTV might be overall beneficial for Bitcoin. Still, we need to think adversially regarding potential risks that could be used to harm the network.

1. Expanding the scripting capabilities. We can expect pros and cons here and it is hard to foresee what these will be.

2. The possibility of creating closed whitelisting loops.

After thinking the second point through over the last few weeks, I am no longer concerned with this scenario. Yet I will share my general thinking process of why I have changed my mind.

As for point 2, if I were to steelman the pro-CTV position, we could argue that all functions that improve security for decentralized Bitcoin users, also can be used by governments to increase the security of government-owned bitcon.

What secures *our* bitcoin as liberty advicates also secures government owned bitcoin, and vice versa. This is an unavoidable and fair situation that benefit Bitcoin.

A hypthetical worst case scenario:

The US, Canada, EU and Australia joins together to prevent bitcoin withdrawals from all exchanges within their respective jurisdictions.

This would not impact the Bitcoin network and sovereign Bitcoin users, but a lot of customers at exchanges would suffer.

Let's say that in this tyrannical scenario, the users of exchanges are only allowed to withdraw their capital in the form of CBDCs, while the exchanges end up holding the exchange-stored bitcoin.

We could then formulate multiple strategies for this alliance of the US and its partners to keep the mentioned exchange-stored bitcoin from being returned to their rightful owners.

One strategy could be via multi-sigs, which of course already exists. If a multi-sig requires signatures from both the US, Canada and the EU, it could be hard to overturn this decision via changing the laws in a single jurisdiction such as the US or the EU.

Another strategy could be to lock in the exchange-stored bitcoin into an unbreakable whitelisting loop, where the US, Canada, EU and Australia all include each other's addresses in a closed whitelisting loop system. If the government of the US is sued and ordered by the supreme court to give back user's bitcoin, it may not be able to.

On the other hand, if this were the case, the US could be forced to buy new bitcoin from the market in order to satisfy customer demands. This would make the whole closed whitelisting loop pointless, apart from it being ineffective from a global trade perspective.

It seems to me that my previous concern over closed whitelisting loops is not valid since it cannot function as a strategy for governments to abolish private property rights of bitcoin users.

My conclusion therefore is that closed whitelisting loops cannot become a threat to Bitcoin.

I am still critical of CTV, but less so than before.

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.

nostr:note19duwtxsgfmlhx70wspenk7m2gjvv4v6565tgcg43zs0w09nnc0asle4kkr

Replying to Avatar Peter Todd

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.